linux-dev/drivers/clk/rockchip, branch master

clk: rockchip: Add clock controller support for RV1126 SoC

2022-09-23T09:15:30Z

Clock & Reset Unit (CRU) in RV1126 support clocks for CRU and CRU_PMU blocks. This patch is trying to add minimal Clock-Architecture Diagram's inferred from [1] authored by Finley Xiao. [1] https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/clk/rockchip/clk-rv1126.c Cc: linux-clk@vger.kernel.org Cc: Michael Turquette Cc: Stephen Boyd Signed-off-by: Finley Xiao Signed-off-by: Jagan Teki Link: https://lore.kernel.org/r/20220915163947.1922183-5-jagan@edgeble.ai Signed-off-by: Heiko Stuebner

clk: rockchip: Add MUXTBL variant

2022-09-13T10:09:14Z

Add a clock branch consisting of a mux with non-standard select values. The parent in Mux table is sorted by priority. Use clk_register_mux_table() to register such a mux-clock. Cc: linux-clk@vger.kernel.org Cc: Michael Turquette Cc: Stephen Boyd Signed-off-by: Elaine Zhang Signed-off-by: Jagan Teki Link: https://lore.kernel.org/r/20220907160207.3845791-3-jagan@edgeble.ai Signed-off-by: Heiko Stuebner

clk: rockchip: Mark hclk_vo as critical on rk3568

2022-05-03T09:16:48Z

Whenever pclk_vo is enabled hclk_vo must be enabled as well. This is described in the Reference Manual as: | 2.8.6 NIU Clock gating reliance | | A part of niu clocks have a dependence on another niu clock in order to | sharing the internal bus. When these clocks are in use, another niu | clock must be opened, and cannot be gated. These clocks and the special | clock on which they are relied are as following: | | Clocks which have dependency The clock which can not be gated | ----------------------------------------------------------------- | ... | pclk_vo_niu, hclk_vo_s_niu hclk_vo_niu | ... The clock framework doesn't offer a way to enable clock B whenever clock A is enabled, at least not when B is not an ancestor of A. Workaround this by marking hclk_vo as critical so it is never disabled. This is suboptimal in terms of power consumption, but a stop gap solution until the clock framework has a way to deal with this. We have this clock tree: | aclk_vo 2 2 0 300000000 0 0 50000 Y | aclk_hdcp 0 0 0 300000000 0 0 50000 N | pclk_vo 2 3 0 75000000 0 0 50000 Y | pclk_edp_ctrl 0 0 0 75000000 0 0 50000 N | pclk_dsitx_1 0 0 0 75000000 0 0 50000 N | pclk_dsitx_0 1 2 0 75000000 0 0 50000 Y | pclk_hdmi_host 1 2 0 75000000 0 0 50000 Y | pclk_hdcp 0 0 0 75000000 0 0 50000 N | hclk_vo 2 5 0 150000000 0 0 50000 Y | hclk_hdcp 0 0 0 150000000 0 0 50000 N | hclk_vop 0 2 0 150000000 0 0 50000 N Without this patch the edp, dsitx, hdmi and hdcp driver would enable their clocks which then enables pclk_vo, but hclk_vo stays disabled and register accesses just hang. hclk_vo is enabled by the VOP2 driver, so reproducibility of this issue depends on the probe order. Signed-off-by: Sascha Hauer Reviewed-by: Dmitry Osipenko Reviewed-by: Robin Murphy Tested-by: Michael Riesch Link: https://lore.kernel.org/r/20220422072841.2206452-2-s.hauer@pengutronix.de Signed-off-by: Heiko Stuebner

clk: rockchip: re-add rational best approximation algorithm to the fractional divider

2022-02-23T23:07:16Z

In commit 4e7cf74fa3b2 ("clk: fractional-divider: Export approximation algorithm to the CCF users"), the code handling the rational best approximation algorithm was replaced by a call to the core clk_fractional_divider_general_approximation function which did the same thing back then. However, in commit 82f53f9ee577 ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag"), this common code was made conditional on CLK_FRAC_DIVIDER_POWER_OF_TWO_PS flag which was not added back to the rockchip clock driver. This broke the ltk050h3146w-a2 MIPI DSI display present on a PX30-based downstream board. Let's add the flag to the fractional divider flags so that the original and intended behavior is brought back to the rockchip clock drivers. Fixes: 82f53f9ee577 ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag") Cc: stable@vger.kernel.org Cc: Quentin Schulz Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20220131163224.708002-1-quentin.schulz@theobroma-systems.com Signed-off-by: Heiko Stuebner

