On Tue, Jul 28, 2026, Krzysztof Kozlowski wrote: > > [...] > > spacemit,k3-gpu is added to the existing ti,am62-gpu/ti,am62p-gpu/ > > ti,j721s2-gpu "if" block that restricts clocks to a single entry, > > since K3 has the same single-clock requirement. It does not match any > > "if" block that constrains power-domains, so that property falls back > > I don't get this explanation. Are you explaining what the patch is doing > or explaining WHY you did this that way?
That paragraph was describing schema mechanics, which does not belong in a commit message. v4 will drop it and state only the hardware facts: the K3 integration of the BXM-4-64 has a single "core" clock, and it has no software-controllable GPU power domain. > > to this schema's general constraints, where it is optional. This > > leaves room for a power-domains provider to be added later without a > > further binding change, should one ever be modelled in Linux for this > > SoC. > > No, you need to provide constraints now. Please read carefully > writing-bindings. Understood. spacemit,k3-gpu currently matches no power-domains "if" block, so it falls back to the top-level 1-2 domains with power-domain-names "a"/"b". That would let a K3 DT with two power domains pass validation, which does not describe this hardware. v4 will add an explicit "if" block: - if: properties: compatible: contains: const: spacemit,k3-gpu then: properties: power-domains: false power-domain-names: false The K3 integration of the BXM-4-64 has no software-controllable GPU power domain, so both properties are disallowed rather than constrained. This is the one place K3 differs from the other bxm-4-64 user: on TH1520 the GPU sits in a single unified domain, and that block stays as it is. > Do not attach (thread) your patchsets to some other threads (unrelated > or older versions). This buries them deep in the mailbox and might > interfere with applying entire sets. Sorry about that -- v2 and v3 were both sent in reply to the v1 review thread. v4 will be sent as its own top-level thread. > Why isn't this part of other enum (and remember about the alphabetical > order of entries)? > > > + - items: > > + - enum: > > + - spacemit,k3-gpu No reason -- it was simply wrong. That block is identical to the thead,th1520-gpu one apart from the SoC compatible, and the differing clock/power-domain constraints live in "allOf", not here. v4 will fold it in, in alphabetical order: - items: - enum: - spacemit,k3-gpu - thead,th1520-gpu - const: img,img-bxm-4-64 - const: img,img-rogue The DTS user, and the drm/imagination change it depends on, will be sent separately once a boot issue on the K3 board is resolved. Best regards, Baihui Liang
