[PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents
From: Kevin Hilman <hidden>
Date: 2011-06-27 19:04:17
Also in:
linux-omap
"Premi, Sanjeev" [off-list ref] writes:
quoted
-----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 [off-list ref] [110627 05:08]:quoted
quoted
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=2I 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