linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	 Sumit Semwal <sumit.semwal@linaro.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	 Brian Starkey <Brian.Starkey@arm.com>,
	John Stultz <jstultz@google.com>,
	 "T.J. Mercier" <tjmercier@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@redhat.com>,
	Mike Rapoport <rppt@kernel.org>,
	dri-devel@lists.freedesktop.org,  devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
	 linux-mm@kvack.org
Subject: Re: [PATCH 6/9] arm64: tegra: Add VPR placeholder node on Tegra234
Date: Thu, 4 Sep 2025 17:30:55 +0200	[thread overview]
Message-ID: <dzbefkymgrtyxfgfcdu4kq7rmgpa6khfqyhzz4a6y3qqonc4gj@yfafsqwnloia> (raw)
In-Reply-To: <20250902154630.4032984-7-thierry.reding@gmail.com>

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

On Tue, Sep 02, 2025 at 05:46:26PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> This node contains two sets of properties, one for the case where the
> VPR is resizable (in which case the VPR region will be dynamically
> allocated at boot time) and another case where the VPR is fixed in size
> and initialized by early firmware.
> 
> The firmware running on the device is responsible for updating the node
> with the real physical address for the fixed VPR case and remove the
> properties needed only for resizable VPR. Similarly, if the VPR is
> resizable, the firmware should remove the "reg" property since it is no
> longer needed.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  arch/arm64/boot/dts/nvidia/tegra234.dtsi | 34 ++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> index df034dbb8285..4d572f5fa0b1 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> @@ -28,6 +28,40 @@ aliases {
>  		i2c8 = &dp_aux_ch3_i2c;
>  	};
>  
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		vpr: video-protection-region@0 {
> +			compatible = "nvidia,tegra-video-protection-region";
> +			status = "disabled";
> +			no-map;
> +
> +			/*
> +			 * Two variants exist for this. For fixed VPR, the
> +			 * firmware is supposed to update the "reg" property
> +			 * with the fixed memory region configured as VPR.
> +			 *
> +			 * For resizable VPR we don't care about the exact
> +			 * address and instead want a reserved region to be
> +			 * allocated with a certain size and alignment at
> +			 * boot time.
> +			 *
> +			 * The firmware is responsible for removing the
> +			 * unused set of properties.
> +			 */
> +
> +			/* fixed VPR */
> +			reg = <0x0 0x0 0x0 0x0>;
> +
> +			/* resizable VPR */
> +			size = <0x0 0x70000000>;
> +			alignment = <0x0 0x100000>;
> +			reusable;
> +		};
> +	};

Hi DT maintainers,

I wanted to get some feedback on this type of placeholder DT node. This
doesn't actually validate properly because it contains properties for
both the fixed and resizable VPR variants, which are mutually exclusive.
However, the way that this currently works is that UEFI will remove and
update whatever properties need to change during boot, so the booted
kernel ends up with the correct, non-conflicting information.

The reason why it was done this way is because it simplifies the code in
UEFI to update this node. Also, without this being a placeholder I don't
know what to put into this. There's no "default" for this. One option is
to not have this in the DT at all and completely create it at boot time,
but then it becomes quite difficult to create the phandle references.

While at it, I'm not sure if I properly understand how to correctly name
a reserved-memory region that is dynamically allocated like in the case
of resizable VPR? It doesn't have a base address during boot and the
kernel will allocate memory where it sees fit. Do I just leave out the
unit-address in that case?

Thanks,
Thierry

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

  reply	other threads:[~2025-09-04 15:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-02 15:46 [PATCH 0/9] dma-buf: heaps: Add Tegra VPR support Thierry Reding
2025-09-02 15:46 ` [PATCH 1/9] dt-bindings: reserved-memory: Document Tegra VPR Thierry Reding
2025-09-03 16:45   ` Rob Herring (Arm)
2025-09-02 15:46 ` [PATCH 2/9] dt-bindings: display: tegra: Document memory regions Thierry Reding
2025-09-02 15:46 ` [PATCH 3/9] mm/cma: Allow dynamically creating CMA areas Thierry Reding
2025-09-02 17:27   ` Frank van der Linden
2025-09-02 19:04     ` David Hildenbrand
2025-09-03 16:12       ` Thierry Reding
2025-09-03 16:14         ` David Hildenbrand
2025-09-03 16:05     ` Thierry Reding
2025-09-03 16:41       ` Frank van der Linden
2025-09-04 12:06         ` Thierry Reding
2025-09-02 15:46 ` [PATCH 4/9] dma-buf: heaps: Add debugfs support Thierry Reding
2025-09-02 22:37   ` John Stultz
2025-09-03 15:38     ` Thierry Reding
2025-09-03 18:48       ` John Stultz
2025-09-04 12:04         ` Thierry Reding
2025-10-02  7:59           ` Maxime Ripard
2025-09-02 15:46 ` [PATCH 5/9] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2025-09-05  4:06   ` kernel test robot
2025-09-05  5:29   ` kernel test robot
2025-09-02 15:46 ` [PATCH 6/9] arm64: tegra: Add VPR placeholder node on Tegra234 Thierry Reding
2025-09-04 15:30   ` Thierry Reding [this message]
2025-09-02 15:46 ` [PATCH 7/9] arm64: tegra: Add GPU " Thierry Reding
2025-09-02 15:46 ` [PATCH 8/9] arm64: tegra: Hook up VPR to host1x Thierry Reding
2025-09-02 15:46 ` [PATCH 9/9] arm64: tegra: Hook up VPR to the GPU Thierry Reding
2025-09-03 11:54 ` [PATCH 0/9] dma-buf: heaps: Add Tegra VPR support David Hildenbrand

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=dzbefkymgrtyxfgfcdu4kq7rmgpa6khfqyhzz4a6y3qqonc4gj@yfafsqwnloia \
    --to=thierry.reding@gmail.com \
    --cc=Brian.Starkey@arm.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=benjamin.gaignard@collabora.com \
    --cc=conor+dt@kernel.org \
    --cc=david@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jstultz@google.com \
    --cc=krzk+dt@kernel.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=rppt@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox