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: > > [anotherPLL] > | > ------ [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 ancestor clock. Besides that, do you know already if it would solve the conflicts described by Doug in the thread below? http://thread.gmane.org/gmane.linux.kernel/1820653/focus=3298 Thanks, Tomeu > 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(-) >
