[RFC PATCH 0/3] clk: attempt to keep requested rate on parent changes
tomeu.vizoso at collabora.com
Thu May 5 06:30:32 PDT 2016
On 05/02/2016 06:36 PM, Heiko Stuebner wrote:
> I remember reading about people discussing that problem in the past, but
> haven't been able to find another approach to it yet [or I'm just blind
> as happens to often].
> Our problem is the following clock structure:
> ------ [div] ----- dclk_vop
> [ vpll ] --------- hdmi_phy
> We need to set the vpll dynamically but still want to retain
Guess something is missing here?
> The other option that comes to mind, would be to have a clock-notifier,
> in the drm driver, but calling clk_set_rate from their looks like it
> shouldn't work due to the prepare mutex already being held.
> The whole thing is labeled RFC because while it works for us and solves
> the problem, I'm not sure if I'm overlooking some important aspect or
> am interferring with some other planned approach for that issue.
I like this approach very much and wonder in what cases it wouldn't be
desirable to re-try to achieve the requested rate after a change in an
Besides that, do you know already if it would solve the conflicts
described by Doug in the thread below?
> Heiko Stuebner (3):
> clk: fix inconsistent use of req_rate
> clk: adjust clocks to their requested rate after parent changes
> clk: rockchip: make rk3399 vop dclks keep their rate on parent rate changes
> drivers/clk/clk.c | 37 +++++++++++++++++++++++++++++--------
> drivers/clk/rockchip/clk-rk3399.c | 4 ++--
> include/linux/clk-provider.h | 1 +
> 3 files changed, 32 insertions(+), 10 deletions(-)
More information about the Linux-rockchip