On Thursday 18 December 2014 20:29:43 Hanjun Guo wrote:
I rework this patch a little bit and add it to platform creation patch for ACPI, if it is ok to you, I will send it to ACPI maiilist.
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 if device is coherent.
A few more things about the general approach:
- I'm still not convinced that we want to have this on ARM64: we may want to WARN_ON() in arch_setup_dma_ops() if we get called on an ACPI based system with coherency disabled, so we can get an error report if we ever encounter a server system with broken coherency, and then decide whether we want to support that or not.
- I'm guessing that the algorithm is not what was originally intended here. Note that you can never have a child device that is more coherent than its parent. If you have a device that is marked coherent, and its parent is marked noncoherent, the latter should probably considered an override.
- While the meaning of cache-coherent is clear to me, the meaning of non-coherent is much less defined and is really platform specific rather than CPU architecture specific. On ARM32, most noncoherent systems require the use of uncached memory, or explicit cache flushes to work around the lack of coherency. On big NUMA server systems (e.g. mips, parisc, itanium, x86-numa), but also arm32 Armada XP, noncoherent devices still participate in the normal cache coherency domain but require a device specific synchronization to ensure that cache lines observed by the device are the same that are seen by the CPU. This can be hard to describe in a single object, unless it contains a method for synchronization.
Arnd