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

[Nishanth Menon]

On 01/16/2014 03:39 PM, Mike Turquette wrote:
> Quoting Tony Lindgren (2014-01-15 11:35:48)
>> * Mike Turquette <mturquette at linaro.org> [140115 11:25]:
>>> Quoting Tony Lindgren (2014-01-15 09:13:23)
>>>> * Mike Turquette <mturquette at linaro.org> [140114 19:52]:
>>>>>>
>>>>>> 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.
>>>>
>>>> You could do something like this to take advantage of fast forward and
>>>> not have to do a merge back from mainline:
>>>>
>>>> $ git checkout -b am3517-clk v3.13-rc8 # or any other -rc with am3517.dtsi
>>>> $ git merge clk-next-omap # this fast forwards clk-next-omap to the desired -rc
>>>> $ git am am3517-clk-patch
>>>> $ git checkout clk-next
>>>> $ git merge clk-next-omap # this fast forwards clk-next to the desired -rc
>>>
>>> That makes sense, but is there anything bad about doing that for a
>>> branch you intend to send as a pull request? I don't see how any of the
>>> commits get re-written or anything... I just wonder if there is some
>>> subtlety that I am not accounting for that makes this approach bad for
>>> sending to Linus.
>>
>> No there should not be any issues. That's the preferred way to keep
>> development branches updated and pullable in long term without any need
>> to rebase.
>>
>> Note that there will be only a merge commit if there is a conflict,
>> otherwise the fast forward will be transparent. So the trick to avoiding
>> rebasing and back merges is to apply patches against what they need in a
>> local branch, then after testing merge that local branch into the development
>> branch. Then for the upsteam pull request, you just need to make it against
>> the -rc you merged in.
>>
>> AFAIK what Linus does not like is doing a back merge to a development
>> branch from mainline, probably as it adds a pointless commit. Or rebasing
>> a branch as that way it won't stay pullable.
> 
> Hi all,
> 
> I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
> Tero's series. This includes the AM3517 bits now. I've pushed this
> branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
> final sanity test before I merge this into clk-next?

multi_v7_defconfig:
 1: am335x-evm:  Boot FAIL: http://slexy.org/raw/s25jHnIctr
mmc/regulator missing stuff
 2:  am335x-sk:  Boot FAIL: http://slexy.org/raw/s2e9oDkTbD
mmc/regulator missing stuff
 3: am3517-evm:  Boot PASS: http://slexy.org/raw/s2KL4qBOM6
 4:  am37x-evm:  Boot PASS: http://slexy.org/raw/s20jAHD1DE
 5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s21vXGDma7
 6:       beag:  Boot PASS: http://slexy.org/raw/s25ZJgkM9q
 7:       bone:  Boot PASS: http://slexy.org/raw/s21U0U2lVW
 8:      crane: No Image built - Missing platform support?:
 9:       dra7:  Boot FAIL: http://slexy.org/raw/s24d4sXtTh
CONFIG_SOC_DRA7XX not present in multi_v7
10:        ldp: No Image built - Missing platform support?:
11:      panda:  Boot PASS: http://slexy.org/raw/s21KrJmEWB
12:    sdp2430: No Image built - Missing platform support?:
13:    sdp3430:  Boot PASS: http://slexy.org/raw/s21uwA3Swz
14:    sdp4430:  Boot PASS: http://slexy.org/raw/s21GE8FOPC
15:       uevm:  Boot FAIL: http://slexy.org/raw/s2E3NAziyb
mmc/regulator missing stuff
TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7

omap2plus_defconfig:
 1: am335x-evm:  Boot PASS: http://slexy.org/raw/s2euW1YeS0
 2:  am335x-sk:  Boot PASS: http://slexy.org/raw/s2nxn1i5Ea
 3: am3517-evm:  Boot PASS: http://slexy.org/raw/s20knQQExn
 4:  am37x-evm:  Boot PASS: http://slexy.org/raw/s21L1hfSHF
 5: am43xx-epos:  Boot PASS: http://slexy.org/raw/s2EpSMvtnF
 6:       beag:  Boot PASS: http://slexy.org/raw/s21Z8ytsMS
 7:       bone:  Boot PASS: http://slexy.org/raw/s21ZpxRieJ
 8:      crane: No Image built - Missing platform support?:
 9:       dra7:  Boot PASS: http://slexy.org/raw/s2owXcv5DW
10:        ldp: No Image built - Missing platform support?:
11:      panda:  Boot PASS: http://slexy.org/raw/s215rSL4p0
12:    sdp2430: No Image built - Missing platform support?:
13:    sdp3430:  Boot PASS: http://slexy.org/raw/s21dxlFJn7
14:    sdp4430:  Boot PASS: http://slexy.org/raw/s20WIfzRqi
15:       uevm:  Boot PASS: http://slexy.org/raw/s20Ba9mBTv
TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3

the 3 no image built boards have pending dts patches in for-next from
Tony and Benoit. So, linux-next should eventually be good.

As far as I see: the test results are equivalent to the branch that
Tero posted.

Thanks for the patience and effort :).
-- 
Regards,
Nishanth Menon