Hello Igor, On Thu, 17 Apr 2008, Igor Stoppa wrote:
> On Thu, 2008-04-17 at 13:44 -0600, ext Paul Walmsley wrote: > > > 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 agree that we shouldn't try to move the clock framework to userspace. But, determining what OPP to switch to next, based on system load or other requirements published by drivers or userspace processes; or determining what power state to put powerdomains to -- it would be nice to experiment with a userspace governor for those tasks. It would certainly make development and testing easier. > > 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. CPUFreq is good, but it does not manage non-CPU-frequency knobs very well, and there are plenty of those on OMAP3. Is there any reason why we should not allow the option of userspace OPP selection/powerdomain control for OMAP? If people don't want to use it, they don't have to :-) - Paul -- 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
