All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>, Christoph Hellwig <hch@lst.de>,
	linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()
Date: Thu, 8 Sep 2022 14:02:13 +0100	[thread overview]
Message-ID: <Yxnn1QhhLf/2ROrq@arm.com> (raw)
In-Reply-To: <6dfd53a1-ce24-086d-1ce6-093d48b033da@arm.com>

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.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-08 13:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23 12:21 [PATCH] arm64: dma: Drop cache invalidation from arch_dma_prep_coherent() Will Deacon
2022-08-24  9:58 ` Ard Biesheuvel
2022-08-24 11:23   ` Will Deacon
2022-08-24 11:49     ` Ard Biesheuvel
2022-08-24 22:00 ` Catalin Marinas
2022-09-07  9:04   ` Christoph Hellwig
2022-09-07 14:10     ` Russell King (Oracle)
2022-09-07 14:14       ` Christoph Hellwig
2022-09-07 14:15         ` Russell King (Oracle)
2022-09-07  9:03 ` Christoph Hellwig
2022-09-07  9:27   ` Robin Murphy
2022-09-07 16:25     ` Will Deacon
2022-09-07 17:50       ` Robin Murphy
2022-09-08 10:32       ` Catalin Marinas
2022-09-08 11:32         ` Robin Murphy
2022-09-08 13:02           ` Catalin Marinas [this message]
2022-09-08 13:27             ` Catalin Marinas
2022-09-08 13:32               ` Will Deacon
2022-09-08 15:49         ` Catalin Marinas
2022-09-07 16:28   ` Will Deacon
2022-09-22 20:02 ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yxnn1QhhLf/2ROrq@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=ardb@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.