clk/rockchip: Use of_device_get_match_data()

2022-02-23T22:59:27Z

Use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot Signed-off-by: Minghao Chi (CGEL ZTE) Link: https://lore.kernel.org/r/20220221020103.1925026-1-chi.minghao@zte.com.cn Signed-off-by: Heiko Stuebner

clk: rockchip: Add CLK_SET_RATE_PARENT to the HDMI reference clock on rk3568

2022-02-08T11:56:34Z

On the rk3568 we have this (simplified) situation: .--------. .-----. .---------. -| hpll |--.--| /n |----|dclk_vop0|- `--------´ | `-----´ `---------´ | .-----. .---------. `--| /m |----|dclk_vop1|- | `-----´ `---------´ | .---------. `-------------|hdmi_ref |- `---------´ For the HDMI to work the HDMI reference clock needs to be the same as the pixel clock which means the dividers have be set to one. The last patch removed the CLK_SET_RATE_PARENT flag from the pixel clocks which means the hpll is not changed on pixel clock changes. In order to allow the HDMI controller to set a suitable PLL rate we now add the CLK_SET_RATE_PARENT flag to the HDMI reference clock. With this the flow becomes: 1) HDMI controller driver sets the rate to its pixel clock which means hpll is set to the pixel clock 2) VOP2 driver sets dclk_vop[012] to the pixel clock. As this can't change the hpll clock anymore this means only the divider is adjusted to the desired value of dividing by one. Signed-off-by: Sascha Hauer Link: https://lore.kernel.org/r/20220126145549.617165-26-s.hauer@pengutronix.de Signed-off-by: Heiko Stuebner

clk: rockchip: drop CLK_SET_RATE_PARENT from dclk_vop* on rk3568

2022-02-08T11:56:33Z

The pixel clocks dclk_vop[012] can be clocked from hpll, vpll, gpll or cpll. gpll and cpll also drive many other clocks, so changing the dclk_vop[012] clocks could change these other clocks as well. Drop CLK_SET_RATE_PARENT to fix that. With this change the VOP2 driver can only adjust the pixel clocks with the divider between the PLL and the dclk_vop[012] which means the user may have to adjust the PLL clock to a suitable rate using the assigned-clock-rate device tree property. Signed-off-by: Sascha Hauer Link: https://lore.kernel.org/r/20220126145549.617165-25-s.hauer@pengutronix.de Signed-off-by: Heiko Stuebner

clk: rockchip: Add more PLL rates for rk3568

2022-02-08T11:56:33Z

This adds a few more PLL settings needed for some standard resolutions: 297MHz 3840x2160-30.00 241.5MHz 2560x1440-59.95 135MHz 1280x1024-75.02 119MHz 1680x1050-59.88 108MHz 1280x1024-60.02 78.75MHz 1024x768-75.03 Changes since v3: - new patch Signed-off-by: Sascha Hauer Link: https://lore.kernel.org/r/20220126145549.617165-12-s.hauer@pengutronix.de Signed-off-by: Heiko Stuebner

clk: rockchip: drop module parts from rk3399 and rk3568 drivers

2021-11-03T00:59:00Z

Both of these drivers were converted to real drivers and got a tristate build option. But them being builtin_platform_drivers, they only ever should be build-in - as the name suggests. So adapt the Kconfig symbol and drop the MODULE_* parts from the drivers. Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20211027132616.1039814-3-heiko@sntech.de Reviewed-by: Stephen Boyd Signed-off-by: Stephen Boyd

Revert "clk: rockchip: use module_platform_driver_probe"

2021-11-03T00:59:00Z

This reverts commit 1da80da028fe5accb866c0d6899a292ed86bef45. Reading recent discussions [0] [1], I realized this change introduces a number of problems: - only converting to module_platform_driver creates the issue with the existing __init and __initdata attributes. When the driver would've been built as a module, all the missing clock-definitions (all are initdata) should've turned up as error in testing suggesting that the change wasn't at all - a clock driver is a very core component of soc bringup and making this able to be built as a module solely for enabling the soc vendor to add out of tree changes for Android implementations is not in our interest and also everything except a ramdisk won't probe without a clock controller. This is especially true when the changes aren't really tested and are merely added to move the mainline driver "out of the way". [0] https://lwn.net/Articles/872209/ [1] https://lore.kernel.org/all/163529604399.15791.378104318036812951@swboyd.mtv.corp.google.com/ Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20211027132616.1039814-2-heiko@sntech.de Reviewed-by: Stephen Boyd Signed-off-by: Stephen Boyd