omap init_early changes for irq and timer init
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 10 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 10 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/10] omap init_early changes for irq and timer init
Quoted 9 lines · Santosh Shilimkar
Quoted 4 lines · Tony Lindgren
What it does not have is the code to dedicate gpt1 for PM code, which can be done later once all the other dmtimer changes are done.
Which not possible to do unless you plan to hack generic timer framework or waste additional timer hardware for this.
Well an extra timer hardware would only be needed on omap2 & 3.
But hey, if it makes sense to do or not to do is a different set of patches. At least we now have an option to play with it.
Quoted 8 lines
Quoted 8 lines
For removing the old interface, I don't see any reason to select timer combinations on omap3 other than
omap3_timerandomap3_beagle_timer.If there's need, any new valid sane combinations can be esily added, although I seriously doubt that we'll need more for omap3.
Quoted 7 lines
May be I am wrong but the point is about the merit of the solution even if there are only couple of board files where we use that interface.
It much cleaner and simpler to say timerid=X, from board file rather than creating a "struct
sys_timer" instance and putting that in timer code.
Well the timerid=X adds yet another interface and more calls from board-*.c to the common code. And it requires more changes if beagle boards want to use the system clock as the source clock instead of the 32KiHZ source.
Maybe let's call the omap3_beagle_timer omap3_secure_timer instead?
That should solve your issue of having the board name show up in the generic code, no?
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines
At least I don't see other solution than using GPT1 for wakeup.
Right, there's no other way to wake except gpt1 or wake-up enabled gpio lines. But we don't need to use gpt1 during runtime at all.
Quoted 5 lines
This is not entirely correct and I think this is the point where we are not on same page. During runtime, gpt1 clock event is not used for tick generation but it's kept programmed because low power state switch via
get triggered any time and on any CPU.
Well ideally we would not program it during runtime at all because it's slow to program. I don't think that can be currently done with the sys_timer.
Quoted 5 lines
This is the same problem as X86 APIC timer + HPET switching and I worked with Thomas G and Russell to get this working on ARM platforms using generic timer framework. No hacking is needed in PM code for this.
Except we should improve things eventually where we don't need to program the slow external timer during runtime if we have local timers.
Hmm maybe I'm wrong and you got that working already?
Regards,
Tony