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
