Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock

[Tero Kristo <t-kristo@ti.com>]

On 07/01/2014 10:48 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
>> On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
>>> When setting the rate of a clock, by default the clock framework will
>>> change the parent of the clock to the most suitable one in
>>> __clk_mux_determine_rate() (most suitable by looking at the clock rate).
>>>
>>> This is a rather dangerous default, and causes problems on AM43x when
>>> using display and ethernet. There are multiple ways to select the clock
>>> muxes on AM43x, and some of those clock paths have the same source
>>> clocks for display and ethernet. When changing the clock rate for the
>>> display subsystem, the clock framework decides to change the display mux
>> >from the dedicated display PLL to a shared PLL which is used by the
>>> ethernet, and then changes the rate of the shared PLL, breaking the
>>> ethernet.
>>>
>>> As I don't think there ever is a case where we want the clock framework
>>> to automatically change the parent clock of a clock mux, this patch sets
>>> the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
>>>
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>>   drivers/clk/ti/mux.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
>>> index 0197a478720c..e9d650e51287 100644
>>> --- a/drivers/clk/ti/mux.c
>>> +++ b/drivers/clk/ti/mux.c
>>> @@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
>>>   	u8 clk_mux_flags = 0;
>>>   	u32 mask = 0;
>>>   	u32 shift = 0;
>>> -	u32 flags = 0;
>>> +	u32 flags = CLK_SET_RATE_NO_REPARENT;
>>>
>>>   	num_parents = of_clk_get_parent_count(node);
>>>   	if (num_parents < 2) {
>>>
>>
>> Thanks, queued for 3.16-rc fixes.
>
> did you skip a few -rcs by any chance? Looks like this could've been
> merged on v3.16-rc3... Just checking.

This goes through Mike's clk tree, so there is extra latency there. Not 
sure when he plans to send next pull-req for clk-fixes to linux-master.

-Tero