On Sun, Feb 07, 2021 at 07:20:14PM +0100, Marek Vasut wrote:
> On 2/4/21 5:57 PM, Tom Rini wrote:
> [...]
>
> > > > > > > > > +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.
>
> Documenting the u-boot cache function behavior precisely is fine by me, but
> that is somewhat separate topic from this bugfix.
>
> So I will ask a simple question -- is there anything blocking this bugfix
> from being applied ?While I can fix the typo, I'm waiting for an Ack/Reviewed-by from Bin (as he's spent the most time on this driver of late) and I'd really like one from Andre, or at least him agreeing this patch is a step in the right direction. -- Tom
signature.asc
Description: PGP signature
