* Tony Lindgren <tony@xxxxxxxxxxx> [120923 12:11]: > * Paul Walmsley <paul@xxxxxxxxx> [120922 10:48]: > > On Fri, 21 Sep 2012, Tony Lindgren wrote: > > > > > Hmm I wonder what's causing it then? There must be something > > > else in tmp-merge at commit abfee61f that causes the problems. > > > Maybe try to merge with that commit and see what you get? > > > > Probably the merge with the clock patches was causing trouble. > > > > > That commit can't be used as a base though as that's temporary > > > most likely.. But we can create a base to use out of the > > > branches once we know them, you can do it yourself too. > > > > Your tmp-merge contains branch/tag merges that haven't yet gone upstream > > to arm-soc. I don't know which of those merges you consider stable (aside > > from the upstream ones, obviously). For this one it looks like the clock > > patches were the ones causing the merge trouble. So since that series > > also came from me and is unmerged, will just merge the clock and hwmod > > patches into a new pull request on v3.6-rc6 + cleanup-fixes-for-v3.7 + > > omap-devel-am33xx-for-v3.7. Hopefully that will work for you... > > Well tmp-merge is a merge of the upstream branches, but the branch > itself is temporary. The issue here is that's it's too messy to get > your branch merged currently because of the various merge conflicts with > other branches. Trying to merge in your updated branch for testing > into tmp-merge with the other branches produces: > > CONFLICT (content): Merge conflict in drivers/spi/spi-omap2-mcspi.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/gpmc.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/devices.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_dpll.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt_clksel.c > CONFLICT (content): Merge conflict in arch/arm/mach-omap2/clkt34xx_dpll3m2.c > > It seems to be conflicting with your own formatting changes, > am33xx changes, PMU changes and RNG changes. Sounds like we're > safest to wait for -rc1 to for the dependencies to clear? Or maybe it's possible to split the series into smaller chunks that can be pulled in to the existing branches without causing new merge conflicts? > Regards, > > Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
