From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5147223AB8D for ; Thu, 2 Apr 2026 15:15:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775142905; cv=none; b=JfYWoQ9o8BOZfAds7X5QpS22i8bgW2zc9kKMY4YbVIVMLiMCN59OGILB/IU/mXVXVrlFgNUZD3Cku8mVs2/lYKVYkEacXTZ6KMA+f1H5WP5jmzWGYcDjghKf8Y9pEzVoE7+ha3Anfvm8fNL/3+bRA9Nk42AYhy9s+Cr1C4cleIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775142905; c=relaxed/simple; bh=Wus51/A5TXZ0C83VrwImP/P+7klhk6dGV/W8j6rkqYo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RczBSbTCPV/zfYdasZPycD5+Vv5VxZji0xqC5fiPRMpHdQDdExNrjR6+OKEFmEBXtbV0nfdahBhxLh9XngJlx0r8WQ9t69fSSAXk7QZnPWhkFBJtg2qUlUSmIlFRC5Jjm6QTAWzqRU9nAdxhoOhl9Pdrmq5LJtAiYehWzDPiGxY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=amJ8x04F; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="amJ8x04F" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E66DF1596 for ; Thu, 2 Apr 2026 08:14:56 -0700 (PDT) Received: from [192.168.0.1] (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 817A83F7D8 for ; Thu, 2 Apr 2026 08:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1775142902; bh=Wus51/A5TXZ0C83VrwImP/P+7klhk6dGV/W8j6rkqYo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=amJ8x04F/KJ6PsEuK+YAdCQOCTkR5yXuAVxppUSt/wohOcjXBX7m3z11ce9D9DU02 uhFEynpAVcUjPLfhcphqalCqQanYCocND0QuhSXS0vh9tJKKT2FBiwulpmlpaZpLMr qgwltXPIwMOgdVtT+7dQhu//fLMIECpDirysRvPg= Date: Thu, 2 Apr 2026 16:14:41 +0100 From: Liviu Dudau To: Guangliu Ding Cc: "Daniel Baluta (OSS)" , Daniel Almeida , Alice Ryhl , Boris Brezillon , Steven Price , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Frank Li , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , "dri-devel@lists.freedesktop.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "imx@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , Jiyu Yang Subject: Re: Re: Re: Re: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support Message-ID: References: <99a1da55-d6e5-4d11-abaa-8c85283ab5f2@oss.nxp.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 > > > > > > > > >>> Reviewed-by: Jiyu Yang > > > > > > > > >>> --- > > > > > > > > >>> > > > > > > > > >>> 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! / --------------- ¯\_(ツ)_/¯