[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