| Message ID | 20220607141535.1.Idafe043ffc94756a69426ec68872db0645c5d6e2@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: rockchip: Assign RK3399 VDU clock rate | expand |
Le mardi 07 juin 2022 à 14:15 -0700, Brian Norris a écrit : > Before commit 9998943f6dfc ("media: rkvdec: Stop overclocking the > decoder"), the rkvdec driver was forcing the VDU clock rate. After that > commit, we rely on the default clock rate. That rate works OK on many > boards, with the default PLL settings (CPLL is 800MHz, VDU dividers > leave it at 400MHz); but some boards change PLL settings. > > Assign the expected default clock rate explicitly, so that the rate is > consistent, regardless of PLL configuration. > > This was particularly broken on RK3399 Gru Scarlet systems, where the > rk3399-gru-scarlet.dtsi assigns PLL_CPLL to 1.6 GHz, and so the VDU > clock ends up at 800 MHz (twice the expected rate), and causes video > artifacts and other issues. > > Note: I assign the clock rate in the clock controller instead of the > vdec node, because there are multiple nodes that use this clock, and per > the clock.yaml specification: > > Configuring a clock's parent and rate through the device node that > consumes the clock can be done only for clocks that have a single > user. Specifying conflicting parent or rate configuration in multiple > consumer nodes for a shared clock is forbidden. > > Configuration of common clocks, which affect multiple consumer devices > can be similarly specified in the clock provider node. > > Fixes: 9998943f6dfc ("media: rkvdec: Stop overclocking the decoder") > Cc: <stable@vger.kernel.org> > Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> My only doubt was if you really needed to duplicate that setting into gru- scarlet.dtsi, but I've simply assumed the answer is yes, and that you already checked that. > --- > This is a candidate for 5.19 IMO, since commit 9998943f6dfc landed in > 5.19-rc1 and is being queued up for -stable as we speak. > > arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 4 +++- > arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 ++++-- > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > index 913d845eb51a..1977103a5ef4 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > @@ -376,7 +376,8 @@ &cru { > <&cru ACLK_VIO>, > <&cru ACLK_GIC_PRE>, > <&cru PCLK_DDR>, > - <&cru ACLK_HDCP>; > + <&cru ACLK_HDCP>, > + <&cru ACLK_VDU>; > assigned-clock-rates = > <600000000>, <1600000000>, > <1000000000>, > @@ -388,6 +389,7 @@ &cru { > <400000000>, > <200000000>, > <200000000>, > + <400000000>, > <400000000>; > }; > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > index fbd0346624e6..9d5b0e8c9cca 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi > @@ -1462,7 +1462,8 @@ cru: clock-controller@ff760000 { > <&cru HCLK_PERILP1>, <&cru PCLK_PERILP1>, > <&cru ACLK_VIO>, <&cru ACLK_HDCP>, > <&cru ACLK_GIC_PRE>, > - <&cru PCLK_DDR>; > + <&cru PCLK_DDR>, > + <&cru ACLK_VDU>; > assigned-clock-rates = > <594000000>, <800000000>, > <1000000000>, > @@ -1473,7 +1474,8 @@ cru: clock-controller@ff760000 { > <100000000>, <50000000>, > <400000000>, <400000000>, > <200000000>, > - <200000000>; > + <200000000>, > + <400000000>; > }; > > grf: syscon@ff770000 {
On Tue, Jun 07, 2022 at 05:20:41PM -0400, Nicolas Dufresne wrote: > Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Thanks! > My only doubt was if you really needed to duplicate that setting into gru- > scarlet.dtsi, but I've simply assumed the answer is yes, and that you already > checked that. I didn't explicitly test without modifying gru-scarlet.dtsi, but the unfortunate nature of these long monolithic assigned-clocks/assigned-clock-rates properties is that if you want to add or override one element in the array, you have to repeat (or override) all of them. And because rk3399-gru-scarlet.dtsi already overrides some of them, every additional change has to be reflected there. That's why it would be much nicer to be able to distribute the assignments to their various consumer nodes, but as noted in the commit message (because you mentioned it to me out-of-band ;) ), we can't do that. Regards, Brian
On Tue, 7 Jun 2022 14:15:36 -0700, Brian Norris wrote: > Before commit 9998943f6dfc ("media: rkvdec: Stop overclocking the > decoder"), the rkvdec driver was forcing the VDU clock rate. After that > commit, we rely on the default clock rate. That rate works OK on many > boards, with the default PLL settings (CPLL is 800MHz, VDU dividers > leave it at 400MHz); but some boards change PLL settings. > > Assign the expected default clock rate explicitly, so that the rate is > consistent, regardless of PLL configuration. > > [...] Applied, thanks! [1/1] arm64: dts: rockchip: Assign RK3399 VDU clock rate commit: 2d56af33d4df94d2b76446ffc3e3654c42232f4b as fix for 5.19 Best regards,
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi index 913d845eb51a..1977103a5ef4 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi @@ -376,7 +376,8 @@ &cru { <&cru ACLK_VIO>, <&cru ACLK_GIC_PRE>, <&cru PCLK_DDR>, - <&cru ACLK_HDCP>; + <&cru ACLK_HDCP>, + <&cru ACLK_VDU>; assigned-clock-rates = <600000000>, <1600000000>, <1000000000>, @@ -388,6 +389,7 @@ &cru { <400000000>, <200000000>, <200000000>, + <400000000>, <400000000>; }; diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi index fbd0346624e6..9d5b0e8c9cca 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi @@ -1462,7 +1462,8 @@ cru: clock-controller@ff760000 { <&cru HCLK_PERILP1>, <&cru PCLK_PERILP1>, <&cru ACLK_VIO>, <&cru ACLK_HDCP>, <&cru ACLK_GIC_PRE>, - <&cru PCLK_DDR>; + <&cru PCLK_DDR>, + <&cru ACLK_VDU>; assigned-clock-rates = <594000000>, <800000000>, <1000000000>, @@ -1473,7 +1474,8 @@ cru: clock-controller@ff760000 { <100000000>, <50000000>, <400000000>, <400000000>, <200000000>, - <200000000>; + <200000000>, + <400000000>; }; grf: syscon@ff770000 {
Before commit 9998943f6dfc ("media: rkvdec: Stop overclocking the decoder"), the rkvdec driver was forcing the VDU clock rate. After that commit, we rely on the default clock rate. That rate works OK on many boards, with the default PLL settings (CPLL is 800MHz, VDU dividers leave it at 400MHz); but some boards change PLL settings. Assign the expected default clock rate explicitly, so that the rate is consistent, regardless of PLL configuration. This was particularly broken on RK3399 Gru Scarlet systems, where the rk3399-gru-scarlet.dtsi assigns PLL_CPLL to 1.6 GHz, and so the VDU clock ends up at 800 MHz (twice the expected rate), and causes video artifacts and other issues. Note: I assign the clock rate in the clock controller instead of the vdec node, because there are multiple nodes that use this clock, and per the clock.yaml specification: Configuring a clock's parent and rate through the device node that consumes the clock can be done only for clocks that have a single user. Specifying conflicting parent or rate configuration in multiple consumer nodes for a shared clock is forbidden. Configuration of common clocks, which affect multiple consumer devices can be similarly specified in the clock provider node. Fixes: 9998943f6dfc ("media: rkvdec: Stop overclocking the decoder") Cc: <stable@vger.kernel.org> Signed-off-by: Brian Norris <briannorris@chromium.org> --- This is a candidate for 5.19 IMO, since commit 9998943f6dfc landed in 5.19-rc1 and is being queued up for -stable as we speak. arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 4 +++- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 ++++-- 2 files changed, 7 insertions(+), 3 deletions(-)