On Tue, Feb 2, 2021 at 4:05 PM Marek Vasut <marek.va...@gmail.com> wrote: > > On 2/2/21 4:55 AM, Bin Meng wrote: > > Hi, > > >> The various structures in the driver are already correcty padded and > > > > typo: correctly > > > >> cache aligned in memory, however the cache operations are called on > >> the structure sizes, which themselves might not be cache aligned. Add > >> the necessary rounding to fix this, which permits the nvme to work on > >> arm64. > > > > +ARM guys > > > > Which ARM64 SoC did you test this with? > > RCar3, although that's irrelevant, the problem will happen on any arm or > arm64, and possibly any other system which needs cache management.
There was a recent change to nvme.c that fixed a cache issue on ARMv8 so I thought this might be platform related. > > > The round down in this patch should be unnecessary. > > Can you explain why ? I just took a further look and most of the start address should be cache line aligned (4KiB aligned) except the nvme_read_completion_status(). It's only 16 bytes aligned which might not be cache line aligned. > > > But it's better to > > figure out which call to dcache_xxx() with an unaligned end address. > > If you look at the code, most of them can (and do) trigger this, > therefore they need such alignment, as explained in the commit message. Now I wonder what's the correct implementation of the invalidate_dcache_range() and flush_dcache_range() in U-Boot? Shouldn't the round down/up happen in these APIs instead of doing such in drivers? Regards, Bin
