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

[Igor Stoppa <igor.stoppa@nokia.com>]

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