Re: [PATCH] clk: mediatek: Disable ACP to fix 3D on MT8192

From: Stephen Boyd <sboyd@kernel.org>
To: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-mediatek@lists.infradead.org
Cc: Michael Turquette <mturquette@baylibre.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Ikjoon Jang <ikjn@chromium.org>,
	Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	Nick Fan <Nick.Fan@mediatek.com>,
	Nicolas Boichat <drinkcat@chromium.org>
Subject: Re: [PATCH] clk: mediatek: Disable ACP to fix 3D on MT8192
Date: Fri, 14 Jan 2022 14:55:30 -0800	[thread overview]
Message-ID: <20220114225532.B0C6DC36AEA@smtp.kernel.org> (raw)
In-Reply-To: <eb6d11af-ff48-a366-d428-77bcaa250a8a@arm.com>

Quoting Robin Murphy (2022-01-14 05:23:51)
> On 2022-01-10 18:13, Alyssa Rosenzweig wrote:
> > Set a mysterious chicken bit in the MT8192 clock driver (!) to get the
> > Mali GPU on MT8192 to work. This workaround is from the downstream Mali
> > driver shipped in ChromeOS. The change there is unsuitable for mainline
> > but good as a reference for the hardware behaviour:
> > 
> > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2781271/5
> > 
> > That links to an internal Google issue tracker which I assume has more
> > information on the bug. I would appreciate if someone from Google or
> > MediaTek could explain what this change actually does and why it's
> > necessary on MT8192.
> > 
> > At any rate, this register logically belongs to the MT8192 "infra" clock
> > device, so it makes sense to set it there too. This avoids adding any
> > platform-specific hacks to the 3D driver, either mainline (Panfrost) or
> > legacy (kbase).
> 
> Does this really have anything to do with clocks? My (uninformed) 
> impression is that the infracfg blocks are general amalgamations of 
> configuration registers that simply happen to contain clock and reset 
> controls among other functionality. In particular, "ACP" usually refers 
> to the Accelerator Coherency Port of a CPU cluster or DSU, and given the 
> stated symptom of the issue affected by it, my first guess would be that 
> this bit might indeed control routing of GPU traffic either to the ACP 
> or the (presumably non-coherent) main interconnect.
> 
> If that is the case, I think this would logically belong as a 
> SoC-specific quirk in panfrost, where we'd need to retrieve the syscon 
> regmap for ourselves (see around line 800 of drivers/iommu/mtk_iommu.c 
> for a similar example).

What's the benefit of putting this into the GPU driver? Is it going to
be runtime managed? It seems most logically related to the SoC or
interconnect, for which there isn't any device driver but there could
be.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel