From: Liviu Dudau <liviu.dudau@arm.com>
To: Guangliu Ding <guangliu.ding@nxp.com>
Cc: "Daniel Baluta (OSS)" <daniel.baluta@oss.nxp.com>,
Daniel Almeida <daniel.almeida@collabora.com>,
Alice Ryhl <aliceryhl@google.com>,
Boris Brezillon <boris.brezillon@collabora.com>,
Steven Price <steven.price@arm.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>, Frank Li <frank.li@nxp.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"imx@lists.linux.dev" <imx@lists.linux.dev>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Jiyu Yang <jiyu.yang@nxp.com>
Subject: Re: Re: Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
Date: Thu, 2 Apr 2026 16:14:41 +0100 [thread overview]
Message-ID: <ac6H4SHdNqKEXgIK@e142607> (raw)
In-Reply-To: <AM0PR04MB470716BD5A538CFBB6685C87F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On Wed, Apr 01, 2026 at 06:03:28PM +0000, Guangliu Ding wrote:
> Hi Liviu
>
> Thanks a lot for your sharing.
>
> > On Wed, Apr 01, 2026 at 03:59:23PM +0000, Guangliu Ding wrote:
> > > Hi Liviu
> > >
> > > > On Wed, Apr 01, 2026 at 10:31:01AM +0000, Guangliu Ding wrote:
> > > > > Hi Liviu
> > > > >
> > > > > > On Wed, Apr 01, 2026 at 09:43:12AM +0000, Guangliu Ding wrote:
> > > > > > > Hi Daniel
> > > > > > >
> > > > > > > > On 4/1/26 11:48, Guangliu Ding wrote:
> > > > > > > > > [You don't often get email from guangliu.ding@nxp.com.
> > > > > > > > > Learn why this is important at
> > > > > > > > > https://aka.ms/LearnAboutSenderIdentification
> > > > > > > > > ]
> > > > > > > > >
> > > > > > > > > Hi Liviu
> > > > > > > > >
> > > > > > > > > Thanks for your review. Please refer to my comments below:
> > > > > > > > >
> > > > > > > > >> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding
> > wrote:
> > > > > > > > >>> Add compatible string of Mali G310 GPU on i.MX952 board.
> > > > > > > > >>>
> > > > > > > > >>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > > > > > > > >>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > > > > > > > >>> ---
> > > > > > > > >>>
> > > > > > > > >>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-c
> > > > > > > > >>> sf.y
> > > > > > > > >>> aml
> > > > > > > > >>> | 1
> > > > > > > > >>> +
> > > > > > > > >>> 1 file changed, 1 insertion(+)
> > > > > > > > >>>
> > > > > > > > >>> diff --git
> > > > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall
> > > > > > > > >>> -csf
> > > > > > > > >>> .yam
> > > > > > > > >>> l
> > > > > > > > >> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.
> > > > > > > > >> yaml
> > > > > > > > >>> index 8eccd4338a2b..6a10843a26e2 100644
> > > > > > > > >>> ---
> > > > > > > > >>> a/Documentation/devicetree/bindings/gpu/arm,mali-valhall
> > > > > > > > >>> -csf
> > > > > > > > >>> .yam
> > > > > > > > >>> l
> > > > > > > > >>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-val
> > > > > > > > >>> +++ hall
> > > > > > > > >>> +++ -csf
> > > > > > > > >>> +++ .yam
> > > > > > > > >>> +++ l
> > > > > > > > >>> @@ -20,6 +20,7 @@ properties:
> > > > > > > > >>> - enum:
> > > > > > > > >>> - mediatek,mt8196-mali
> > > > > > > > >>> - nxp,imx95-mali # G310
> > > > > > > > >>> + - nxp,imx952-mali # G310
> > > > > > > > >> Can you explain why this is needed? Can it not be covered
> > > > > > > > >> by the existing compatible?
> > > > > > > > > There are functional differences in GPU module (GPUMIX)
> > > > > > > > > between
> > > > > > > > > i.MX95 and i.MX952. So they cannot be fully covered by a
> > > > > > > > > single existing
> > > > > > compatible.
> > > > > > > > > On i.MX952, The GPU clock is controlled by hardware GPU
> > > > > > > > > auto clock-gating mechanism, while the GPU clock is
> > > > > > > > > managed explicitly by the
> > > > > > > > driver on i.MX95.
> > > > > > > > > Because of these behavioral differences, separate
> > > > > > > > > compatible strings "nxp,imx95-mali" and "nxp,imx952-mali"
> > > > > > > > > are needed to allow the driver to handle the two variants
> > > > > > > > > independently and to keep room for future
> > > > > > > > divergence.
> > > > > > > >
> > > > > > > >
> > > > > > > > This information should be added in the commit message
> > > > > > > > explaining why
> > > > > > > >
> > > > > > > > the change is needed.
> > > > > > > >
> > > > > > > >
> > > > > > > > But then where is the driver code taking care of these diferences?
> > > > > > > >
> > > > > > >
> > > > > > > Yes. Currently the driver does not require "nxp,imx952-mali" string.
> > > > > > > However, when GPU ipa_counters are enabled to calculate the
> > > > > > > GPU busy_time/idle_time for GPU DVFS feature, they will
> > > > > > > conflict with the hardware GPU auto clock‑gating mechanism,
> > > > > > > causing GPU clock to remain
> > > > > > always on.
> > > > > > > In such cases, ipa_counters need to be disabled so that the
> > > > > > > GPU auto clock‑gating mechanism can operate normally, using
> > > > "nxp,imx952-mali"
> > > > > > string.
> > > > > >
> > > > > > OK, I understand that you're following guidance from some other
> > > > > > senior people on how to upstream patches so you've tried to
> > > > > > create the smallest patchset to ensure that it gets reviewed and
> > > > > > accepted, but in this case we need to see the other patches as
> > > > > > well to decide if your approach is the right one and we do need
> > > > > > a separate compatible
> > > > string.
> > > > > >
> > > > > > If enabling GPU ipa_counters causes the clocks to get stuck
> > > > > > active, that feels like a hardware bug, so figuring out how to
> > > > > > handle that is more important than adding a compatible string.
> > > > > >
> > > > > > Either add the patch(es) that use the compatible to this series
> > > > > > in v2, or put a comment in the commit message on where we can
> > > > > > see the
> > > > driver changes.
> > > > > >
> > > > >
> > > > > According to discussions with the GPU vendor, this is a hardware
> > > > > limitation of Mali-G310 rather than a hardware bug, and it has
> > > > > been addressed in newer Mali GPU families.
> > > >
> > > > I represent the said GPU vendor and I think I know what you're
> > > > talking about, but you're taking the wrong approach. All G310s have
> > > > a problem where in order to enable access to the ipa_counters the
> > > > automatic clock gating gets disabled. So the solution that needs to
> > > > be implemented when we add support for IPA_COUNTERs will apply to all
> > GPUs, not just MX952.
> > >
> > > Yes. We have bring-up G310 (V2) GPU on both i.MX95 and i.MX952. And
> > > auto clock gating mechanism is firstly introduced in i.MX952 (not supported
> > on i.MX95).
> > > According to your update, solution needs to be implemented to all GPUs
> > > which support auto clock gating mechanism after IPA_COUNTERs are
> > supported in the driver, right?
> >
> > A solution is needed, yes.
> >
> > > What's your suggestions for 952 gpu dtb node?
> >
> > There is no IPA_COUNTER use in Panthor at the moment. Unless your DVFS
> > controller uses that, I would suggest that we don't introduce a compatible for
> > 952 until the time we add support for reading the counters.
> >
> > It helps if you think in terms of what is already in upstream, rather than mixing
> > with the tests that uses kbase code. Does your hardware need extra code in
> > upstream in order to function? If so, where is that code? If not, then let's not
> > introduce the compatible until we are absolutely sure we need it because we
> > have code specific to that SoC. For everything else we will implement an
> > architecture fix if needed.
> >
>
> Got it. The following compatible string is the correct choice since the GPU on
> i.MX952 is fully compatible with the GPU on i.MX95 now.
> compatible = "nxp,imx95-mali", "arm,mali-valhall-csf";
>
> I will not mix tests with kbase code in the following upstream patches for panthor driver.
OK. I think if you drop patch 2/3 from your series you can send a v3.
Best regards,
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
next prev parent reply other threads:[~2026-04-02 15:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 10:12 [PATCH 0/2] Enable Mali G310 GPU support on i.MX952 board Guangliu Ding
2026-03-31 10:12 ` [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support Guangliu Ding
2026-03-31 14:31 ` Liviu Dudau
2026-04-01 8:48 ` [EXT] " Guangliu Ding
2026-04-01 8:56 ` Krzysztof Kozlowski
2026-04-01 9:19 ` Daniel Baluta
2026-04-01 9:43 ` Guangliu Ding
2026-04-01 10:13 ` Liviu Dudau
2026-04-01 10:31 ` Guangliu Ding
2026-04-01 10:38 ` Krzysztof Kozlowski
2026-04-01 11:01 ` Guangliu Ding
2026-04-01 11:03 ` Krzysztof Kozlowski
2026-04-01 11:27 ` Guangliu Ding
2026-04-01 16:07 ` Krzysztof Kozlowski
2026-04-01 17:52 ` [EXT] " Guangliu Ding
2026-04-01 15:26 ` Liviu Dudau
2026-04-01 15:59 ` Guangliu Ding
2026-04-01 17:20 ` Liviu Dudau
2026-04-01 18:03 ` Guangliu Ding
2026-04-02 15:14 ` Liviu Dudau [this message]
2026-04-01 7:40 ` Krzysztof Kozlowski
2026-04-01 9:11 ` Guangliu Ding
2026-03-31 10:12 ` [PATCH 2/2] arm64: dts: imx952: Describe Mali G310 GPU Guangliu Ding
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=ac6H4SHdNqKEXgIK@e142607 \
--to=liviu.dudau@arm.com \
--cc=airlied@gmail.com \
--cc=aliceryhl@google.com \
--cc=boris.brezillon@collabora.com \
--cc=conor+dt@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=daniel.baluta@oss.nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=festevam@gmail.com \
--cc=frank.li@nxp.com \
--cc=guangliu.ding@nxp.com \
--cc=imx@lists.linux.dev \
--cc=jiyu.yang@nxp.com \
--cc=kernel@pengutronix.de \
--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=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=simona@ffwll.ch \
--cc=steven.price@arm.com \
--cc=tzimmermann@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.