On 04/04/2017 10:26 PM, Dr. Philipp Tomsich wrote: > >> On 04 Apr 2017, at 22:09, Marek Vasut <ma...@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 . -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot