[PATCH] clk: mediatek: Disable ACP to fix 3D on MT8192
AngeloGioacchino Del Regno
angelogioacchino.delregno at collabora.com
Tue Feb 15 02:44:32 PST 2022
Il 20/01/22 15:27, Alyssa Rosenzweig ha scritto:
>> We also already have SoC-specific GPU compatibles because even without
>> experimental interconnect easter eggs, people integrate these IPs in fairly
>> involved ways and there's a fair degree of variety. However unless we want
>> to be super-strict it's also not too hard to simply assume that if we can
>> find a "mediatek,mt8192-infracfg" syscon then we set the MT8192 magic bit
>> within it, and if we can't then we don't.
>
> We need a MT8192-specific compatible for the GPU anyway due to "unique"
> power management requirements, this is why the MT8183 before it has a
> specific GPU compatible. So I'm not worried about the compatible.
>
Thing is, as it was explained, this is about a unwanted SoC misconfiguration,
hence this is very specific to one SoC, which *happens to* integrate a Mali GPU.
I agree with Stephen's reasoning - also in my opinion, the panfrost driver should
be dedicated to managing the Mali GPUs and *not* the SoCs on which it is present,
so disabling the Accelerator Coherency Port for MFG should be performed inside of
files that are dealing with the specific SoC that requires this configuration (or,
if you want, quirk).
Simply put, though, as you already perfectly know, there is no driver that is
dedicated to exclusively manage the "extra" INFRA bits, so here's what I've been
thinking for a while; my logical reasoning:
- Doing it in the IOMMU driver may seem at a first glance to make some sense,
but then, does this really have anything to do with the IOMMU? I don't think so;
- Performing the disablement in mtk-pm-domains is very shady... there's nothing
that screams "power" in that;
- This doesn't scream "clocks" either, I understand that;
- As far as I understand this specific thing won't happen anymore (or at least,
not in MediaTek land, but I also don't expect to see this on other SoCs).
Getting back to MediaTek-land, only MT8192 is (and will ever be) affected, from
what I understand... and there is one driver that is very specific to, targets
only, and would probe only on MT8192 - which also happens to manage the very same
iospace that we also want to poke at to disable this bit......
... clk-mt8192!
For this reason, I think that (unfortunately, to some extent) the most transparent
and cleanest approach is the one that Alyssa took, which is to perform this
set-and-forget operation there - also keeping in mind that panfrost obviously has
no way to finish probing (hence, no way to actually use the GPU device) *before*
the driver that provides clocks to it also probes and registers .. the clocks.
My personal view on this would imply that Alyssa sends a v2 of this commit that
includes MediaTek's explanation on why the ACP has to be disabled (as much as
nicely expanding the ACP acronym as a documentation effort).
I'm sorry for this wall of text (and for boring you with it! :P), but I felt like
giving an extensive personal opinion on this would've been nice.
Thank you all!
Angelo
More information about the linux-arm-kernel
mailing list