All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	Will Deacon <will@kernel.org>, Nicolin Chen <nicolinc@nvidia.com>,
	Krishna Reddy <vdumpa@nvidia.com>,
	Dmitry Osipenko <dmitry.osipenko@collabora.com>,
	Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Janne Grunau <j@jannau.net>, Sameer Pujar <spujar@nvidia.com>,
	devicetree@vger.kernel.org, iommu@lists.linux-foundation.org,
	linux-tegra@vger.kernel.org, asahi@lists.linux.dev,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v9 1/5] dt-bindings: reserved-memory: Document iommu-addresses
Date: Fri, 7 Oct 2022 15:54:26 +0200	[thread overview]
Message-ID: <Y0AvkshNYmqc3UGo@orome> (raw)
In-Reply-To: <3fb949ad-74c4-1bac-7e14-5d056afcef5f@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Fri, Oct 07, 2022 at 02:45:31PM +0100, Robin Murphy wrote:
> On 2022-09-23 13:35, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > This adds the "iommu-addresses" property to reserved-memory nodes, which
> > allow describing the interaction of memory regions with IOMMUs. Two use-
> > cases are supported:
> > 
> >    1. Static mappings can be described by pairing the "iommu-addresses"
> >       property with a "reg" property. This is mostly useful for adopting
> >       firmware-allocated buffers via identity mappings. One common use-
> >       case where this is required is if early firmware or bootloaders
> >       have set up a bootsplash framebuffer that a display controller is
> >       actively scanning out from during the operating system boot
> >       process.
> > 
> >    2. If an "iommu-addresses" property exists without a "reg" property,
> >       the reserved-memory node describes an IOVA reservation. Such memory
> >       regions are excluded from the IOVA space available to operating
> >       system drivers and can be used for regions that must not be used to
> >       map arbitrary buffers.
> 
> Bah, I've only just realised: don't we also need to change the "oneOf:
> required: ..." schema to permit "iommu-addresses" without "reg" or "size"?

Hm... good point. I think at least we'll want another:

     - required:
         - iommu-addresses

in there. I wonder if we also need to avoid the combination of "size"
and "iommu-addresses". When "size" is specified, is it guaranteed that
those regions will be allocated before the direct mapping needs to be
created?

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-10-07 13:54 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23 12:35 [PATCH v9 0/5] iommu: Support mappings/reservations in reserved-memory regions Thierry Reding
2022-09-23 12:35 ` [PATCH v9 1/5] dt-bindings: reserved-memory: Document iommu-addresses Thierry Reding
2022-10-07 13:45   ` Robin Murphy
2022-10-07 13:54     ` Thierry Reding [this message]
2022-10-07 14:21       ` Robin Murphy
2022-10-07 15:22         ` Thierry Reding
2022-10-07 16:25           ` Robin Murphy
2022-09-23 12:35 ` [PATCH v9 2/5] iommu: Implement of_iommu_get_resv_regions() Thierry Reding
2022-10-07 13:47   ` Robin Murphy
2022-10-07 15:28     ` Thierry Reding
2022-10-07 16:35       ` Robin Murphy
2022-10-19 18:03   ` Thierry Reding
2022-10-20 14:34     ` Thierry Reding
2022-09-23 12:35 ` [PATCH v9 3/5] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding
2022-09-23 12:35 ` [PATCH v9 4/5] iommu/tegra-smmu: Add support for reserved regions Thierry Reding
2022-09-23 12:35 ` [PATCH v9 5/5] iommu/tegra-smmu: Support managed domains Thierry Reding
2022-10-07 13:48   ` Robin Murphy
2022-10-07 15:40     ` Thierry Reding
2022-10-07 12:51 ` [PATCH v9 0/5] iommu: Support mappings/reservations in reserved-memory regions Thierry Reding

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=Y0AvkshNYmqc3UGo@orome \
    --to=thierry.reding@gmail.com \
    --cc=alyssa.rosenzweig@collabora.com \
    --cc=asahi@lists.linux.dev \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.osipenko@collabora.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=j@jannau.net \
    --cc=joro@8bytes.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=spujar@nvidia.com \
    --cc=vdumpa@nvidia.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.