Thread (1 message) 1 message, 1 author, 2011-06-27

[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=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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help