regression: Clock changes in next-20141205 break at least omap4

[Tony Lindgren]

* Paul Walmsley <pwalmsley at nvidia.com> [141215 16:23]:
> On 12/15/2014 03:02 PM, Mike Turquette wrote:
> >Quoting Paul Walmsley (2014-12-12 15:28:32)
> >>On Fri, 12 Dec 2014, Mike Turquette wrote:
> >>
> >>>Quoting Tony Lindgren (2014-12-05 10:38:49)
> >>>>* Stephen Boyd <sboyd at codeaurora.org> [141205 10:23]:
> >>>>>On 12/05/2014 08:55 AM, Tony Lindgren wrote:
> >>>>>>Hi,
> >>>>>>
> >>>>>>Looks like commit 646cafc6aa4d ("clk: Change clk_ops->determine_rate
> >>>>>>to return a clk_hw as the best parent") breaks booting at least for
> >>>>>>omap4.
> >>>>>Do you get a compilation warning in arch/arm/mach-omap2/dpll3xxx.c ?
> >>>>Yes so it seems.
> >>>>
> >>>>> From what I can tell omap3_noncore_dpll_determine_rate() hasn't been
> >>>>>updated to take a clk_hw pointer instead of clk pointer. It was there in
> >>>>>the original patch and I'm not sure why Mike dropped that part while
> >>>>>applying.
> >>>>OK that makes sense, Mike should apply that part too. Note that also
> >>>>include/linux/clk/ti.h needs changed accordingly for struct clk_hw,
> >>>>which you probably had in your orignal patch too. Assuming that's there,
> >>>>please feel free to add:
> >>>>
> >>>>Acked-by: Tony Lindgren <tony at atomide.com>
> >>>I figured out what went wrong here. When I applied Tomeu's changes the
> >>>OMAP stuff did not apply at all. In fact the .determine_rate callbacks
> >>>did not exist in clk-next. Paul merged that stuff through his tree[0]. I
> >>>don't know why I didn't follow up on that at the time.
> >>>
> >>>So we need to come up with a solution. Paul can take the OMAP portion of
> >>>Tomeu's changes[1] for OMAP, but I believe compilation will be broken in
> >>>his tree until it meets up with mine in linux-next. Or we could set up a
> >>>shared immutable branch that provides the needed changes.
> >>>
> >>>I could either set up a shared branch that includes Tomeu's changes that
> >>>Paul could merge (will require a rebase of the tip of my tree) or Paul
> >>>could provide a shared branch of the changes to dpll3xxx.c and
> >>>dpll4xxx.c that I could merge in.
> >>>
> >>>Or I could remove Tomeu's patches from my tree since we're right up
> >>>against the merge window but I would rather not do that since he has
> >>>worked tirelessly on this topic.
> >>>
> >>>[0] http://www.spinics.net/lists/arm-kernel/msg377288.html
> >>>[1] https://lkml.org/lkml/2014/12/2/70
> >>I don't think there's much that I can do at this point.  My tree is quite
> >>topologically distant from Linus's tree (pjw/omap-pending ->
> >>tmlind/linux-omap -> arm/arm-soc -> torvalds/linux).  So anything I do is
> >>high-latency.  My pull request for Tero's patches was sent to Tony a month
> >>ago.
> >Paul,
> >
> >I identified the patch in your tree that is missing in mine and, with
> >Tony's help, applied your for-v3.19/omap-a signed tag to my tree. With
> >these 5 patches in place I have applied Tero's two patches from
> >Friday[0].
> >
> >Paul & Tony, are you OK for me to take both of Tero's patches? I'm
> >already taking stuff in late so it is no trouble for me to pick up "ARM:
> >OMAP3: clock: fix boot breakage in legacy mode" while I'm at it.
> >
> >I'm going to let this get at least one cycle in linux-next before
> >sending my PR late this week. Hopefully Kevin (Cc'd) can check on the
> >omap boards in his autobuilder once my tree hits -next?
> >
> >Let me know if I missed anything. Thanks for the great teamwork, gang.
> >
> >[0] http://lkml.kernel.org/r/<1418390521-7541-1-git-send-email-t-kristo@ti.com>
> >
> >Regards,
> >Mike
> 
> I think Tony's taking the second patch from Tero.

If it applies to what Mike has now queued, please take that too Mike:

Acked-by: Tony Lindgren <tony at atomide.com>