[PATCH] arm64: dts: mediatek: mt8195: Fix PM suspend/resume with venc clocks
AngeloGioacchino Del Regno
angelogioacchino.delregno at collabora.com
Fri Jul 7 01:19:10 PDT 2023
Il 07/07/23 07:06, Chen-Yu Tsai ha scritto:
> On Thu, Jul 6, 2023 at 5:59 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno at collabora.com> wrote:
>>
>> Before suspending the LARBs we're making sure that any operation is
>> done: this never happens because we are unexpectedly unclocking the
>> LARB20 before executing the suspend handler for the MediaTek Smart
>> Multimedia Interface (SMI) and the cause of this is incorrect clocks
>> on this LARB.
>>
>> Fix this issue by changing the Local Arbiter 20 (used by the video
>> encoder secondary core) apb clock to CLK_VENC_CORE1_VENC;
>> furthermore, in order to make sure that both the PM resume and video
>> encoder operation is stable, add the CLK_VENC(_CORE1)_LARB clock to
>> the VENC (main core) and VENC_CORE1 power domains, as this IP cannot
>> communicate with the rest of the system (the AP) without local
>> arbiter clocks being operational.
>
> Somehow I feel like this is papering over some dependency issue in Linux.
>
It felt the same here, but then, if you disable the video encoder driver entirely
(or even both enc/dec drivers), you'll still get issues with the LARB20 timing out
on the SLP_PROT_RDY check, as there's something in queue going through that larb,
probably from something done by the bootloader before booting Linux.
Note that I'm pointing my finger to the bootloader because - again - even disabling
the venc entirely produces the same issue, and if you disable probing the LARB20
you will anyway get sleep issues (wakes up immediately after going to sleep).
That said, there is another possible solution to that (but even then, I think that
we still need those clock assignments that I've done here), which is to implement
the SMI power domains (mtcmos...): we'd be saving *all smi registers*, resetting an
entire SMI ctx with a poweroff, powering back on and restoring all registers *but*
larb20... at least that's the only solution that I've seen downstream (android
kernels).
...and that's why I believe that this commit is correct.
Of course, if there's something that I'm underestimating here, I'd be glad to
understand.
Cheers,
Angelo
>> Fixes: 3b5838d1d82e ("arm64: dts: mt8195: Add iommu and smi nodes")
>> Fixes: 2b515194bf0c ("arm64: dts: mt8195: Add power domains controller")
>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno at collabora.com>
>> ---
>> arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>> index 95bd058d6083..5c670fce1e47 100644
>> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>> @@ -626,6 +626,8 @@ power-domain at MT8195_POWER_DOMAIN_VDEC1 {
>>
>> power-domain at MT8195_POWER_DOMAIN_VENC_CORE1 {
>> reg = <MT8195_POWER_DOMAIN_VENC_CORE1>;
>> + clocks = <&vencsys_core1 CLK_VENC_CORE1_LARB>;
>> + clock-names = "venc1-larb";
>> mediatek,infracfg = <&infracfg_ao>;
>> #power-domain-cells = <0>;
>> };
>> @@ -688,6 +690,8 @@ power-domain at MT8195_POWER_DOMAIN_VDEC2 {
>>
>> power-domain at MT8195_POWER_DOMAIN_VENC {
>> reg = <MT8195_POWER_DOMAIN_VENC>;
>> + clocks = <&vencsys CLK_VENC_LARB>;
>> + clock-names = "venc0-larb";
>> mediatek,infracfg = <&infracfg_ao>;
>> #power-domain-cells = <0>;
>> };
>> @@ -3094,7 +3098,7 @@ larb20: larb at 1b010000 {
>> reg = <0 0x1b010000 0 0x1000>;
>> mediatek,larb-id = <20>;
>> mediatek,smi = <&smi_common_vpp>;
>> - clocks = <&vencsys_core1 CLK_VENC_CORE1_LARB>,
>> + clocks = <&vencsys_core1 CLK_VENC_CORE1_VENC>,
>> <&vencsys_core1 CLK_VENC_CORE1_GALS>,
>> <&vppsys0 CLK_VPP0_GALS_VDO0_VDO1_VENCSYS_CORE1>;
>> clock-names = "apb", "smi", "gals";
>> --
>> 2.40.1
>>
>>
>
More information about the linux-arm-kernel
mailing list