Re: [PATCH 1/2] ARM: OMAP: CLKFW: Initial debugfs support for omap clock framework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux