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

[Paul Walmsley <pwalmsley@nvidia.com>]

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@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@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.

- Paul