From: Matt Coster <Matt.Coster@imgtec.com>
To: Michal Wilczynski <m.wilczynski@samsung.com>
Cc: Frank Binns <Frank.Binns@imgtec.com>,
Alessio Belle <Alessio.Belle@imgtec.com>,
Alexandru Dadu <Alexandru.Dadu@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>, Randolph Sapp <rs@ti.com>,
Darren Etheridge <detheridge@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>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>
Subject: Re: [PATCH v5 01/18] dt-bindings: gpu: img: Future-proofing enhancements
Date: Mon, 14 Apr 2025 09:25:50 +0000 [thread overview]
Message-ID: <2358944e-4114-4319-b2bb-0c463b18d5bb@imgtec.com> (raw)
In-Reply-To: <a9716af2-2403-44a4-b1a7-c3ab832c3c1c@samsung.com>
[-- Attachment #1.1: Type: text/plain, Size: 8825 bytes --]
On 01/04/2025 17:45, Michal Wilczynski wrote:
> On 3/26/25 17:48, Matt Coster wrote:
>> The first compatible strings added for the AXE-1-16M are not sufficient to
>> accurately describe all the IMG Rogue GPUs. The current "img,img-axe"
>> string refers to the entire family of Series AXE GPUs, but this is
>> primarily a marketing term and does not denote a level of hardware
>> similarity any greater than just "Rogue".
>>
>> The more specific "img,img-axe-1-16m" string refers to individual AXE-1-16M
>> GPU. For example, unlike the rest of the Series AXE GPUs, the AXE-1-16M
>> only uses a single power domain.
>>
>> The situation is actually slightly worse than described in the first
>> paragraph, since many "series" (such as Series BXS found in the TI AM68
>> among others and added later in this series) contain cores with both Rogue
>> and Volcanic architectures.
>>
>> Besides attempting to move away from vague groupings defined only
>> by marketing terms, we want to draw a line between properties inherent to
>> the IP core and choices made by the silicon vendor at integration time.
>> For instance, the number of power domains is a property of the IP core,
>> whereas the decision to use one or multiple clocks is a vendor one.
>
> Hi,
> We’ve had an interesting discussion on how to synchronize clock and
> reset management for the T-HEAD SoC [1] with regard to the Imagination
> GPU. Long story short, there is a preference to place SoC-specific
> elements in the generic PM driver - however since drm/imagination driver
> currently attempts to manage clocks itself, we would need to provide
> some empty stubs, which does seem like an ugly solution.
Hi Michał,
I've been following the discussions on the risc-v list, I was somewhat
hoping somebody over there would come up with a perfect solution for
this one!
I definitely agree with the inclination to package the SoC-specific
quirks up in the PM driver, that feels like the right place to isolate
it from the other device drivers. I'm not sure I see the use of stubs
(essentially just always-on clocks if I understand correctly) as ugly
here.
>
> I agree that a number of clocks is a vendor decision, but the clocks
> doesn't have to necessarily be managed from the consumer driver. Would
> you be open to a patch which makes the clock management from the
> drm/imagination driver optional ? Same way I've proposed an optional
> reset [2] previously.
The issue here is that as far as the devicetree bindings are concerned,
the GPU *does* need those clocks. Whether they can actually be
controlled by the device driver is immaterial, since the devicetree
is a description of the hardware, not the driver.
In this integration, the GPU block has three clock connections, one just
happens to not be gateable due to some SoC quirk. There isn't a real
issue for us in that sense; the only consequence of not being able to
gate off the SYS clock is that that island will consume more power when
idle.
The use of trivial clocks such as "fixed-clock" would appear to be the
appropriate way to declare this in devicetree, so that any calls gating
the affected clock would be reduced to nops.
Cheers,
Matt
>
> This way if the clocks/reset are not provided, it would be assumed that
> there is something SoC specific to how they're mangaged and they would
> be implemented in the generic PM driver.
>
> Regards,
> Michał
>
> [1] - https://lore.kernel.org/all/ef17e5d1-b364-41e1-ab8b-86140cbe69b2@samsung.com/
> [2] - https://lore.kernel.org/all/20250219140239.1378758-14-m.wilczynski@samsung.com/
>
>>
>> In the original compatible strings, we must use "ti,am62-gpu" to constrain
>> both of these properties since the number of power domains cannot be fixed
>> for "img,img-axe".
>>
>> Work is currently underway to add support for volcanic-based Imagination
>> GPUs, for which bindings will be added in "img,powervr-volcanic.yaml".
>> As alluded to previously, the split between rogue and volcanic cores is
>> non-obvious at times, so add a generic top-level "img,img-rogue" compatible
>> string here to allow for simpler differentiation in devicetrees without
>> referring back to the bindings.
>>
>> The currently supported 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.
>>
>> Also allow the dma-coherent property to be added to IMG Rogue GPUs, which
>> are DMA devices. The decision for coherency is made at integration time and
>> this property should be applied wherever it accurately describes the
>> vendor integration.
>>
>> Note that the new required properties for power domains are conditional on
>> the new base compatible string to avoid an ABI break.
>>
>> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
>> ---
>> Changes in v5:
>> - Remove extraneous (and error-causing) power-domains minItems constraint
>> - Link to v4: https://lore.kernel.org/r/20250320-sets-bxs-4-64-patch-v1-v4-1-d987cf4ca439@imgtec.com
>> Changes in v4:
>> - Add img,img-rogue back to ti,am62-gpu compatible strings to allow
>> compatibility with older kernels
>> - Revert change to power-domains property and add proper constraint
>> - Link to v3: https://lore.kernel.org/r/20250310-sets-bxs-4-64-patch-v1-v3-1-143b3dbef02f@imgtec.com
>> Changes in v3:
>> - Remove unnecessary example
>> - Remove second power domain details, add these where they're used instead
>> - Avoid ABI breaks by limiting new required properties to new compatible
>> strings and making all binding changes in a single patch.
>> - Links to v2:
>> https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-1-3fd45d9fb0cf@imgtec.com
>> https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-3-3fd45d9fb0cf@imgtec.com
>> https://lore.kernel.org/r/20241118-sets-bxs-4-64-patch-v1-v2-4-3fd45d9fb0cf@imgtec.com
>> ---
>> .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 43 +++++++++++++++++++---
>> 1 file changed, 38 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> index 256e252f8087fa0d6081f771a01601d34b66fe19..e1056bf2af84c3eb43733bdc91124a66aaf51d35 100644
>> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
>> @@ -12,10 +12,23 @@ maintainers:
>>
>> properties:
>> compatible:
>> - items:
>> - - enum:
>> - - ti,am62-gpu
>> - - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
>> + oneOf:
>> + - items:
>> + - enum:
>> + - ti,am62-gpu
>> + - const: img,img-axe-1-16m
>> + # This deprecated element must be kept around to allow old kernels to
>> + # work with newer dts.
>> + - const: img,img-axe
>> + - const: img,img-rogue
>> +
>> + # This legacy combination of compatible strings was introduced early on
>> + # before the more specific GPU identifiers were used.
>> + - items:
>> + - enum:
>> + - ti,am62-gpu
>> + - const: img,img-axe
>> + deprecated: true
>>
>> reg:
>> maxItems: 1
>> @@ -37,6 +50,12 @@ properties:
>> power-domains:
>> maxItems: 1
>>
>> + power-domain-names:
>> + items:
>> + - const: a
>> +
>> + dma-coherent: true
>> +
>> required:
>> - compatible
>> - reg
>> @@ -47,6 +66,18 @@ required:
>> additionalProperties: false
>>
>> allOf:
>> + # Constraints added alongside the new compatible strings that would otherwise
>> + # create an ABI break.
>> + - if:
>> + properties:
>> + compatible:
>> + contains:
>> + const: img,img-rogue
>> + then:
>> + required:
>> + - power-domains
>> + - power-domain-names
>> +
>> - if:
>> properties:
>> compatible:
>> @@ -64,10 +95,12 @@ examples:
>> #include <dt-bindings/soc/ti,sci_pm_domain.h>
>>
>> gpu@fd00000 {
>> - compatible = "ti,am62-gpu", "img,img-axe";
>> + compatible = "ti,am62-gpu", "img,img-axe-1-16m", "img,img-axe",
>> + "img,img-rogue";
>> reg = <0x0fd00000 0x20000>;
>> clocks = <&k3_clks 187 0>;
>> clock-names = "core";
>> interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
>> power-domains = <&k3_pds 187 TI_SCI_PD_EXCLUSIVE>;
>> + power-domain-names = "a";
>> };
>>
--
Matt Coster
E: matt.coster@imgtec.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
next prev parent reply other threads:[~2025-04-14 9:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 16:48 [PATCH v5 00/18] Imagination BXS-4-64 MC1 GPU support Matt Coster
2025-03-26 16:48 ` [PATCH v5 01/18] dt-bindings: gpu: img: Future-proofing enhancements Matt Coster
2025-03-27 7:55 ` Krzysztof Kozlowski
2025-04-01 16:45 ` Michal Wilczynski
2025-04-14 9:25 ` Matt Coster [this message]
2025-03-26 16:48 ` [PATCH v5 02/18] dt-bindings: gpu: img: Add BXS-4-64 devicetree bindings Matt Coster
2025-03-27 7:56 ` Krzysztof Kozlowski
2025-03-26 16:48 ` [PATCH v5 03/18] drm/imagination: Update register defs for newer GPUs Matt Coster
2025-04-01 13:40 ` Frank Binns
2025-03-26 16:48 ` [PATCH v5 04/18] drm/imagination: Use new generic compatible string Matt Coster
2025-03-26 16:48 ` [PATCH v5 05/18] drm/imagination: Add power domain control Matt Coster
2025-03-26 16:48 ` [PATCH v5 06/18] drm/imagination: Mask GPU IRQs in threaded handler Matt Coster
2025-03-26 16:48 ` [PATCH v5 07/18] drm/imagination: Handle Rogue safety event IRQs Matt Coster
2025-03-26 16:48 ` [PATCH v5 08/18] drm/imagination: Remove firmware enable_reg Matt Coster
2025-03-26 16:48 ` [PATCH v5 09/18] drm/imagination: Rename event_mask -> status_mask Matt Coster
2025-03-26 16:48 ` [PATCH v5 10/18] drm/imagination: Make has_fixed_data_addr a value Matt Coster
2025-03-26 16:48 ` [PATCH v5 11/18] drm/imagination: Use a lookup table for fw defs Matt Coster
2025-03-26 16:48 ` [PATCH v5 12/18] drm/imagination: Use callbacks for fw irq handling Matt Coster
2025-03-26 16:48 ` [PATCH v5 13/18] drm/imagination: Move ELF fw utils to common file Matt Coster
2025-03-26 16:48 ` [PATCH v5 14/18] drm/imagination: Add RISC-V firmware processor support Matt Coster
2025-03-26 16:48 ` [PATCH v5 15/18] drm/imagination: Use cached memory with dma_coherent Matt Coster
2025-03-26 16:48 ` [PATCH v5 16/18] drm/imagination: Add support for TI AM68 GPU Matt Coster
2025-03-26 16:48 ` [PATCH DO NOT MERGE v5 17/18] arm64: dts: ti: k3-am62: New GPU binding details Matt Coster
2025-03-26 16:48 ` [PATCH DO NOT MERGE v5 18/18] 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=2358944e-4114-4319-b2bb-0c463b18d5bb@imgtec.com \
--to=matt.coster@imgtec.com \
--cc=Alessio.Belle@imgtec.com \
--cc=Alexandru.Dadu@imgtec.com \
--cc=Frank.Binns@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=linux-riscv@lists.infradead.org \
--cc=m.wilczynski@samsung.com \
--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