[PATCH 06/10] soc/qbman: Add ARM equivalent for flush_dcache_range()

Scott Wood scott.wood at nxp.com
Wed Jan 25 21:08:43 PST 2017


On 01/25/2017 03:20 PM, Arnd Bergmann wrote:
> On Monday, January 23, 2017 7:24:59 PM CET Roy Pledge wrote:
>>> Is there a non-"under the covers" way to say "flush this region" without
>>> the arch second-guessing whether it really needs to be flushed?
>> Any advice on how to resolve this? I looked into trying to do a
>> non-cacheable mapping of the
>> memory so that the flush wouldn't be required but the ioremap code
>> prevents mapping normal
>> memory in this way.  The QMan device requiresthis memory to be zeroed at
>> startup. Because the device
>> does non coherent reads and writes to the memory we must ensure that any
>> cache in the CPU cluster(s)
>> is flushed in order to prevent a future castout from overwriting data.
>> This happened before on PPC
>> platforms and made for some very unfun debug session trying to
>> understand what was causing the failure.
> 
> If this is normal RAM, you should be able to just write zeroes, and then
> do a dma_map_single() for initialization.

The DMA API on PPC currently has no way of knowing that the device
accesses this memory incoherently.

If that were somehow fixed, we still couldn't use dma_map_single() as it
doesn't accept virtual addresses that come from memremap() or similar
dynamic mappings.  We'd have to convert the physical address to an array
of struct pages and pass each one to dma_map_page().

And even if we did all that, there would still be other manual cache
manipulation left in this driver, to deal with its cacheable register
interface.

> Are there any other requirements
> what to do with the memory later, is it used for communication at all,
> or just required to be zero?

It just needs to be zeroed before the device begins using it for
internal storage.

-Scott




More information about the linux-arm-kernel mailing list