ST SPEAr: Added basic header files for SPEAr platform
in [Kernel]
|
Prev: [PATCH 2/2] fs/partition/msdos: Fix unusable extended partition for > 512B sector
Next: Driver core: Early platform kernel-doc update
From: Thomas Gleixner on 10 Mar 2010 11:40 On Wed, 10 Mar 2010, Paul Mundt wrote: > On Wed, Mar 10, 2010 at 03:41:51PM +0530, Viresh KUMAR wrote: > > As you may have seen in spear.h files in mach folders, we have multiple hardware > > timers in our design (3 in spear3xx, 4 in spear6xx and each timer have two > > independent channels. That doubles the timers count, so it is 6 and 8). > > One timer (or two channels) are used by clock event and clock source, but rest of > > the timers are still available. So we need some way to export this functionality > > of our hardware. It can be considered simply as a driver for GPT. > > > > What do you say? > > > This is hardly a unique situation for your platform, this is true for > most platforms. There's no reason why clockevents couldn't just be > extended and drivers could then just grab unused clockevents and pin them > accordingly. Most of the infrastructure is already in place for something > like that, without really having to do anything special. > > Having said that, most drivers have pretty lame reasons for trying to get > at fixed timer channels, and most of the time they can easily get by with > an hrtimer instead. There's also the issue that you're effectively > bypassing nohz by having some timer channel off on the side doing who > knows what. You would need a pretty compelling reason for why you are > sidestepping all of the existing infrastructure anyways. Right, and that's exactly the reason why we did not add the few missing bits to make clock events directly usable from drivers. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tony Lindgren on 10 Mar 2010 17:20 * Thomas Gleixner <tglx(a)linutronix.de> [100310 08:38]: > On Wed, 10 Mar 2010, Paul Mundt wrote: > > On Wed, Mar 10, 2010 at 03:41:51PM +0530, Viresh KUMAR wrote: > > > As you may have seen in spear.h files in mach folders, we have multiple hardware > > > timers in our design (3 in spear3xx, 4 in spear6xx and each timer have two > > > independent channels. That doubles the timers count, so it is 6 and 8). > > > One timer (or two channels) are used by clock event and clock source, but rest of > > > the timers are still available. So we need some way to export this functionality > > > of our hardware. It can be considered simply as a driver for GPT. > > > > > > What do you say? > > > > > This is hardly a unique situation for your platform, this is true for > > most platforms. There's no reason why clockevents couldn't just be > > extended and drivers could then just grab unused clockevents and pin them > > accordingly. Most of the infrastructure is already in place for something > > like that, without really having to do anything special. > > > > Having said that, most drivers have pretty lame reasons for trying to get > > at fixed timer channels, and most of the time they can easily get by with > > an hrtimer instead. There's also the issue that you're effectively > > bypassing nohz by having some timer channel off on the side doing who > > knows what. You would need a pretty compelling reason for why you are > > sidestepping all of the existing infrastructure anyways. > > Right, and that's exactly the reason why we did not add the few > missing bits to make clock events directly usable from drivers. Yeah still no direct users so far for the 12 hardware timers on omaps.. I guess the only use I could see is bit banging data over a few GPIO lines using a FIQ handler. Another thing to consider is that most likely all hardware timers are not able to wake up the system from idle, which would easily cause some mysterious errors for drivers. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 10 Mar 2010 18:50
On Thu, 11 Mar 2010, Paul Mundt wrote: > On Wed, Mar 10, 2010 at 02:16:53PM -0800, Tony Lindgren wrote: > > * Thomas Gleixner <tglx(a)linutronix.de> [100310 08:38]: > > > On Wed, 10 Mar 2010, Paul Mundt wrote: > > > > This is hardly a unique situation for your platform, this is true for > > > > most platforms. There's no reason why clockevents couldn't just be > > > > extended and drivers could then just grab unused clockevents and pin them > > > > accordingly. Most of the infrastructure is already in place for something > > > > like that, without really having to do anything special. > > > > > > > > Having said that, most drivers have pretty lame reasons for trying to get > > > > at fixed timer channels, and most of the time they can easily get by with > > > > an hrtimer instead. There's also the issue that you're effectively > > > > bypassing nohz by having some timer channel off on the side doing who > > > > knows what. You would need a pretty compelling reason for why you are > > > > sidestepping all of the existing infrastructure anyways. > > > > > > Right, and that's exactly the reason why we did not add the few > > > missing bits to make clock events directly usable from drivers. > > > > Yeah still no direct users so far for the 12 hardware timers on > > omaps.. I guess the only use I could see is bit banging data > > over a few GPIO lines using a FIQ handler. > > > > Another thing to consider is that most likely all hardware timers > > are not able to wake up the system from idle, which would easily > > cause some mysterious errors for drivers. > > > Even if most drivers shouldn't be touching clockevents directly, there > are still legitimate cases. In SMP configurations where a single timer > block is shared across multiple CPUs it would be easier to have the boot > CPU register all of the timer channels under clockevents and have the > secondaries grab one at random for setting up their local timers. (Even > if they're not truly "local" timers, it's still a better situation than > broadcast IPIs). clockevents would need some minor extension, including > dealing with unregistration for the CPU hotplug case, but it's a pretty > good fit for the problem otherwise. No objections against that, but that's not a use case for drivers and limited to (arch) core code functionality. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |