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

[Mike Turquette <mturquette@linaro.org>]

Quoting Tero Kristo (2014-07-03 00:41:22)
> 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.

Expect it late next week as several new fixes pull requests have come
in. I merge those into clk-fixes, which then gets merged into clk-next
and all of that gets pulled into linux-next. After some cycles there and
testing on my end I send the fixes PR to Linus. So expect it to go
between -rc4 and -rc5.

Regards,
Mike

> 
> -Tero