On Wednesday 12 November 2014 11:12:17 Al Stone wrote:
On 11/11/2014 11:12 AM, Mark Salter wrote:
On Tue, 2014-11-11 at 19:00 +0100, Arnd Bergmann wrote:
On Tuesday 11 November 2014 12:46:18 Mark Salter wrote: I think that is correct in general, in particular for embedded x86 devices that may have noncoherent devices. However to repeat my earlier question: are you aware of any noncoherent devices that you think we will have to support on ARM64?
I'm not personally aware, but that is certainly not definitive.
My understanding from ARM is that there is no reasonable default. If we assume on ARM that devices are coherent, we are just as likely to assume wrong as when we assume they are non-coherent. I can only presume they know their customers better than I do.
The next version of the ACPI spec will address this and mandate a _CCA method be defined on ARMv8 for all bus masters.
Ok, so this is more of a general handwavy feeling that someone at ARM has. In this case, I'd assume that all servers are doing the right thing and that we don't care about ACPI on non-server parts in Linux.
This would also make the implementation of setting the right DMA mask and dma_map_ops straightforward: if the device is marked as cache-coherent, then set a 32-bit DMA mask by default and use the coherent swiotlb ops, otherwise set a NULL dma_mask and don't let the device do any DMA. An alternative would be to always set the 64-bit dma ops and not require swiotlb, but I suspect that we will see devices that are not 64-bit capable and I see no way for ACPI to detect that. Also, setting up the SMMU wouldn't be possible until the ACPI spec gains a way to describe the relation between a non-PCI dma master and the SMMU.
Arnd