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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 177F9C53200 for ; Wed, 29 Jul 2026 09:23:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:References:To:From:Subject: Cc:Message-Id:Date:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NcBskUS0QuxF3AQJWVYbUmlO6O9wU1K6Ds+UVrXwF3Y=; b=AECUzNN+IrFH6A I586kyexz4c7oKFNawghIUOmlapLvH0I8mMNu5hMOAvYSPeG2iDBoEagjCtDs1ChZ1z2c8gas0ZZ4 mP8ur9/uyHkpSkE54YZkQY8f1LtIiOqmlSKP7CoyjGarsizU93DGW3pN3+iGem8Hvaa+dTq0J14CZ Bvq9pETogaNtS3+qZr+ko3tjCNakEnqbA9BogywrVwVM5q16KmoWN4vOxYGIXJEa4hd7q69DQ2KRf KcI0duAyUQ4KXZzwOk/+jK/T1YdJUFsAlk00DhNEkirjxiRDVMcWBLHimbZ/CplVCQfqI5pv2uS6B A/P2mzQ9U9tUfJTSz0yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wp0VP-00000007M77-133m; Wed, 29 Jul 2026 09:23:15 +0000 Received: from smtpbgau1.qq.com ([54.206.16.166]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wp0VL-00000007M49-3WzT for linux-riscv@lists.infradead.org; Wed, 29 Jul 2026 09:23:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.spacemit.com; s=mxsw2412; t=1785316953; bh=Z8jgFnSsfsBCNp8MTSDgq+awuLrAuj0O13qIpQRlAas=; h=Mime-Version:Date:Message-Id:Subject:From:To; b=A/Eu0FLnd/l5zV9WJ3K2ZGV+AHKJQYTJMGs5UkVIIxpzfg/ePGrbJJByZjmrS78Bu PmGV9TiGKZcNryCuUZDyzLMByKWQT3KUBhlBry2t2gsP8l7Tadf/Bmmu98B0BszGyc g1yQw1Gmj3hBDYX44YIZhTdJTq1q3ZejX6/0lypk= 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 Mime-Version: 1.0 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: NT1GeB58nkv+mzDjZP/id+gTZoP6XTyxXhcCU83WSNEiw5+vi09e/sWr zJmBGCiHvwFfUATXeI0QI2yjz353BV9HXLrvndAtMzNczWAuS6oaYTG3RPmKGg3R2pV+qU3 k32GeRLUrNUzkdwASKFUYLcFKSzTylueffeD62lO7I6WM0Vvp9ExkDHa/HZV48sdtfR26V/ pkx1BjVE6/u5/CAZU58eLp2NA2d7P9VGR+s134G6lhohcH85uaaAHSFppk/TNNHTrIYKkXb qR0NFxM1bh7WaObvWDNSlhLhfU2hv/qzLm8GxI9bOWoIqE+0WcZuLC6U4O9YUk1ln4ceeEY svVlekVtd2E6/zcY3G5xauAOwNYUCvNlR0oc8qscR9cri0Q+5kirgjJSdNirbuDsMjXppCt HtI1WVxTGN82KPXy9ELJ/M6bjmm8hqZcl7qz9KT9M/5nPOyoQDYXuAnF8qQEhg3vBpCY7bQ QFUvLNRnIDABocRVYkGpV1L/HQ3ry2Ez4ifkZ8tKs9m8EclKibb8j382DDlkm9Rwn3VqNgy 4Ixy2wJe90P/yk7aFcAlOJBDk/TTLZIQmhp9UaJXJ+VW+pHRaaM3tKNh3nTtQNL4MGAHCS6 baIZCDYpSoVzjFhcNc9LxlZMZvKmGMUCBctfQPGnF881nESu77ZZkY4txcKxyBMdLS7hSPH ALtIxbBeCTZVrjcII7onljISfwNRy3rtdsZ81UbVlJQSQlwP/mlPhAHcchDxORSR4XimCkC qUEGrIsOROD2ch9WlxUx4pc28aap72OsTue7IyqSy4F2p7KWRBmzO5bUvV+a3q1+BmCfiwN eQRVpXO4FLxl6xTBOWgv9JmtQjTn832pCRG/pD0/s9RA7ayhINtdHgMimsacgU6Qrc6dt7G e/2+JB0mimd0NGwsMcGzt5ugpR3d56biZKObrPr3IylJSDWXJy9IE/T5bc//5hoEY4LU7qs JpBQvGDSuOAMxhRR2LeFrXm1P5dnpHiFLMne/U2mWKBzyt72GMG/wg3CJK5t/3dOOhSGWpz Q1KSLU2INxcYQ/FMe6BwGWWbdSa2DDBTPqBzeNqKFWpDmwXONrRACxVw5zIQ4= X-QQ-XMRINFO: NS+P29fieYNwqS3WCnRCOn9D1NpZuCnCRA== X-QQ-RECHKSPAM: 0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260729_022312_256563_578C49CC X-CRM114-Status: GOOD ( 32.95 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org 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). > > > > 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. > > > > 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/submitting-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). > > > > .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml 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 _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv