public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, Randolph Sapp <rs@ti.com>,
	Darren Etheridge <detheridge@ti.com>
Subject: Re: [PATCH 01/21] dt-bindings: gpu: img: More explicit compatible strings
Date: Tue, 5 Nov 2024 18:13:04 +0000	[thread overview]
Message-ID: <20241105-matron-gangway-64e78576ec47@spud> (raw)
In-Reply-To: <20241105-sets-bxs-4-64-patch-v1-v1-1-4ed30e865892@imgtec.com>

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

On Tue, Nov 05, 2024 at 03:58:07PM +0000, Matt Coster wrote:
> The current compatible strings are not specific enough to constrain the
> hardware in devicetree. For example, the current "img,img-axe" string
> refers to the entire family of Series AXE GPUs. The more specific
> "img,img-axe-1-16m" string refers to the AXE-1-16M GPU which, unlike the
> rest of its family, only uses a single power domain.

That's not true, you could apply the rules using the ti,am62-gpu
compatible, no?

> Work is currently underway to add support for volcanic-based Imagination
> GPUs; also add a generic top-level "img,img-rogue" compatible string to
> allow for simpler differentiation in devicetrees.

This makes no sense, how does adding another fallback compatible make
it simpler? I have to assume that this means there will be geothermally
powered axes in the future and you want to tell the difference between
them and those pesky rogue axes that chop the heads off of naughty
children?

> 
> Make these changes now before introducing more compatible strings to keep
> the legacy versions to a minimum.
> 
> Signed-off-by: Matt Coster <matt.coster@imgtec.com>
> ---
>  .../devicetree/bindings/gpu/img,powervr-rogue.yaml    | 19 ++++++++++++++-----
>  1 file changed, 14 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..ef7070daf213277d0190fe319e202fdc597337d4 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -12,10 +12,19 @@ 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
> +          - const: img,img-rogue
> +
> +      # This legacy combination of compatible strings was introduced early on before the more
> +      # specific GPU identifiers were used. Keep it around here for compatibility, but never use
> +      # "img,img-axe" in new devicetrees.
> +      - items:
> +          - const: ti,am62-gpu
> +          - const: img,img-axe
>  
>    reg:
>      maxItems: 1
> @@ -64,7 +73,7 @@ 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-rogue";
>          reg = <0x0fd00000 0x20000>;
>          clocks = <&k3_clks 187 0>;
>          clock-names = "core";
> 
> -- 
> 2.47.0
> 

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

  reply	other threads:[~2024-11-05 18:15 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 [this message]
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
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=20241105-matron-gangway-64e78576ec47@spud \
    --to=conor@kernel.org \
    --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=frank.binns@imgtec.com \
    --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=matt.coster@imgtec.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