| Message ID | 20230706095841.109315-1-angelogioacchino.delregno@collabora.com |
|---|---|
| State | Accepted |
| Commit | 61b94d54421a1f3670ddd5396ec70afe833e9405 |
| Headers | show |
| Series | arm64: dts: mediatek: mt8195: Fix PM suspend/resume with venc clocks | expand |
On 06/07/2023 11:58, AngeloGioacchino Del Regno 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. Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
On Thu, Jul 6, 2023 at 5:59 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@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. > 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@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@MT8195_POWER_DOMAIN_VDEC1 { > > power-domain@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@MT8195_POWER_DOMAIN_VDEC2 { > > power-domain@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@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 > >
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@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@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@MT8195_POWER_DOMAIN_VDEC1 { >> >> power-domain@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@MT8195_POWER_DOMAIN_VDEC2 { >> >> power-domain@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@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 >> >> >
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@MT8195_POWER_DOMAIN_VDEC1 { power-domain@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@MT8195_POWER_DOMAIN_VDEC2 { power-domain@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@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";
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. 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@collabora.com> --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)