[U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on event buffers more robust

Marek Vasut marex at denx.de
Wed Apr 5 10:25:41 UTC 2017


On 04/04/2017 10:26 PM, Dr. Philipp Tomsich wrote:
> 
>> On 04 Apr 2017, at 22:09, Marek Vasut <marex at 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


More information about the U-Boot mailing list