| Message ID | 1309171009-8075-1-git-send-email-premi@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Sanjeev Premi <premi@ti.com> [110627 03:33]: > From: Hrishikesh Bhandiwad <hrishikesh.b@ti.com> > > Present current selection of the GPTIMER on Beagleboard > was result of a hardware issue in early versions of the > Beagleboards (Ax and B1 thru B4). [1][2] > > Its been long since the hardware issue has been fixed. > This patch uses GPTIMER 1 for all newer board revisions > incl. Beagleboard XM. > > Also, the clock source for GPTIMER12 is much less frequency > stable than clock sources for GPTIMER1. Using GPTIMER12 can > result in major time skew over a fairly short interval. I don't think omap3_beagle_init_rev is even called when the timer is set? But even if it was, this is not a good fix because of the dependency issues it causes to mux and gpio framework in omap3_beagle_rev_init. The best way to fix this is to set a separate machine ID for the working beagle boards like I commented earlier. It allows just setting the .timer based on that, the rest of the code can be shared. Regards, Tony
> -----Original Message----- > From: Tony Lindgren [mailto:tony@atomide.com] > Sent: Monday, June 27, 2011 4:46 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; Gregoire Gentil; > Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber > Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents > > * Sanjeev Premi <premi@ti.com> [110627 03:33]: > > From: Hrishikesh Bhandiwad <hrishikesh.b@ti.com> > > > > Present current selection of the GPTIMER on Beagleboard > > was result of a hardware issue in early versions of the > > Beagleboards (Ax and B1 thru B4). [1][2] > > > > Its been long since the hardware issue has been fixed. > > This patch uses GPTIMER 1 for all newer board revisions > > incl. Beagleboard XM. > > > > Also, the clock source for GPTIMER12 is much less frequency > > stable than clock sources for GPTIMER1. Using GPTIMER12 can > > result in major time skew over a fairly short interval. > > 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 > > But even if it was, this is not a good fix because of the > dependency issues it causes to mux and gpio framework in > omap3_beagle_rev_init. > > The best way to fix this is to set a separate machine ID > for the working beagle boards like I commented earlier. > It allows just setting the .timer based on that, the rest > of the code can be shared. [sp] Sorry missed reading your comment. I wasn't checking mails while sending the updated patch. > > Regards, > > Tony >
* Premi, Sanjeev <premi@ti.com> [110627 05:08]: > > From: Tony Lindgren [mailto:tony@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 :) Tony
> -----Original Message----- > From: Tony Lindgren [mailto:tony@atomide.com] > Sent: Monday, June 27, 2011 6:02 PM > To: Premi, Sanjeev > Cc: linux-omap@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; Gregoire Gentil; > Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber > Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents > > * Premi, Sanjeev <premi@ti.com> [110627 05:08]: > > > From: Tony Lindgren [mailto:tony@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. ~sanjeev > Tony >
* Premi, Sanjeev <premi@ti.com> [110627 06:24]: > > [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. Yes that's a hassle :( Until we have device tree, maybe see if u-boot passes ATAG_REVISION that's available as system_rev in kernel? > 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. Let's not do a Kconfig option, but a cmdline option should work if done in a generic way. If you decide to go that way, then please add that to timer.c against devel-timer branch. Regards, Tony
"Premi, Sanjeev" <premi@ti.com> writes: >> -----Original Message----- >> From: Tony Lindgren [mailto:tony@atomide.com] >> Sent: Monday, June 27, 2011 6:02 PM >> To: Premi, Sanjeev >> Cc: linux-omap@vger.kernel.org; >> linux-arm-kernel@lists.infradead.org; Gregoire Gentil; >> Bhandiwad, Hrishikesh; Jason Lam; Thomas Weber >> Subject: Re: [PATCHv2] omap3: beagle: Use GPTIMER1 for clockevents >> >> * Premi, Sanjeev <premi@ti.com> [110627 05:08]: >> > > From: Tony Lindgren [mailto:tony@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. Kevin
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index 4b113b2..edc1596 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -509,7 +509,10 @@ static void __init omap3_beagle_init_irq(void) { omap_init_irq(); #ifdef CONFIG_OMAP_32K_TIMER - omap2_gp_clockevent_set_gptimer(12); + if (omap3_beagle_version == OMAP3BEAGLE_BOARD_AXBX) + omap2_gp_clockevent_set_gptimer(12); + else + omap2_gp_clockevent_set_gptimer(1); #endif }