"Premi, Sanjeev" <premi@xxxxxx> writes: >> -----Original Message----- >> From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] >> Sent: Monday, June 27, 2011 6:02 PM >> To: Premi, Sanjeev >> Cc: linux-omap@xxxxxxxxxxxxxxx; >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Gregoire Gentil; >> Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber >> Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents >> >> * Premi, Sanjeev <premi@xxxxxx> [110627 05:08]: >> > > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] >> > > >> > > I don't think omap3_beagle_init_rev is even called when >> > > the timer is set? >> > >> > [sp] I verified the patch based on the print indicating that >> > GPTIMER1 being used as clockevent source. >> > http://marc.info/?l=linux-omap&m=130893319726456&w=2 >> >> I suspect the test always fails though, so it probably never >> gets set to gptimer12 on any board :) >> > > [sp] While I take my time understanding things on devel-timer; > I had a quick question - at risk of being flamed. > > Adding a new machine ID would trickle to u-boot and same > uImage (default) may not work across board revisions. > > How does this scheme look like: > - GPTIMER1 is used as default - as it works for most boards. > - GPTIMER12 is used based on a static config option OR a > board specific bootarg > > I know both these options aren't general practice. Still > wanted to know your views in the current context. > Another option may be to always use GPTIMER1 on early boot for all boards. Later in the boot, when the old rev boards are detected, a new GPT12 clockevent could be registered (with a higher rating) such that the clockevent core would switch to the new source. Kevin -- 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
