[PATCHv13,00/40] ARM: TI SoC clock DT conversion

On 01/10/2014 08:51 PM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [140110 08:32]:
>> On 01/10/2014 06:13 PM, Felipe Balbi wrote:
>>> On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote:
>>>> On 01/10/2014 01:15 AM, Felipe Balbi wrote:
>>>>> On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote:
>>>>>>
>>>>>> conflicts with be changes on Tony's be branch.
>>>>>> commit 80f304dd2360cf5d50953c4eb4e902536f6a1263
>>>>>>      ARM: OMAP2+: raw read and write endian fix
>>>>>>
>>>>>> Conflict:
>>>>>> arch/arm/mach-omap2/clkt_clksel.c
>>>>>> arch/arm/mach-omap2/clkt_dpll.c
>>>>>> arch/arm/mach-omap2/clkt_iclk.c
>>>>>> arch/arm/mach-omap2/clock.c
>>>>>> arch/arm/mach-omap2/clock36xx.c
>>>>>> arch/arm/mach-omap2/dpll3xxx.c
>>>>>> arch/arm/mach-omap2/dpll44xx.c
>>>>>>
>>>>>> Both change raw_readls -> should now be just clk api instead which
>>>>>> already does readl_relaxed etc.. If Tony feels like, then we should
>>>>>> probably post a branch based on 'be' branch for easy merge.
>
> This should be a trivial merge conflict to handle, so let's not base
> things on the BE changes.
>
>>>> I think all of these fails are caused by the initially bugged
>>>> Makefile + Kconfig under mach-omap2. Seems like they can be fixed by
>>>> the patches I inlined at the end (will also post them as proper
>>>> patches to l-o list after this.) The question is, should Mike go
>>>> ahead and merge these along with the base clk patches or how should
>>>> we handle them? Patch 1 must be merged, patch 2 is a nice to have one
>>>> which allows DRA7 only builds (doing DRA7 only build currently seems
>>>> not possible.)
>>>
>>> If it's OK with Tony, I would suggest having a branch with both patches
>>> below which both Tony and Mike merge before merging CCF series. That way
>>> we avoid bisection problems.
>
> I can queue those two separately as fixes.
>
>> That reminds me, I think the baseline branch for the mach-omap2
>> patches is still somewhat unclear to me, what should be used for
>> this? And which patches should be put there (the mach-omap2 patches
>> depend on the drivers/clk/ti part basically, so I need to put at
>> least those there also.)
>
> I would keep the clock patches against some mainline -rc commit if
> possible, and if there are non trivial merge conflicts, the omap
> to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c.
>
> In any case, it's probably best that Mike merges this all via his
> clock tree unless there non-trivial merge conflicts.
>

I just pushed a branch against rc7 with makefile fixes in place to fix 
omap1 and omap2 only builds for this stuff. Inlined the delta here at 
the end. Do you want me to repost the series as v14 for this or is the 
attached delta ok for review purposes? All the changes have been 
squashed to existing patches (except the 2 patches I posted separately 
for DRA7xx / AM43xx only builds.)

The test branch itself can be found here:

tree: https://github.com/t-kristo/linux-pm.git
branch: 3.13-rc7-dt-clks-v13-build-fixes

Felipe, care to run your randconfig magic for this?

-Tero

