From: Tony Lindgren <tony@atomide.com> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org Subject: Re: [PATCH 00/10] omap init_early changes for irq and timer init Date: Thu, 31 Mar 2011 10:32:12 -0700 [thread overview] Message-ID: <20110331173212.GB21887@atomide.com> (raw) In-Reply-To: <4D943871.4030206@ti.com> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110331 01:14]: > On 3/30/2011 11:52 PM, Tony Lindgren wrote: > > >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. > >For removing the old interface, I don't see any reason to > >select timer combinations on omap3 other than omap3_timer > >and omap3_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. > > > 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? > >>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. > > > 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. > 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
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/10] omap init_early changes for irq and timer init Date: Thu, 31 Mar 2011 10:32:12 -0700 [thread overview] Message-ID: <20110331173212.GB21887@atomide.com> (raw) In-Reply-To: <4D943871.4030206@ti.com> * Santosh Shilimkar <santosh.shilimkar@ti.com> [110331 01:14]: > On 3/30/2011 11:52 PM, Tony Lindgren wrote: > > >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. > >For removing the old interface, I don't see any reason to > >select timer combinations on omap3 other than omap3_timer > >and omap3_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. > > > 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? > >>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. > > > 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. > 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
next prev parent reply other threads:[~2011-03-31 17:32 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-03-28 22:21 [PATCH 00/10] omap init_early changes for irq and timer init Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 01/10] omap: Use separate init_irq functions to avoid cpu_is_omap tests early Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 6:11 ` [PATCH 01/10] omap: Use separate init_irq functions to avoidcpu_is_omap " Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 6:11 ` Santosh Shilimkar 2011-03-29 15:30 ` Tony Lindgren 2011-03-29 15:30 ` Tony Lindgren 2011-03-29 22:27 ` Tony Lindgren 2011-03-29 22:27 ` Tony Lindgren 2011-03-29 17:11 ` [PATCH 01/10] omap: Use separate init_irq functions to avoid cpu_is_omap " Kevin Hilman 2011-03-29 17:11 ` Kevin Hilman 2011-03-29 17:14 ` Tony Lindgren 2011-03-29 17:14 ` Tony Lindgren 2011-05-17 11:28 ` Tony Lindgren 2011-05-17 11:28 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 02/10] omap: Set separate timer init functions to avoid cpu_is_omap tests Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 03/10] omap: Move dmtimer defines to dmtimer.h Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:41 ` Kevin Hilman 2011-03-29 17:41 ` Kevin Hilman 2011-03-29 17:44 ` Tony Lindgren 2011-03-29 17:44 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 04/10] omap: Make a subset of dmtimer functions into inline functions Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:51 ` Kevin Hilman 2011-03-29 17:51 ` Kevin Hilman 2011-03-29 17:58 ` Tony Lindgren 2011-03-29 17:58 ` Tony Lindgren 2011-03-29 18:01 ` Kevin Hilman 2011-03-29 18:01 ` Kevin Hilman 2011-03-29 18:02 ` Tony Lindgren 2011-03-29 18:02 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 05/10] omap2+: Use dmtimer macros for clockevent Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 17:16 ` Tony Lindgren 2011-03-29 17:16 ` Tony Lindgren 2011-03-31 21:35 ` Kevin Hilman 2011-03-31 21:35 ` Kevin Hilman 2011-03-31 22:04 ` Tony Lindgren 2011-03-31 22:04 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 06/10] omap2+: Remove gptimer_wakekup for now Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-31 22:09 ` Kevin Hilman 2011-03-31 22:09 ` Kevin Hilman 2011-04-01 16:26 ` Santosh Shilimkar 2011-04-01 16:26 ` Santosh Shilimkar 2011-03-28 22:21 ` [PATCH 07/10] omap2+: Reserve clocksource and timesource and initialize dmtimer later Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 08/10] omap2+: Use dmtimer macros for clocksource Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 09/10] omap2+: Remove omap2_gp_clockevent_set_gptimer Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-28 22:21 ` [PATCH 10/10] omap2+: Rename timer-gp.c into timer.c to combine timer init functions Tony Lindgren 2011-03-28 22:21 ` Tony Lindgren 2011-03-29 18:16 ` [PATCH 00/10] omap init_early changes for irq and timer init Kevin Hilman 2011-03-29 18:16 ` Kevin Hilman 2011-03-30 7:56 ` Santosh Shilimkar 2011-03-30 7:56 ` Santosh Shilimkar 2011-03-30 18:22 ` Tony Lindgren 2011-03-30 18:22 ` Tony Lindgren 2011-03-31 8:16 ` Santosh Shilimkar 2011-03-31 8:16 ` Santosh Shilimkar 2011-03-31 17:32 ` Tony Lindgren [this message] 2011-03-31 17:32 ` Tony Lindgren 2011-04-01 8:39 ` Santosh Shilimkar 2011-04-01 8:39 ` Santosh Shilimkar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20110331173212.GB21887@atomide.com \ --to=tony@atomide.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=santosh.shilimkar@ti.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.