All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	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
Subject: Re: [PATCH v8 1/5] dt-bindings: reserved-memory: Document iommu-addresses
Date: Thu, 8 Sep 2022 17:32:47 -0500	[thread overview]
Message-ID: <20220908223247.GA3448766-robh@kernel.org> (raw)
In-Reply-To: <20220905170833.396892-2-thierry.reding@gmail.com>

On Mon, Sep 05, 2022 at 07:08:29PM +0200, 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.
> 
> Each mapping or reservation is tied to a specific device via a phandle
> to the device's device tree node. This allows a reserved-memory region
> to be reused across multiple devices.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v8:
> - include validation warning fixes that had crept into an unrelated patch
> 
> Changes in v7:
> - keep reserved-memory.txt to avoid broken references
> 
> Changes in v6:
> - add device phandle to iommu-addresses property in examples
> - remove now unused dt-bindings/reserved-memory.h header
> 
>  .../reserved-memory/reserved-memory.yaml      | 70 +++++++++++++++++++
>  1 file changed, 70 insertions(+)

Thanks for being persistent with this. It looks good to me.

Reviewed-by: Rob Herring <robh@kernel.org>

I really don't like new common bindings with only 1 user, so I hope the 
Asahi folks chime in here. Or really anyone else look at it.

Rob

  reply	other threads:[~2022-09-08 22:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-05 17:08 [PATCH v8 0/5] iommu: Support mappings/reservations in reserved-memory regions Thierry Reding
2022-09-05 17:08 ` [PATCH v8 1/5] dt-bindings: reserved-memory: Document iommu-addresses Thierry Reding
2022-09-08 22:32   ` Rob Herring [this message]
2022-09-09 14:45     ` Janne Grunau
2022-09-09 10:24   ` Robin Murphy
2022-09-05 17:08 ` [PATCH v8 2/5] iommu: Implement of_iommu_get_resv_regions() Thierry Reding
2022-09-09 10:56   ` Robin Murphy
2022-09-09 15:16     ` Janne Grunau
2022-09-09 16:10       ` Robin Murphy
2022-09-05 17:08 ` [PATCH v8 3/5] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding
2022-09-05 17:08 ` [PATCH v8 4/5] iommu/tegra-smmu: Add support for reserved regions Thierry Reding
2022-09-05 17:08 ` [PATCH v8 5/5] iommu/tegra-smmu: Support managed domains 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=20220908223247.GA3448766-robh@kernel.org \
    --to=robh@kernel.org \
    --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=robin.murphy@arm.com \
    --cc=spujar@nvidia.com \
    --cc=thierry.reding@gmail.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.