Hi, Arnd:

2018-01-25 18:42 GMT+08:00 Arnd Bergmann [off-list ref]:

On Thu, Jan 25, 2018 at 4:45 AM, Greentime Hu [off-list ref] wrote:

quoted

2018-01-24 19:36 GMT+08:00 Arnd Bergmann [off-list ref]:

quoted

On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu [off-list ref] wrote:

quoted

2018-01-23 16:23 GMT+08:00 Greentime Hu [off-list ref]:

quoted

2018-01-18 18:26 GMT+08:00 Arnd Bergmann [off-list ref]:

quoted

On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu [off-list ref] wrote:

That looks reasonable enough, but it does depend on a number of factors,
and the dma-mapping.h implementation is not just about cache flushes.

As I don't know the microarchitecture, can you answer these questions:

- are caches always write-back, or could they be write-through?

Yes, we can config it to write-back or write-through.

Ok. If a WT-cache is common enough, you could optimize for that
case by skipping the explicit writeback here and just doing a synchronizing
instruction. Usually if the cache is configurable, one would pick the
writeback option though, so it's probably not important.

Thank you for this suggestion.
We have optimized in cpu_dcache_wb_range() and it will be called from
cpu_dma_wb_range().
It will do nothing if it is a write-through config cache.

quoted

quoted

- is the CPU physical address always the same as the address visible to the
  device?

Yes, it is always the same unless the CPU uses local memory. The
physical address of local memory will overlap the original bus
address.
I think the local memory case can be ignored because we don't use it for now.

Ok, makes sense.

quoted

quoted

- are there devices that can only see a subset of the physical memory?

All devices are able to see the whole physical memory in our current
SoC, but I think other SoC may support such kind of HW behavior.

This is one area that might need a more complex implementation then,
depending on what devices are used in other SoCs. For network or
storage devices, it's usually sufficient to configure a DMA mask
from the "dma-ranges" property of the parent bus in the device tree,
the kernel code will then use bounce buffers.

For other types of drivers, using the streaming DMA interfaces
can require using the swiotlb helper that performs the bounce
buffering at in place of the cache operations. With a bit of luck,
you won't ever need to worry about it, just mentioning it here in
case you run into that problem later.

The consistent_sync() implementaiton you showed earlier should be
good enough then.  With that change,

Acked-by: Arnd Bergmann <redacted>

Thank you. :)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html