All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Jon Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 1/7] dt-bindings: display: simple-framebuffer: Support system memory framebuffers
Date: Mon, 17 Oct 2022 16:38:54 +0200	[thread overview]
Message-ID: <Y01o/ktQGO430tc6@orome> (raw)
In-Reply-To: <44567457-2062-6e16-9a7f-c4ad23809ac9@suse.de>

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

On Mon, Oct 10, 2022 at 11:37:37AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > In order to support framebuffers residing in system memory, allow the
> > memory-region property to override the framebuffer memory specification
> > in the "reg" property.
> 
> What happens if both properties are present and they disagree with each
> other?
> 
> I understand that the framebuffer is behind 'memory-region', but does 'reg'
> still contain device memory?  Do we need to acquire ownership from within
> the driver?

The intention is for both memory-region and reg properties to be
mutually exclusive. I can't think of a scenario where you would need or
want both.

Note also the documentation for the memory-region property:

|  memory-region:
|    maxItems: 1
|    description: Phandle to a node describing the memory to be used for the
|      framebuffer. If present, overrides the "reg" property (if one exists).

Thierry

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

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org, David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Jon Hunter <jonathanh@nvidia.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-tegra@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v2 1/7] dt-bindings: display: simple-framebuffer: Support system memory framebuffers
Date: Mon, 17 Oct 2022 16:38:54 +0200	[thread overview]
Message-ID: <Y01o/ktQGO430tc6@orome> (raw)
In-Reply-To: <44567457-2062-6e16-9a7f-c4ad23809ac9@suse.de>

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

On Mon, Oct 10, 2022 at 11:37:37AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 07.10.22 um 14:49 schrieb Thierry Reding:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > In order to support framebuffers residing in system memory, allow the
> > memory-region property to override the framebuffer memory specification
> > in the "reg" property.
> 
> What happens if both properties are present and they disagree with each
> other?
> 
> I understand that the framebuffer is behind 'memory-region', but does 'reg'
> still contain device memory?  Do we need to acquire ownership from within
> the driver?

The intention is for both memory-region and reg properties to be
mutually exclusive. I can't think of a scenario where you would need or
want both.

Note also the documentation for the memory-region property:

|  memory-region:
|    maxItems: 1
|    description: Phandle to a node describing the memory to be used for the
|      framebuffer. If present, overrides the "reg" property (if one exists).

Thierry

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

  reply	other threads:[~2022-10-17 14:39 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-07 12:49 [PATCH v2 0/7] drm/simpledrm: Support system memory framebuffers Thierry Reding
2022-10-07 12:49 ` Thierry Reding
2022-10-07 12:49 ` [PATCH v2 1/7] dt-bindings: display: simple-framebuffer: " Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-07 14:00   ` Rob Herring
2022-10-07 14:00     ` Rob Herring
2022-10-10  9:37   ` Thomas Zimmermann
2022-10-10  9:37     ` Thomas Zimmermann
2022-10-17 14:38     ` Thierry Reding [this message]
2022-10-17 14:38       ` Thierry Reding
2022-10-07 12:49 ` [PATCH v2 2/7] dt-bindings: display: simple-framebuffer: Document 32-bit BGR format Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-07 14:01   ` Rob Herring
2022-10-07 14:01     ` Rob Herring
2022-10-07 12:49 ` [PATCH v2 3/7] dt-bindings: reserved-memory: Support framebuffer reserved memory Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-07 14:01   ` Rob Herring
2022-10-07 14:01     ` Rob Herring
2022-10-07 12:49 ` [PATCH v2 4/7] drm/simpledrm: Add support for system memory framebuffers Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-10  8:12   ` Thomas Zimmermann
2022-10-10  8:12     ` Thomas Zimmermann
2022-10-17 14:54     ` Thierry Reding
2022-10-17 14:54       ` Thierry Reding
2022-10-17 18:15       ` Rob Herring
2022-10-17 18:15         ` Rob Herring
2022-10-18 10:46         ` Thierry Reding
2022-10-18 10:46           ` Thierry Reding
2022-10-18 15:32           ` Rob Herring
2022-10-18 15:32             ` Rob Herring
2022-10-18 11:58       ` Thomas Zimmermann
2022-10-18 11:58         ` Thomas Zimmermann
2022-10-18 15:13         ` Thierry Reding
2022-10-18 15:13           ` Thierry Reding
2022-10-19 12:25   ` Thomas Zimmermann
2022-10-19 12:25     ` Thomas Zimmermann
2022-10-07 12:49 ` [PATCH v2 5/7] drm/format-helper: Support the XB24 format Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-07 12:49 ` [PATCH v2 6/7] drm/simpledrm: Support the XB24/AB24 format Thierry Reding
2022-10-07 12:49   ` Thierry Reding
2022-10-07 12:49 ` [PATCH v2 7/7] arm64: tegra: Add simple framebuffer on Jetson Xavier NX Thierry Reding
2022-10-07 12:49   ` 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=Y01o/ktQGO430tc6@orome \
    --to=thierry.reding@gmail.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=tzimmermann@suse.de \
    /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.