* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [131210 08:08]: > On Tue, Dec 10, 2013 at 08:01:44AM -0800, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [131210 06:37]: > > > On Mon, Dec 09, 2013 at 06:42:27PM -0800, Tony Lindgren wrote: > > > > We can now finally make mach-omap2 to boot with device tree only and get > > > > rid of over 20k lines of platform init code that way. > > > > > > > > Most basic devices already work using device tree based initialization > > > > and the remaining devices can be initialized using platform data > > > > with pdata-quirks.c. > > > > > > > > So for most missing boards it's just a question of adding a .dts file > > > > that should be fairly similar to one of the existing .dts files as > > > > we've tried to cover all basic omap3 board types. > > > > > > > > For people getting started updating their board files to for device > > > > tree, there are some basic instructions in commit 8dc8b3ddf5d7 > > > > (ARM: OMAP2+: Remove legacy omap3 board-*.c files and make mach-omap2 > > > > DT only for booting). > > > > > > > > Please also note that there are also some related fixes making their way > > > > into the mainline kernel that are needed for some use cases: > > > > > > > > PM off-idle for omap3 and wake-up events need the following two patches: > > > > > > While this is good, what seems to be happening is a complete switch > > > from one method of booting to a different method of booting with no > > > compatibility inbetween. We're going from only supporting the ATAG > > > booting protocol for these platforms in v3.12 to only supporting the > > > DT booting protocol in v3.13. There's no forward or backwards > > > compatibility - it's one or the other. > > > > Hmm hey this is for v3.14, not for v3.13. > > Yes, I meant 3.14. > > > > This is bad: this is the kind of "flag day" change which Linus hates - > > > and I hate it because it means I need to update my build test system > > > at the same time that arm-soc merges this stuff. > > > > Unfortunately there's no way around that unless we carry the legacy > > booting setup for longer. We can certainly postpone the flip over if > > if there's a real neeed to do it. > > > > But if the issue is just building an appended DTB image, I'd rather just > > get done with it as that problem we're always going to have no matter > > how much we delay the flip over. > > Right, so I should just turn off building OMAP3 for the remainder of this > cycle. > > What's the fscking point me running a build system, because if I switch > it now, OMAP3 breaks. If I don't switch it now and your pull request is > merged, it breaks at that point. Fair enough, I hear you. > This is utterly insane. Well let's do this. Let's merge the parts that add stuff now, then wait a week (or longer as needed) so you have both ways working with linux next for a while. Does that sounds reasonable to you? 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
