From: Conor Dooley <conor@kernel.org>
To: Matt Coster <Matt.Coster@imgtec.com>
Cc: Frank Binns <Frank.Binns@imgtec.com>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Nishanth Menon <nm@ti.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>, Randolph Sapp <rs@ti.com>,
Darren Etheridge <detheridge@ti.com>
Subject: Re: [PATCH 03/21] dt-bindings: gpu: img: Power domain details
Date: Wed, 6 Nov 2024 18:28:51 +0000 [thread overview]
Message-ID: <20241106-embassy-busload-2093b80d012a@spud> (raw)
In-Reply-To: <ff4e96e4-ebc2-4c50-9715-82ba3d7b8612@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 3111 bytes --]
On Wed, Nov 06, 2024 at 10:18:01AM +0000, Matt Coster wrote:
> On 05/11/2024 18:13, Conor Dooley wrote:
> > On Tue, Nov 05, 2024 at 06:05:54PM +0000, Conor Dooley wrote:
> >> On Tue, Nov 05, 2024 at 03:58:09PM +0000, Matt Coster wrote:
> >>> The single existing GPU (AXE-1-16M) only requires a single power domain.
> >>> Subsequent patches will add support for BXS-4-64 MC1, which has two power
> >>> domains. Add infrastructure now to allow for this.
> >>>
> >>> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
> >>> ---
> >>> .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 29 +++++++++++++++++++++-
> >>> 1 file changed, 28 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> >>> index 6924831d3e9dd9b2b052ca8f9d7228ff25526532..55f422be1bc5b7564e3e81f24c4b93857f3e12fe 100644
> >>> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> >>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> >>> @@ -49,7 +49,16 @@ properties:
> >>> maxItems: 1
> >>>
> >>> power-domains:
> >>> - maxItems: 1
> >>> + minItems: 1
> >>> + maxItems: 2
> >>> +
> >>> + power-domain-names:
> >>> + oneOf:
> >>> + - items:
> >>> + - const: a
> >>> + - items:
> >>> + - const: a
> >>> + - const: b
> >
> > Additionally, a & b? Are those actually the names for the power domains?
>
> Sadly yes, Rogue has power domains that are literally just A, B, etc. I
> wouldn't believe me either; the attached image is taken directly from
> the documentation for BXS-4-64.
heh, nice... Also - if you have the oneOf stuff here for the same reason
as the locks, the same logic with min/maxItems applies here.
>
> >>>
> >>> required:
> >>> - compatible
> >>> @@ -57,10 +66,27 @@ required:
> >>> - clocks
> >>> - clock-names
> >>> - interrupts
> >>> + - power-domains
> >>> + - power-domain-names
> >>
> >> A new required property is an ABI break. Please explain why this is
> >> acceptable in your commit message.
>
> Strictly it's only necessary for multi-domain GPUs, or perhaps in
> instances where the SoC power controller already enforces the
> dependencies between power domains. In reality, I think it was simply an
> oversight not to enfore this requirement in the first place. We have
> very, very few cores that require <2 power domains so names are always
> required if domains are enumerated in dt.
>
> Would you prefer we drop the requirement for "power-domains" and gate
> the requirement for "power-domain-names" behind >2 domains, or just
> explain the change properly and make the ABI break now while only one
> core is supported?
I dunno, depends really on whether or not it is possible to have power
domain "a" and domain "c" in a rogue gpu. If "a" and "b" is all it will
ever be, the order is fixed by the binding and you can do
genpd_dev_pm_attach_by_id() instead of genpd_dev_pm_attach_by_name().
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-11-06 18:30 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 15:58 [PATCH 00/21] Imagination BXS-4-64 MC1 GPU support Matt Coster
2024-11-05 15:58 ` [PATCH 01/21] dt-bindings: gpu: img: More explicit compatible strings Matt Coster
2024-11-05 18:13 ` Conor Dooley
2024-11-06 10:17 ` Matt Coster
2024-11-06 16:57 ` Conor Dooley
2024-11-05 15:58 ` [PATCH 02/21] dt-bindings: gpu: img: Further constrain clocks Matt Coster
2024-11-05 18:16 ` Conor Dooley
2024-11-06 10:17 ` Matt Coster
2024-11-06 17:06 ` Conor Dooley
2024-11-05 15:58 ` [PATCH 03/21] dt-bindings: gpu: img: Power domain details Matt Coster
2024-11-05 18:05 ` Conor Dooley
2024-11-05 18:13 ` Conor Dooley
2024-11-06 10:18 ` Matt Coster
2024-11-06 18:28 ` Conor Dooley [this message]
2024-11-05 15:58 ` [PATCH 04/21] dt-bindings: gpu: img: Allow dma-coherent Matt Coster
2024-11-05 18:06 ` Conor Dooley
2024-11-06 10:18 ` Matt Coster
2024-11-06 18:30 ` Conor Dooley
2024-11-06 19:28 ` Andrew Davis
2024-11-05 15:58 ` [PATCH 05/21] drm/imagination: Use more specific compatible strings Matt Coster
2024-11-05 15:58 ` [PATCH 06/21] drm/imagination: Add power domain control Matt Coster
2024-11-05 15:58 ` [PATCH 07/21] arm64: dts: ti: k3-am62: New GPU binding details Matt Coster
2024-11-05 15:58 ` [PATCH 08/21] dt-bindings: gpu: img: Add BXS-4-64 devicetree bindings Matt Coster
2024-11-05 18:03 ` Conor Dooley
2024-11-06 10:18 ` Matt Coster
2024-11-06 18:33 ` Conor Dooley
2024-11-05 15:58 ` [PATCH 09/21] drm/imagination: Revert to non-threaded IRQs Matt Coster
2024-11-05 15:58 ` [PATCH 10/21] drm/imagination: Remove firmware enable_reg Matt Coster
2024-11-05 15:58 ` [PATCH 11/21] drm/imagination: Rename event_mask -> status_mask Matt Coster
2024-11-05 15:58 ` [PATCH 12/21] drm/imagination: Make has_fixed_data_addr a value Matt Coster
2024-11-05 15:58 ` [PATCH 13/21] drm/imagination: Use a lookup table for fw defs Matt Coster
2024-11-05 15:58 ` [PATCH 14/21] drm/imagination: Use callbacks for fw irq handling Matt Coster
2024-11-05 15:58 ` [PATCH 15/21] drm/imagination: Add register required for RISC-V firmware Matt Coster
2024-11-05 15:58 ` [PATCH 16/21] drm/imagination: Move ELF fw utils to common file Matt Coster
2024-11-05 15:58 ` [PATCH 17/21] drm/imagination: Add RISC-V firmware processor support Matt Coster
2024-11-05 15:58 ` [PATCH 18/21] drm/imagination: Add platform overrides infrastructure Matt Coster
2024-11-05 15:58 ` [PATCH 19/21] drm/imagination: Add device_memory_force_cpu_cached override Matt Coster
2024-11-05 15:58 ` [PATCH 20/21] drm/imagination: Add support for TI AM68 GPU Matt Coster
2024-11-05 15:58 ` [PATCH 21/21] arm64: dts: ti: k3-j721s2: Add GPU node Matt Coster
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=20241106-embassy-busload-2093b80d012a@spud \
--to=conor@kernel.org \
--cc=Frank.Binns@imgtec.com \
--cc=Matt.Coster@imgtec.com \
--cc=airlied@gmail.com \
--cc=conor+dt@kernel.org \
--cc=detheridge@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kristo@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=rs@ti.com \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
--cc=vigneshr@ti.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