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.svgI'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
