On 04/04/2017 10:26 PM, Dr. Philipp Tomsich wrote:
On 04 Apr 2017, at 22:09, Marek Vasut marex@denx.de wrote:
The DWC3 flush expands to a clean+invalidate. It is not wrong, as long as it is used as in my patch: a. before the first time data is expected to be written by the peripheral (i.e. before the peripheral is started)—to ensure that the cache line is not cached any longer…
So invalidate() is enough ?
If I had to write this from scratch, I’d got with the paranoid sequence of:
handler(): { invalidate do my stuff clean }
However, some architectures in U-Boot (e.g. ARMv8) don’t implement the invalidate verb. Given this, I’d rather stay as close to what’s already there.
invalidate_dcache_range() must be implemented if flush_dcache_range() is, otherwise it's a bug.
Note that using flush (i.e. clean+invalidate) aligns with how caches are managed throughout various other drivers in U-Boot.
b. after the driver modifies any buffers (i.e. anything modified will be written back) and before it next reads the buffers expecting possibly changed data (i.e. invalidating).
So flush+invalidate ? Keep in mind this driver may not be used on ARMv7/v8 only …
Yes, a clean+invalidate. The flush_dcache_range(…, …) function in U-Boot implements C+I semantics at least on arm, arm64, avr32, powerpc, xtensa …
flush on arm926 does not invalidate the cacheline iirc .