[PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()
Will Deacon
will at kernel.org
Thu Sep 8 06:32:38 PDT 2022
On Thu, Sep 08, 2022 at 02:27:19PM +0100, Catalin Marinas wrote:
> On Thu, Sep 08, 2022 at 02:02:13PM +0100, Catalin Marinas wrote:
> > On Thu, Sep 08, 2022 at 12:32:42PM +0100, Robin Murphy wrote:
> > > On 2022-09-08 11:32, Catalin Marinas wrote:
> > > > The architecture requires invalidate or clean while also stating that
> > > > clean+invalidate can be used instead, so I don't think there's much to
> > > > justify. From the mismatched attributes section:
> > > >
> > > > 1. If the mismatched attributes for a memory location all assign the
> > > > same shareability attribute to a Location that has a cacheable
> > > > attribute,
> > >
> > > This is not describing our case, though. We do have a cacheable attribute in
> > > at least one alias, but the shareability is *not* the same across all
> > > aliases, therefore at face value it clearly does not apply.
> >
> > From the CPU perspective, both the cacheable and non-cacheable aliases
> > have the same inner shareable attribute. The device accessing the buffer
> > presumably should use the same shareability attributes. In the worst
> > case it's outer shareable but on most implementations the inner and
> > outer shareability domains are the same.
>
> Ah, so you are referring to this paragraph:
>
> The shareability field is only relevant if the memory is a Normal
> Cacheable memory type. All Device and Normal Non-cacheable memory
> regions are always treated as Outer Shareable, regardless of the
> translation table shareability attributes.
FWIW, I've never understood what this paragraph means for the shareability
of something like an inner-cacheable, outer-non-cacheable mapping.
*shrug*
Will
More information about the linux-arm-kernel
mailing list