[PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents
khilman at ti.com
Mon Jun 27 15:04:17 EDT 2011
"Premi, Sanjeev" <premi at ti.com> writes:
>> -----Original Message-----
>> From: Tony Lindgren [mailto:tony at atomide.com]
>> Sent: Monday, June 27, 2011 6:02 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap at vger.kernel.org;
>> linux-arm-kernel at lists.infradead.org; Gregoire Gentil;
>> Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber
>> Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents
>> * Premi, Sanjeev <premi at ti.com> [110627 05:08]:
>> > > From: Tony Lindgren [mailto:tony at atomide.com]
>> > >
>> > > 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.
More information about the linux-arm-kernel