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

Igor Stoppa
2008-04-17T19:53:31Z

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