From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Brian Norris <briannorris@chromium.org>,
Heiko Stuebner <heiko@sntech.de>
Cc: linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org,
Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Sebastian Fricke <sebastian.fricke@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
stable@vger.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: Assign RK3399 VDU clock rate
Date: Tue, 07 Jun 2022 17:20:41 -0400 [thread overview]
Message-ID: <253e2771abb13a3e62c07dfb0b420169bb572c2d.camel@collabora.com> (raw)
In-Reply-To: <20220607141535.1.Idafe043ffc94756a69426ec68872db0645c5d6e2@changeid>
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 {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-06-07 21:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-07 21:15 [PATCH] arm64: dts: rockchip: Assign RK3399 VDU clock rate Brian Norris
2022-06-07 21:20 ` Nicolas Dufresne [this message]
2022-06-07 21:36 ` Brian Norris
2022-06-11 15:20 ` Heiko Stuebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=253e2771abb13a3e62c07dfb0b420169bb572c2d.camel@collabora.com \
--to=nicolas.dufresne@collabora.com \
--cc=briannorris@chromium.org \
--cc=devicetree@vger.kernel.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=heiko@sntech.de \
--cc=hverkuil-cisco@xs4all.nl \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=sebastian.fricke@collabora.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox