On Tue, 2014-11-11 at 19:00 +0100, Arnd Bergmann wrote:
On Tuesday 11 November 2014 12:46:18 Mark Salter wrote:
On Tue, 2014-11-11 at 18:37 +0100, Arnd Bergmann wrote:
On Thursday 06 November 2014 11:43:51 Arnd Bergmann wrote:
On Wednesday 05 November 2014 20:32:46 al.stone@linaro.org wrote:
From: Mark Salter msalter@redhat.com
ACPI 5.1 adds a _CCA object to indicate memory coherency of a bus master device. It is an integer with zero meaning non-coherent and one meaning coherent. This attribute may be inherited from a parent device. It may also be missing entirely, in which case, an architecture-specific default is assumed.
This patch adds a utility function to parse a device handle (and its parents) for a _CCA object and return the coherency attribute if found.
Signed-off-by: Mark Salter msalter@redhat.com
This should probably come before patch 26, so you can use it in that driver.
On a more general note, we also need to change the platform device creation path for ACPI to evaluate this and set the correct dma_map_ops based on it.
On second thought, I wonder why this is even required on ARM64. Are there any DMA masters that we want to support with ACPI that are not cache coherent? It sounds strange in a server context, so why not assume that everything is coherent and just set dma_mask=NULL for noncoherent devices to prevent them from doing DMA?
I think we need to support the _CCA info but this patch really isn't the way to do it. Just as the OF code looks for dma-coherent when creating the platform device, the check for _CCA should be in acpi_platform.c when the device gets created. I just haven't gotten around to writing the patch.
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.