> -----Original Message----- > From: Paul Walmsley [mailto:paul@xxxxxxxxx] > Sent: Monday, June 27, 2011 9:00 PM > To: Premi, Sanjeev; Tony Lindgren > Cc: Koen Kooi; linux-omap@xxxxxxxxxxxxxxx List; linux-arm-kernel > Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents > > On Mon, 27 Jun 2011, Tony Lindgren wrote: > > > This fix will cause bad dependency issues with sys_timer. > > > > This patch has a dependency to omap3_beagle_init_rev, which > depends on > > the mux framework and gpio framework. Not cool for > init_early. We just > > want to initialize sys_timer early without any complicated > dependencies. > > > > The best way to fix this is to set a separate machine ID > for the properly > > working beagle boards like xm, then just set the .timer > entry to omap3_timer > > for working beagle boards and omap3_secure_timer for > non-working beagle > > boards. The rest of the board-*.c file can be shared. > > Sanjeev, want to take care of this? Machine ID update info is in > linux/arch/arm/tools/mach-types. > > This strategy will unfortunately involve patching > bootloaders. But if the > default is to use GPT12, it should work out okay. [sp] Just sent another query to Tony on this specific issue. But, if different mach-type is the way forward, then I will take it forward. > > Hopefully we won't have to do the same thing for the other > Beagle-derived > boards, Devkit8000, Touchbook, etc. etc. Then again, I > suppose this will > eventually just be another property passed in via DT, with a single > machine ID. [sp] Can you look at my query to Tony? Will that be an acceptable workaround until DT. Going to two machine IDs and then unifying back again could cause confusion - esp. during transition times. ~sanjeev > > > The above assumes the patches in devel-timer branch where > we no longer > > have the non-standard timer interface, but use the sys_timer entries > > instead like we should. > > > - Paul > -- 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
