Hi all, On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: > Hello Hiroshi, David, > > On Thu, 17 Apr 2008, David Brownell wrote: > > > On Thursday 17 April 2008, Hiroshi DOYU wrote: > > > > > And if there will be a little possibility that sysfs attribute can be > > > used by userland in the future, keeping sysfs instead of debugfs > > > doesn't seem not so illegal, does it? > > True, but if we can do a debugfs implementation first, then that seems > like a good way to start, no? Userspace PM implementations are probably > some months in the future, and we can mandate that debugfs be mounted for > those.
I can hardly see the benefit of a userspace implementation, considering the extra context switch required and the fact the in many cases clocks get enabled in response to irqs. > > I happen to think that the clock tree is sensitive enough > > that it should not be managed from userspace in production > > systems. (Except possibly through driver-specific APIs which > > ensure the right rules are followed.) Too easy to break things > > otherwise. > > In terms of the clock tree, it would be good to allow userspace-driven OPP > changes, analogous to CPUFreq's userspace governor. [ In general, I agree > that userspace should not be changing driver clocks directly, just like > userspace should not be mucking around in /dev/mem directly :-) ] That also sounds akward at best: cpufreq (or similar) is much better suited for this sort of activity; userspace governor would be the userspace controller you refer to, but it is far from being optimal. Userspace should limit itself to changing policies. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices R&D - Helsinki -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
