omap init_early changes for irq and timer init
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest1 of 10 patches 0 repliesNew
1 of 10 patches is in this archive. The cover letter announces 10.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 6/10 | omap2+: Remove gptimer_wakekup for now | +0 | 0 replies |
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 37 lines · Tony Lindgren
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.
Quoted 5 lines
Maybe let's call the
omap3_beagle_timeromap3_secure_timerinstead?That should solve your issue of having the board name show up in the generic code, no?
Sorry about picking up on names but that was not my point. I agree with you on reducing interfaces so I step back on this point.
Quoted 23 lines
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.
Quoted 4 lines
Except we should improve things eventually where we don't need to program the slow external timer during runtime if we have local timers.
This is already the case now. On OMAP4 running system, CPU use their own local timers and rq's. There is no broadcasting. Whenever there is a need of it like the situations where local-timers die (low power states), timer system switches to broad-cast timer which is wakeup capable. GPT1 in our case. This is all managed by timer framework and works seamlessly.
Quoted 2 lines
Hmm maybe I'm wrong and you got that working already?
I don't think you are wrong. All your points are correct. The only missing point was the necessity of GPT1 registered as clock-event to allow dynamic switching between clock-events.
That's where I was saying that we are not left with GPT1 for PM debug feature.
Regards
Santosh