| Message ID | 20240627-hdmi-tx-v5-4-355d5c1fbc3c@freebox.fr |
|---|---|
| State | Superseded |
| Headers | show |
| Series | HDMI TX support in msm8998 | expand |
On 27.06.2024 5:54 PM, Marc Gonzalez wrote: > From: Arnaud Vrac <avrac@freebox.fr> > > Port device nodes from vendor code. > > Signed-off-by: Arnaud Vrac <avrac@freebox.fr> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr> > --- > arch/arm64/boot/dts/qcom/msm8998.dtsi | 100 +++++++++++++++++++++++++++++++++- > 1 file changed, 99 insertions(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi > index ba5e873f0f35f..417c12534823f 100644 > --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi > +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi > @@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c0000 { > <&mdss_dsi0_phy 0>, > <&mdss_dsi1_phy 1>, > <&mdss_dsi1_phy 0>, > - <0>, > + <&hdmi_phy 0>, > <0>, > <0>, > <&gcc GCC_MMSS_GPLL0_DIV_CLK>; > @@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint { > remote-endpoint = <&mdss_dsi1_in>; > }; > }; > + > + port@2 { > + reg = <2>; > + > + dpu_intf3_out: endpoint { > + remote-endpoint = <&hdmi_in>; > + }; > + }; > }; > }; > > @@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 { > > status = "disabled"; > }; > + > + hdmi: hdmi-tx@c9a0000 { Please prefix the labels (hdmi: and hdmi_phy:) with mdss_ Otherwise, this looks good Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> One thing I noticed (testing on the 8998 MTP), enabling MDSS (not necessarily HDMI, mdss and mdp is enough) results in SMMU lockups about 30% of the time.. [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.913412] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.930647] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000 [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.952338] msm_hdmi_phy c9a0600.hdmi-phy: supply vddio not found, using dummy regulator [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.967917] msm_hdmi_phy c9a0600.hdmi-phy: supply vcca not found, using dummy regulator [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.984122] Bluetooth: hci0: setting up wcn399x [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] Konrad
On 16/07/2024 15:11, Konrad Dybcio wrote: > On 27.06.2024 5:54 PM, Marc Gonzalez wrote: > >> arch/arm64/boot/dts/qcom/msm8998.dtsi | 100 +++++++++++++++++++++++++++++++++- >> 1 file changed, 99 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi >> index ba5e873f0f35f..417c12534823f 100644 >> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi >> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi >> @@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c0000 { >> <&mdss_dsi0_phy 0>, >> <&mdss_dsi1_phy 1>, >> <&mdss_dsi1_phy 0>, >> - <0>, >> + <&hdmi_phy 0>, >> <0>, >> <0>, >> <&gcc GCC_MMSS_GPLL0_DIV_CLK>; >> @@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint { >> remote-endpoint = <&mdss_dsi1_in>; >> }; >> }; >> + >> + port@2 { >> + reg = <2>; >> + >> + dpu_intf3_out: endpoint { >> + remote-endpoint = <&hdmi_in>; >> + }; >> + }; >> }; >> }; >> >> @@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 { >> >> status = "disabled"; >> }; >> + >> + hdmi: hdmi-tx@c9a0000 { > > Please prefix the labels (hdmi: and hdmi_phy:) with mdss_ > > Otherwise, this looks good > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > One thing I noticed (testing on the 8998 MTP), enabling MDSS (not necessarily > HDMI, mdss and mdp is enough) results in SMMU lockups about 30% of the time.. > > [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.913412] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 > [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.930647] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000 > [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.952338] msm_hdmi_phy c9a0600.hdmi-phy: supply vddio not found, using dummy regulator > [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.967917] msm_hdmi_phy c9a0600.hdmi-phy: supply vcca not found, using dummy regulator > [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.984122] Bluetooth: hci0: setting up wcn399x > [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] Interesting. I don't think I've noticed any lock-ups across multiple reboots. FWIW, I get similar warnings about "Fixed dependency cycle(s)" on my custom DT. [ 0.055349] platform 1da4000.ufshc: Fixed dependency cycle(s) with /soc@0/phy@1da7000 [ 0.055525] platform 1da4000.ufshc: Fixed dependency cycle(s) with /soc@0/phy@1da7000 [ 0.055584] platform 1da7000.phy: Fixed dependency cycle(s) with /soc@0/ufshc@1da4000 [ 0.060279] platform c8c0000.clock-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-phy@c9a0600 [ 0.060494] platform c900000.display-subsystem: Fixed dependency cycle(s) with /soc@0/clock-controller@c8c0000 [ 0.062432] platform hdmi-out: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e ... [ 18.534346] adreno 5000000.gpu: Adding to iommu group 2 [ 18.540215] msm-mdss c900000.display-subsystem: Adding to iommu group 3 [ 18.544695] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 [ 18.551239] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 [ 18.562685] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e [ 18.574122] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000 [ 18.617640] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e [ 18.618885] i2c 2-005e: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 [ 18.627768] tdp158-bridge 2-005e: supply vcc not found, using dummy regulator [ 18.636853] tdp158-bridge 2-005e: supply vdd not found, using dummy regulator It looks like some of these warnings were pre-existing, but some might have been added by my patches? Do they need looking into? I'm slightly confused. Regards
On Tue, 16 Jul 2024 at 17:34, Marc Gonzalez <mgonzalez@freebox.fr> wrote: > > On 16/07/2024 15:11, Konrad Dybcio wrote: > > > On 27.06.2024 5:54 PM, Marc Gonzalez wrote: > > > >> arch/arm64/boot/dts/qcom/msm8998.dtsi | 100 +++++++++++++++++++++++++++++++++- > >> 1 file changed, 99 insertions(+), 1 deletion(-) > >> > >> diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi > >> index ba5e873f0f35f..417c12534823f 100644 > >> --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi > >> +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi > >> @@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c0000 { > >> <&mdss_dsi0_phy 0>, > >> <&mdss_dsi1_phy 1>, > >> <&mdss_dsi1_phy 0>, > >> - <0>, > >> + <&hdmi_phy 0>, > >> <0>, > >> <0>, > >> <&gcc GCC_MMSS_GPLL0_DIV_CLK>; > >> @@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint { > >> remote-endpoint = <&mdss_dsi1_in>; > >> }; > >> }; > >> + > >> + port@2 { > >> + reg = <2>; > >> + > >> + dpu_intf3_out: endpoint { > >> + remote-endpoint = <&hdmi_in>; > >> + }; > >> + }; > >> }; > >> }; > >> > >> @@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 { > >> > >> status = "disabled"; > >> }; > >> + > >> + hdmi: hdmi-tx@c9a0000 { > > > > Please prefix the labels (hdmi: and hdmi_phy:) with mdss_ > > > > Otherwise, this looks good > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > > > One thing I noticed (testing on the 8998 MTP), enabling MDSS (not necessarily > > HDMI, mdss and mdp is enough) results in SMMU lockups about 30% of the time.. > > > > [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > > [ 4.913412] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 > > [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > > [ 4.930647] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000 > > [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > > [ 4.952338] msm_hdmi_phy c9a0600.hdmi-phy: supply vddio not found, using dummy regulator > > [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > > [ 4.967917] msm_hdmi_phy c9a0600.hdmi-phy: supply vcca not found, using dummy regulator > > [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > > [ 4.984122] Bluetooth: hci0: setting up wcn399x > > [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > Interesting. I don't think I've noticed any lock-ups > across multiple reboots. > > FWIW, I get similar warnings about "Fixed dependency cycle(s)" on my custom DT. > > [ 0.055349] platform 1da4000.ufshc: Fixed dependency cycle(s) with /soc@0/phy@1da7000 > [ 0.055525] platform 1da4000.ufshc: Fixed dependency cycle(s) with /soc@0/phy@1da7000 > [ 0.055584] platform 1da7000.phy: Fixed dependency cycle(s) with /soc@0/ufshc@1da4000 > [ 0.060279] platform c8c0000.clock-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-phy@c9a0600 > [ 0.060494] platform c900000.display-subsystem: Fixed dependency cycle(s) with /soc@0/clock-controller@c8c0000 > [ 0.062432] platform hdmi-out: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e > ... > [ 18.534346] adreno 5000000.gpu: Adding to iommu group 2 > [ 18.540215] msm-mdss c900000.display-subsystem: Adding to iommu group 3 > [ 18.544695] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 > [ 18.551239] platform c901000.display-controller: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 > [ 18.562685] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e > [ 18.574122] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/display-controller@c901000 > [ 18.617640] platform c9a0000.hdmi-tx: Fixed dependency cycle(s) with /soc@0/i2c@c1b5000/tdp158@5e > [ 18.618885] i2c 2-005e: Fixed dependency cycle(s) with /soc@0/display-subsystem@c900000/hdmi-tx@c9a0000 > [ 18.627768] tdp158-bridge 2-005e: supply vcc not found, using dummy regulator > [ 18.636853] tdp158-bridge 2-005e: supply vdd not found, using dummy regulator > > It looks like some of these warnings were pre-existing, > but some might have been added by my patches? > > Do they need looking into? > I'm slightly confused. No, that's fine. It is the SMMU issue that Konrad has been asking you to take a look at.
On 16/07/2024 18:37, Dmitry Baryshkov wrote: > No, that's fine. It is the SMMU issue that Konrad has been asking you > to take a look at. Context: [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] As I mentioned, I don't think I've ever seen issues from cd00000.iommu on my board. I can test a reboot loop for a few hours, to see if anything shows up. Regards
On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez <mgonzalez@freebox.fr> wrote: > > On 16/07/2024 18:37, Dmitry Baryshkov wrote: > > > No, that's fine. It is the SMMU issue that Konrad has been asking you > > to take a look at. > > Context: > > [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > > > As I mentioned, I don't think I've ever seen issues from cd00000.iommu > on my board. Interestingly enough, I can also see iommu errors during WiFi startup / shutdown on msm8998 / miix630. This leads me to thinking that it well might be that there is a missing quirk in the iommu driver. > > I can test a reboot loop for a few hours, to see if anything shows up. Yes, pleas.
On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: > On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez <mgonzalez@freebox.fr> wrote: >> >> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >> >>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>> to take a look at. >> >> Context: >> >> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >> >> >> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >> on my board. > > Interestingly enough, I can also see iommu errors during WiFi startup > / shutdown on msm8998 / miix630. This leads me to thinking that it > well might be that there is a missing quirk in the iommu driver. > >> >> I can test a reboot loop for a few hours, to see if anything shows up. > > Yes, pleas. Yeah I do trust you Marc that it actually works for you and I'm not gonna delay this series because of that, but please go ahead and reboot-loop your board 8998/660 is """famous""" for it's iommu problems Konrad
On 23/07/2024 13:45, Konrad Dybcio wrote: > On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: > >> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: >> >>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >>> >>>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>>> to take a look at. >>> >>> Context: >>> >>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>> >>> >>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >>> on my board. >> >> Interestingly enough, I can also see iommu errors during WiFi startup >> / shutdown on msm8998 / miix630. This leads me to thinking that it >> well might be that there is a missing quirk in the iommu driver. >> >>> I can test a reboot loop for a few hours, to see if anything shows up. >> >> Yes, please. > > Yeah I do trust you Marc that it actually works for you and I'm not > gonna delay this series because of that, but please go ahead and > reboot-loop your board > > 8998/660 is """famous""" for it's iommu problems [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 I get the above warning pretty reliably. I don't think it's related to the issue(s) you mentioned. System just keeps plodding along. Regards
On 23.07.2024 2:57 PM, Marc Gonzalez wrote: > On 23/07/2024 13:45, Konrad Dybcio wrote: > >> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: >> >>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: >>> >>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >>>> >>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>>>> to take a look at. >>>> >>>> Context: >>>> >>>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>> >>>> >>>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >>>> on my board. >>> >>> Interestingly enough, I can also see iommu errors during WiFi startup >>> / shutdown on msm8998 / miix630. This leads me to thinking that it >>> well might be that there is a missing quirk in the iommu driver. >>> >>>> I can test a reboot loop for a few hours, to see if anything shows up. >>> >>> Yes, please. >> >> Yeah I do trust you Marc that it actually works for you and I'm not >> gonna delay this series because of that, but please go ahead and >> reboot-loop your board >> >> 8998/660 is """famous""" for it's iommu problems > > [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 > > I get the above warning pretty reliably. > I don't think it's related to the issue(s) you mentioned. > System just keeps plodding along. Yeah that one's "fine" Konrad
On Tue, 23 Jul 2024 at 15:57, Marc Gonzalez <mgonzalez@freebox.fr> wrote: > > On 23/07/2024 13:45, Konrad Dybcio wrote: > > > On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: > > > >> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: > >> > >>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: > >>> > >>>> No, that's fine. It is the SMMU issue that Konrad has been asking you > >>>> to take a look at. > >>> > >>> Context: > >>> > >>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > >>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > >>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > >>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > >>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > >>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > >>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > >>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > >>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 > >>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] > >>> > >>> > >>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu > >>> on my board. > >> > >> Interestingly enough, I can also see iommu errors during WiFi startup > >> / shutdown on msm8998 / miix630. This leads me to thinking that it > >> well might be that there is a missing quirk in the iommu driver. > >> > >>> I can test a reboot loop for a few hours, to see if anything shows up. > >> > >> Yes, please. > > > > Yeah I do trust you Marc that it actually works for you and I'm not > > gonna delay this series because of that, but please go ahead and > > reboot-loop your board > > > > 8998/660 is """famous""" for it's iommu problems > > [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 I think 0x1900 is WiFi. > > I get the above warning pretty reliably. > I don't think it's related to the issue(s) you mentioned. > System just keeps plodding along. > > Regards >
On 23/07/2024 15:08, Konrad Dybcio wrote: > On 23.07.2024 2:57 PM, Marc Gonzalez wrote: > >> On 23/07/2024 13:45, Konrad Dybcio wrote: >> >>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: >>> >>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: >>>> >>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >>>>> >>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>>>>> to take a look at. >>>>> >>>>> Context: >>>>> >>>>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>> >>>>> >>>>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >>>>> on my board. >>>> >>>> Interestingly enough, I can also see iommu errors during WiFi startup >>>> / shutdown on msm8998 / miix630. This leads me to thinking that it >>>> well might be that there is a missing quirk in the iommu driver. >>>> >>>>> I can test a reboot loop for a few hours, to see if anything shows up. >>>> >>>> Yes, please. >>> >>> Yeah I do trust you Marc that it actually works for you and I'm not >>> gonna delay this series because of that, but please go ahead and >>> reboot-loop your board >>> >>> 8998/660 is """famous""" for it's iommu problems >> >> [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 >> >> I get the above warning pretty reliably. >> I don't think it's related to the issue(s) you mentioned. >> System just keeps plodding along. > > Yeah that one's "fine" I booted 40 times in a loop. `grep -a -i FSYNR console.logs` just returns the same 16c0000.iommu "Unhandled context fault" message 76 times (as above). NB: I have maxcpus=1 set in bootargs. Could the iommu issue be a race condition, NOT triggered when code runs with less parallelism? Regards
On 23.07.2024 3:38 PM, Marc Gonzalez wrote: > On 23/07/2024 15:08, Konrad Dybcio wrote: > >> On 23.07.2024 2:57 PM, Marc Gonzalez wrote: >> >>> On 23/07/2024 13:45, Konrad Dybcio wrote: >>> >>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: >>>> >>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: >>>>> >>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >>>>>> >>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>>>>>> to take a look at. >>>>>> >>>>>> Context: >>>>>> >>>>>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>> >>>>>> >>>>>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >>>>>> on my board. >>>>> >>>>> Interestingly enough, I can also see iommu errors during WiFi startup >>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it >>>>> well might be that there is a missing quirk in the iommu driver. >>>>> >>>>>> I can test a reboot loop for a few hours, to see if anything shows up. >>>>> >>>>> Yes, please. >>>> >>>> Yeah I do trust you Marc that it actually works for you and I'm not >>>> gonna delay this series because of that, but please go ahead and >>>> reboot-loop your board >>>> >>>> 8998/660 is """famous""" for it's iommu problems >>> >>> [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 >>> >>> I get the above warning pretty reliably. >>> I don't think it's related to the issue(s) you mentioned. >>> System just keeps plodding along. >> >> Yeah that one's "fine" > > I booted 40 times in a loop. > > `grep -a -i FSYNR console.logs` just returns the same 16c0000.iommu > "Unhandled context fault" message 76 times (as above). > > NB: I have maxcpus=1 set in bootargs. > > Could the iommu issue be a race condition, NOT triggered when code > runs with less parallelism? No clue, can you try without maxcpus=1? The thing will likely run slower (because reasons), but shouldn't explode Konrad
On 23/07/2024 15:43, Konrad Dybcio wrote: > On 23.07.2024 3:38 PM, Marc Gonzalez wrote: > >> On 23/07/2024 15:08, Konrad Dybcio wrote: >> >>> On 23.07.2024 2:57 PM, Marc Gonzalez wrote: >>> >>>> On 23/07/2024 13:45, Konrad Dybcio wrote: >>>> >>>>> On 23.07.2024 11:59 AM, Dmitry Baryshkov wrote: >>>>> >>>>>> On Tue, 23 Jul 2024 at 12:48, Marc Gonzalez wrote: >>>>>> >>>>>>> On 16/07/2024 18:37, Dmitry Baryshkov wrote: >>>>>>> >>>>>>>> No, that's fine. It is the SMMU issue that Konrad has been asking you >>>>>>>> to take a look at. >>>>>>> >>>>>>> Context: >>>>>>> >>>>>>> [ 4.911422] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>>> [ 4.923353] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>>> [ 4.927893] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>>> [ 4.941928] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>>> [ 4.944438] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>>> [ 4.956013] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>>> [ 4.961055] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>>> [ 4.974565] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>>> [ 4.977628] arm-smmu cd00000.iommu: FSR = 00000402 [Format=2 TF], SID=0x0 >>>>>>> [ 4.989670] arm-smmu cd00000.iommu: FSYNR0 = 00000021 [S1CBNDX=0 PNU PLVL=1] >>>>>>> >>>>>>> >>>>>>> As I mentioned, I don't think I've ever seen issues from cd00000.iommu >>>>>>> on my board. >>>>>> >>>>>> Interestingly enough, I can also see iommu errors during WiFi startup >>>>>> / shutdown on msm8998 / miix630. This leads me to thinking that it >>>>>> well might be that there is a missing quirk in the iommu driver. >>>>>> >>>>>>> I can test a reboot loop for a few hours, to see if anything shows up. >>>>>> >>>>>> Yes, please. >>>>> >>>>> Yeah I do trust you Marc that it actually works for you and I'm not >>>>> gonna delay this series because of that, but please go ahead and >>>>> reboot-loop your board >>>>> >>>>> 8998/660 is """famous""" for it's iommu problems >>>> >>>> [ 20.501062] arm-smmu 16c0000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x1, cbfrsynra=0x1900, cb=0 >>>> >>>> I get the above warning pretty reliably. >>>> I don't think it's related to the issue(s) you mentioned. >>>> System just keeps plodding along. >>> >>> Yeah that one's "fine" >> >> I booted 40 times in a loop. >> >> `grep -a -i FSYNR console.logs` just returns the same 16c0000.iommu >> "Unhandled context fault" message 76 times (as above). >> >> NB: I have maxcpus=1 set in bootargs. >> >> Could the iommu issue be a race condition, NOT triggered when code >> runs with less parallelism? > > No clue, can you try without maxcpus=1? Same behavior without maxcpus=1 40 boots, no panics, no FSYNR other than 16c0000.iommu > The thing will likely run slower (because reasons), but shouldn't > explode That makes sense! - Hey, boot is slow. What can we do to make it slower? - Well, just add a bunch of cores running in parallel, that will get the job done! As a matter of fact, trying to boot to command-line with maxcpus=1 causes the system to lock up & reboot. I had to add a systemd script to enable some cores at init. Some qcom daemon must be locking a core & expect progress from another process. Regards
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi index ba5e873f0f35f..417c12534823f 100644 --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi @@ -2785,7 +2785,7 @@ mmcc: clock-controller@c8c0000 { <&mdss_dsi0_phy 0>, <&mdss_dsi1_phy 1>, <&mdss_dsi1_phy 0>, - <0>, + <&hdmi_phy 0>, <0>, <0>, <&gcc GCC_MMSS_GPLL0_DIV_CLK>; @@ -2890,6 +2890,14 @@ dpu_intf2_out: endpoint { remote-endpoint = <&mdss_dsi1_in>; }; }; + + port@2 { + reg = <2>; + + dpu_intf3_out: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; }; }; @@ -3045,6 +3053,96 @@ mdss_dsi1_phy: phy@c996400 { status = "disabled"; }; + + hdmi: hdmi-tx@c9a0000 { + compatible = "qcom,hdmi-tx-8998"; + reg = <0x0c9a0000 0x50c>, + <0x00780000 0x6220>, + <0x0c9e0000 0x2c>; + reg-names = "core_physical", + "qfprom_physical", + "hdcp_physical"; + + interrupt-parent = <&mdss>; + interrupts = <8>; + + clocks = <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_HDMI_CLK>, + <&mmcc MDSS_HDMI_DP_AHB_CLK>, + <&mmcc MDSS_EXTPCLK_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MNOC_AHB_CLK>, + <&mmcc MISC_AHB_CLK>; + clock-names = + "mdp_core", + "iface", + "core", + "alt_iface", + "extp", + "bus", + "mnoc", + "iface_mmss"; + + phys = <&hdmi_phy>; + #sound-dai-cells = <1>; + + pinctrl-0 = <&hdmi_hpd_default>, + <&hdmi_ddc_default>, + <&hdmi_cec_default>; + pinctrl-1 = <&hdmi_hpd_sleep>, + <&hdmi_ddc_default>, + <&hdmi_cec_default>; + pinctrl-names = "default", "sleep"; + + status = "disabled"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + hdmi_in: endpoint { + remote-endpoint = <&dpu_intf3_out>; + }; + }; + + port@1 { + reg = <1>; + hdmi_out: endpoint { + }; + }; + }; + }; + + hdmi_phy: hdmi-phy@c9a0600 { + compatible = "qcom,hdmi-phy-8998"; + reg = <0x0c9a0600 0x18b>, + <0x0c9a0a00 0x38>, + <0x0c9a0c00 0x38>, + <0x0c9a0e00 0x38>, + <0x0c9a1000 0x38>, + <0x0c9a1200 0x0e8>; + reg-names = "hdmi_pll", + "hdmi_tx_l0", + "hdmi_tx_l1", + "hdmi_tx_l2", + "hdmi_tx_l3", + "hdmi_phy"; + + #clock-cells = <0>; + #phy-cells = <0>; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&gcc GCC_HDMI_CLKREF_CLK>, + <&rpmcc RPM_SMD_XO_CLK_SRC>; + clock-names = "iface", + "ref", + "xo"; + + status = "disabled"; + }; }; venus: video-codec@cc00000 {