On Thu, Feb 04, 2021 at 10:26:36AM +0000, Andre Przywara wrote: > On Wed, 3 Feb 2021 14:08:39 +0100 > Marek Vasut <marek.va...@gmail.com> wrote: > > Hi Marek, > > I think our opinions actually don't differ that much, but we might be > either misunderstanding ourselves or talk about different things. > See below. [snip] > > >>>>> +static void nvme_flush_dcache_range(void *start, unsigned long size) > > >>>>> +{ > > >>>>> + unsigned long s, e; > > >>>>> + nvme_align_dcache_range(start, size, &s, &e); > > >>>>> + flush_dcache_range(s, e); > > >>> > > >>> There is no good reason for alignment restrictions when it comes to > > >>> clean (& invalidate), so there is no need for this wrapper. > > >> > > >> Is that on ARM64-specific or is that applicable in general ? The driver > > >> is expected to work on any CPU. > > > > > > Cache clean (actually: cache clean&invalidate) is what happens on > > > evictions > > > all of the time, at the cache controller's discretion. So there is no > > > real harm in that operation per se. When an eviction happens on a > > > *clean* cache line, this is basically just an invalidate, which is also > > > not > > > harmful. > > > > > > There are harmful cases when buffers sharing a cache line are both "just > > > invalidated" > > > and "cleaned" at different points in time. > > > > Is that on ARM64-specific or is that applicable in general ? (the above > > does not answer that question) > > I would say that's a property of *every* write-back cache > implementation: > https://en.wikipedia.org/wiki/Cache_(computing)#/media/File:Write-back_with_write-allocation.svg
I've been reading and digesting the thread as it goes, and the only thing I do want to chime in on here right now is that yes, U-Boot does and will continue to support every CPU that someone wants to run it on, and one of the takeaways I see from this thread is we need some better documented abstractions around cache, as it's very tricky to get right all the time. -- Tom
signature.asc
Description: PGP signature