[RFC PATCH 0/3] clk: attempt to keep requested rate on parent changes

[Doug Anderson]

Hi,

On Thu, May 5, 2016 at 8:07 AM, Heiko Stübner <heiko at sntech.de> wrote:
>> 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
>
> I think the big issue on the rk3288 is, who is actually in charge of
> controlling the npll frequency.
>
> On the rk3399 the vpll is supplied unmodified to the hdmiphy, while as a
> dclk_vop source it goes through a divider first. So it's pretty clear that the
> hdmiphy will control the core frequency while other users need to adapt to
> what they get.
>
> On the rk3288 the npll is a possible source to both the hdmi- as well as the
> edp-clock (and some others as well), so when it gets adapted dynamically, wo
> is going to be in charge and who needs to adapt ... and how do we set this
> hierarchy.

Yeah, I don't think it fully solves the rk3288 problem, though
probably you'd end up in a better shape than today.

Specifically:

1. It assumes that the last requester of the rate is the one who gets
to specify it.  That's fine in the master-slave relationship that
Heiko describes for rk3399, but not so great for the peer-peer
relationship of NPLL uses on rk3288.  Said another way: on rk3399 it's
clear that HDMI decides the rate and the VOP has to deal with it, but
on rk3288 you've got two equals both wanting their own rate.

2. It's unclear exactly how well the different users of the VOP would
be able to cope with arbitrary rate changes since it really depends on
what's connected on the other end.


In general it seems like the rule for two peers should be that the
first requester should keep its rate and the 2nd requester should just
have to deal with it, unless the first requester added special code to
validate that the new rate was OK.

-Doug