From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpbgeu1.qq.com (smtpbgeu1.qq.com [52.59.177.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA6FA43F8D6 for ; Wed, 29 Jul 2026 09:22:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=52.59.177.22 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785316960; cv=none; b=Wxx5Syr2MdKAS1kvKe/9VhYDG0c19QDoUeXrGkXqnfuU1mmexdGofhPNP2IBVmAae5yJoO7eeEg9uKAEQpHG1zanfGpLQ1vfi6N31w1a1S2/52yia1PsvYrFBHX6STG4gCF/9LYzNYSyOWwvTmBJjXm7+6GYaEqzwmK9/SD4klM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785316960; c=relaxed/simple; bh=IeBWTSG3cPOeoUq52Q35y9ykbiEdcoNeyqrb8LUjGf4=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=u+MmvcEZ+WHI2eNOTAUFxVnR06qTHMnkOTbCCMIjh/s+MJoq3eaDSlw9raG5t16puWWD18H+YfLHqrn5B/XRw81zkvEBRH8qK6ICu4Mb2/KZZim4ilhSZFE96lg897v7IGfW7EvKw8OxS5+zJv7rJq2SPSNYFvPwZIjeI/m7ltk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.spacemit.com; spf=none smtp.mailfrom=linux.spacemit.com; dkim=pass (1024-bit key) header.d=linux.spacemit.com header.i=@linux.spacemit.com header.b=xSzJApK/; arc=none smtp.client-ip=52.59.177.22 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux.spacemit.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.spacemit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.spacemit.com header.i=@linux.spacemit.com header.b="xSzJApK/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.spacemit.com; s=mxsw2412; t=1785316948; bh=Z8jgFnSsfsBCNp8MTSDgq+awuLrAuj0O13qIpQRlAas=; h=Mime-Version:Date:Message-Id:Subject:From:To; b=xSzJApK/oi8j+6tf5UqNzKSqW9Kr0+k1/W8VZTN+wMgAxM4MS8NGvkIbvRtm1S4YU PrftFT8grnEDRMmMuKNdC4Vsj0QSTIGEvlE55HqR7vrNM2X/Kxc/PCNrdti8FKtmfa 0Ga69p9S5pfAY9BKmVqAjChvc5f4COcpwA9g5oLI= X-QQ-mid: zesmtpgz6t1785316944t7d5426a8 X-QQ-Originating-IP: uiN5hJeyCk8Cgn2Kllv6CP7k2E6uuJH+qdj4J3W2DYo= Received: from localhost ( [120.237.158.181]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 29 Jul 2026 17:22:22 +0800 (CST) X-QQ-SSF: 0000000000000000000000000000000 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 3554096686797190771 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 29 Jul 2026 17:22:21 +0800 Message-Id: Cc: "frank.binns" , "robh" , "krzk+dt" , "conor+dt" , "dlan" , "dri-devel" , "devicetree" , "linux-kernel" , "linux-riscv" , "spacemit" Subject: Re: [PATCH v3 1/2] dt-bindings: gpu: img,powervr-rogue: add spacemit,k3-gpu From: "Baihui Liang" To: "Krzysztof Kozlowski" X-Mailer: aerc 0.17.0 References: <75c9382d2bda766aa459b00321153d715254d1a4.camel@imgtec.com> <20260728010513.1627950-1-liangbaihui@linux.spacemit.com> <20260728010513.1627950-2-liangbaihui@linux.spacemit.com> <20260728-proud-coyote-of-happiness-e99c24@quoll> In-Reply-To: <20260728-proud-coyote-of-happiness-e99c24@quoll> X-QQ-SENDSIZE: 520 Feedback-ID: zesmtpgz:linux.spacemit.com:qybglogicsvrgz:qybglogicsvrgz6b-0 X-QQ-XMAILINFO: Mg/IV5Xi+DFZaEf7gx7RvCPcqyOVubBIm8B3mhdfdSOuxQ1ahOlFD5/8 pueZLveQEMq4RXBMFVh60uKRpi3K4qQUAYVjsAR5y1pt5/5i5e63Ai2ZGfmqsZpRu4dRlSB kDQLhDQS5DQAFxvGZ8smcfsITHfQifeR3EJmOz74s6ly4qro1okGsv0RbbTxjZHxbFnfM6+ Gyw06Ld2f5J4r0dhXjadSkGYt43xtpzryN6CH+8VcWhX/NYvi7k2ouiMvD+ivnk1161TryY Js1dDMN9akeeQ4YolqbaPnIkj3aQ2W5vjTvk/MmJ3W4jrcFvSfp2R1S6YMO88d250ogD6oO ggNxvGj8pLJHSUsV8OWW97nstkmtCXIYfymVAm7t+iDHRKLwrQm+LXxE6CYUioy7e4ZrQgo OnxtBg9jmVMCPvpmpy4Sjg5b2ppyAEZ5tcWUbeL810/E6+G0rB8lszxZCoTAzweOUqbvd2g spG3evT1X2x0pvV70gDjuDaLZArxqn+ynK6tUpLeFsX8wfF8K4Znta51Cd0aFxwNbRweiUo D/C3+SiGbhhP60bKG/m+qJ9F3NmMaCd6FJftQiPMKx0U8V7/hx+ECgMUP2icxvpI8vomVac TDr9AWuh/7zF4euMAZOxRQsdR8s7QHVhgI1Z7do+NQawcMxZ2TVBgq0nuHgoHsGDGe+nTy2 TIroxUTHFOXKu7r12dQovAok7XKD2MUxYCVRyx4Q8kMRMl5g/Q1Foc/W6S6vpoA/84Ui60b 1eDF26Vxen28HyCm3Bi0ZMUNwAuNgLUvAtNFp4tYl+iBJd7BTvR9n/W5DknzSWIuEBZLE8q E4JdvluuLyllDsA+1nJH3XpD+CSJt7sm5077cxjep45MBPANY4+b0DYTUrnx++5ZgaFRCPL tEiEtY/m70oPnYVTXcEe9USBYCMYbds6kYMeGCDzK43bZZE4klAyjryMz5tJQkQKPE/xcpY 7H5T0AvyxDcDgG7Toku0TFnxOS5t+TJ+G1T/Sp1eKTJ8uCfdNlMGriP4rkoiCDdkZ0CDmM8 yOXp8qyLs3RciBj9bCHhHeZz3dzBO2tt5cpuyqLnTPMMmNAod7JbSCNL7UicQ= X-QQ-XMRINFO: NI4Ajvh11aEjEMj13RCX7UuhPEoou2bs1g== X-QQ-RECHKSPAM: 0 On Tue Jul 28, 2026 at 4:07 PM CST, Krzysztof Kozlowski wrote: > On Tue, Jul 28, 2026 at 09:05:12AM +0800, Sterling-Ash wrote: > > Add a compatible string for the IMG BXM-4-64 GPU integrated into the > > SpacemiT K3 SoC. It shares the same core as thead,th1520-gpu but is > > kept as a separate compatible entry, since the K3 integration differs > > from TH1520 in its clock and power-domain requirements: K3 has a > > single "core" clock rather than three, and its GPU power domain is > > enabled by the bootloader before Linux boots rather than being > > modelled and switched by Linux, so no power-domains property is > > required for this platform (unlike the other img,img-bxm-4-64 user). > >=20 > > 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. > >=20 > > Signed-off-by: Sterling-Ash > > --- > > 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. See also: > https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/s= ubmitting-patches.rst#L830 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. > > v3: also add spacemit,k3-gpu to the existing ti,am62-gpu/ti,am62p-gpu/ > > ti,j721s2-gpu "if" block restricting clocks to a single entry -- > > previously it fell back to this schema's general clocks constraint > > (1-3 items), which would have let an invalid DT with 2 or 3 clocks > > pass validation (found by automated review on v2). > >=20 > > .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 6 ++++++ > > 1 file changed, 6 insertions(+) > >=20 > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.ya= ml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > index a1f54dbae3f3..d29f0d163b91 100644 > > --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml > > @@ -38,6 +38,11 @@ properties: > > - thead,th1520-gpu > > - const: img,img-bxm-4-64 > > - const: img,img-rogue > > + - items: > > + - enum: > > + - spacemit,k3-gpu > > Why isn't this part of other enum (and remember about the alphabetical > order of entries)? 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, > Krzysztof Best regards, Baihui Liang