----------------


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Jan 14, 2014 at 02:41:40PM +0200, Tero Kristo wrote:
> On 01/10/2014 08:51 PM, Tony Lindgren wrote:
> >* Tero Kristo <t-kristo@ti.com> [140110 08:32]:
> >>On 01/10/2014 06:13 PM, Felipe Balbi wrote:
> >>>On Fri, Jan 10, 2014 at 11:52:49AM +0200, Tero Kristo wrote:
> >>>>On 01/10/2014 01:15 AM, Felipe Balbi wrote:
> >>>>>On Thu, Jan 09, 2014 at 03:22:03PM -0600, Nishanth Menon wrote:
> >>>>>>
> >>>>>>conflicts with be changes on Tony's be branch.
> >>>>>>commit 80f304dd2360cf5d50953c4eb4e902536f6a1263
> >>>>>>     ARM: OMAP2+: raw read and write endian fix
> >>>>>>
> >>>>>>Conflict:
> >>>>>>arch/arm/mach-omap2/clkt_clksel.c
> >>>>>>arch/arm/mach-omap2/clkt_dpll.c
> >>>>>>arch/arm/mach-omap2/clkt_iclk.c
> >>>>>>arch/arm/mach-omap2/clock.c
> >>>>>>arch/arm/mach-omap2/clock36xx.c
> >>>>>>arch/arm/mach-omap2/dpll3xxx.c
> >>>>>>arch/arm/mach-omap2/dpll44xx.c
> >>>>>>
> >>>>>>Both change raw_readls -> should now be just clk api instead which
> >>>>>>already does readl_relaxed etc.. If Tony feels like, then we should
> >>>>>>probably post a branch based on 'be' branch for easy merge.
> >
> >This should be a trivial merge conflict to handle, so let's not base
> >things on the BE changes.
> >
> >>>>I think all of these fails are caused by the initially bugged
> >>>>Makefile + Kconfig under mach-omap2. Seems like they can be fixed by
> >>>>the patches I inlined at the end (will also post them as proper
> >>>>patches to l-o list after this.) The question is, should Mike go
> >>>>ahead and merge these along with the base clk patches or how should
> >>>>we handle them? Patch 1 must be merged, patch 2 is a nice to have one
> >>>>which allows DRA7 only builds (doing DRA7 only build currently seems
> >>>>not possible.)
> >>>
> >>>If it's OK with Tony, I would suggest having a branch with both patches
> >>>below which both Tony and Mike merge before merging CCF series. That way
> >>>we avoid bisection problems.
> >
> >I can queue those two separately as fixes.
> >
> >>That reminds me, I think the baseline branch for the mach-omap2
> >>patches is still somewhat unclear to me, what should be used for
> >>this? And which patches should be put there (the mach-omap2 patches
> >>depend on the drivers/clk/ti part basically, so I need to put at
> >>least those there also.)
> >
> >I would keep the clock patches against some mainline -rc commit if
> >possible, and if there are non trivial merge conflicts, the omap
> >to use as the base is commit adfe9361b236154215d4b0fc8b6d79995394b15c.
> >
> >In any case, it's probably best that Mike merges this all via his
> >clock tree unless there non-trivial merge conflicts.
> >
> 
> I just pushed a branch against rc7 with makefile fixes in place to
> fix omap1 and omap2 only builds for this stuff. Inlined the delta
> here at the end. Do you want me to repost the series as v14 for this
> or is the attached delta ok for review purposes? All the changes have
> been squashed to existing patches (except the 2 patches I posted
> separately for DRA7xx / AM43xx only builds.)
> 
> The test branch itself can be found here:
> 
> tree: https://github.com/t-kristo/linux-pm.git
> branch: 3.13-rc7-dt-clks-v13-build-fixes
> 
> Felipe, care to run your randconfig magic for this?

This branch builds just fine so far, I still have omap5 multiplaform and
uniplatform builds, but since that was working before i'm assuming it
won't break.

cheers

Hi,

On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
> > Felipe, care to run your randconfig magic for this?
> 
> This branch builds just fine so far, I still have omap5 multiplaform and
> uniplatform builds, but since that was working before i'm assuming it
> won't break.

No build failures in any of my 18 seeds (5 randconfigs of each), I'd
attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
send it.

FWIW:

Acked-by: Felipe Balbi <balbi@ti.com>

cheers

On 01/15/2014 05:50 AM, Mike Turquette wrote:
> Quoting Mike Turquette (2014-01-14 19:16:32)
>> Quoting Felipe Balbi (2014-01-14 18:04:21)
>>> Hi,
>>>
>>> On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
>>>>> Felipe, care to run your randconfig magic for this?
>>>>
>>>> This branch builds just fine so far, I still have omap5 multiplaform and
>>>> uniplatform builds, but since that was working before i'm assuming it
>>>> won't break.
>>>
>>> No build failures in any of my 18 seeds (5 randconfigs of each), I'd
>>> attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
>>> send it.
>>>
>>> FWIW:
>>>
>>> Acked-by: Felipe Balbi <balbi@ti.com>
>>
>> Felipe,
>>
>> That's great to hear. Thanks for testing.
>>
>> Tero & Tony,
>>
>> These 40 patches apply very cleanly on top of clk-next with 2
>> exceptions:
>>
>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
>> on 3.13-rc1).
>>
>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
>> resolved correctly but would like verification.
>>
>> I'd prefer to simply merge these patches into clk-next, which is the
>> most straightforward route. Any ideas on how to handle the missing
>> AM35xx dtsi data? It can always go as a separate fix after this stuff
>> gets merged which, ironically, is how that file was created in the first
>> place.
>
> I've pushed my branch. Tero can you take a look and let me know if you
> see any problems?
>
> git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap

Hey Mike,

Can't see any issues there, also gave it a quick boot test with the 
boards I have access to and seems to work fine.

-Tero

>
> Thanks!
> Mike
>
>>
>> Regards,
>> Mike
>>
>>>
>>> cheers
>>>
>>> --
>>> balbi

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html