[PATCH v2 1/3] dt-bindings: gpu: img,powervr-rogue: Document GX6250 GPU in Renesas R-Car M3-W/M3-W+

Matt Coster Matt.Coster at imgtec.com
Thu Oct 16 01:48:39 PDT 2025


Hi Marek,

On 15/10/2025 19:38, Marek Vasut wrote:
> On 10/15/25 6:50 PM, Matt Coster wrote:
> 
> Hello Matt,
> 
>> Would you mind splitting this conditional block up? We already have a
>> constraint for 2 power-domains (see img,img-bxs-4-64), which should be
>> applied to the entire img,img-gx6250 compatible.
> 
> I will add a patch into V3 which splits the allOf section up such,
> that clocks and power-domains limits are limited separately. That will
> make this addition of GX6250 easy.
> 
>> As for the clocks, for the currently supported GPUs, we have "mem" and
>> "sys" clocks that are optional at integration time, so those
>> conditionals are based on the vendor compatible strings (ti,... etc).
>> However, these older GPUs always require all three clocks, so it
>> probably makes sense to create the properties:clock{,-name}s:minItems:3
>> constraint on the img,img-gx6250 compatible as well, rather than the
>> renesas,r8... ones.
> 
> OK
> 
>> You shouldn't need to explicit list the power-domain descriptions at the
>> constraint level at all; if there's a build warning that they're missing
>> I guess the correct place to add them would be on the top-level
>> power-domains entry, but I don't really think they contribute anything
>> meaningful.
> The descriptions basically emulate minItems/maxItems: 2 here. I can
> also just set minItems:2 ?

I think that's probably much cleaner! We can add maxItems:2 back in
later if/when we add additional power domains at the top level.

> 
> I have one more question -- does GX6250 _always_ have two power
> domains, i.e. the constrains always set minItems:2 for
> "img,img-gx6250" "power-domains" property ?

Yes, that's correct. All PowerVR GPUs have the number of power domains
defined in the IP. Even where the SoC does not expose control of these
to the OS, the GPU still communicates with the SoC power controller
directly to gate them on and off during normal operation.

Cheers,
Matt

-- 
Matt Coster
E: matt.coster at imgtec.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20251016/d7cdff35/attachment-0001.sig>


More information about the linux-arm-kernel mailing list