sleeping clk_[enable,disable]?

sleeping clk_[enable,disable]?

[Linus Walleij]

A question here:

If you have a clocking hardware that would actually require
clk_[enable,disable] to
sleep in order to ascertain that the clock is actually in the
requested state when
you return from these functions, what can you do?

I could think of several solutions, like:

* Actually let clk_[enable,disable] sleep, make sure all drivers only calls them
  in thread context.

* Impose a state in the clk so it can be "in transition", then an
additional function
  clk_is_stable() which will also have to be added to most drivers but had the
  advantage of not violating the defined clk_[enable,disable] API.

* Throw in udelay():s after the clk_[enable,disable] calls, with some values
  that are unfortunately then spread out in the drivers instead of in the
  clk implementation.

Any ideas?

Linus Walleij

sleeping clk_[enable,disable]?

[Rabin Vincent]

On Tue, Feb 23, 2010 at 03:32:19PM +0100, Linus Walleij wrote:
> * Throw in udelay():s after the clk_[enable,disable] calls, with some values
>   that are unfortunately then spread out in the drivers instead of in the
>   clk implementation.

Or you could place the udelay()s inside the clk_* calls themselves.  See
mach-pxa/clock.c or plat-stmp3xxx/clock.c.

Rabin

sleeping clk_[enable,disable]?

[Linus Walleij]

2010/2/23 Rabin Vincent <rabin@rab.in>:

> On Tue, Feb 23, 2010 at 03:32:19PM +0100, Linus Walleij wrote:

>> * Throw in udelay():s after the clk_[enable,disable] calls, with some values
>> ? that are unfortunately then spread out in the drivers instead of in the
>> ? clk implementation.
>
> Or you could place the udelay()s inside the clk_* calls themselves. ?See
> mach-pxa/clock.c or plat-stmp3xxx/clock.c.

Hm, yeah pxa has a the maximum defined delay 5 us, and stmp3xx has
a maximum of 10 us both probably acceptable delays in a fastpath. So your
system latency requirements control the limit here and in that case ...
perhaps one would better just switch all interrupt handlers where a
clk_enable/disable occurs to threaded anyway just to be on the safe
side. (Just thinking aloud a bit...)

Yours,
Linus Walleij

sleeping clk_[enable,disable]?

[Uwe Kleine-König]

Hello,

On Tue, Feb 23, 2010 at 03:32:19PM +0100, Linus Walleij wrote:
> A question here:
> 
> If you have a clocking hardware that would actually require
> clk_[enable,disable] to
> sleep in order to ascertain that the clock is actually in the
> requested state when
> you return from these functions, what can you do?
> 
> I could think of several solutions, like:
> 
> * Actually let clk_[enable,disable] sleep, make sure all drivers only calls them
>   in thread context.
> 
> * Impose a state in the clk so it can be "in transition", then an
> additional function
>   clk_is_stable() which will also have to be added to most drivers but had the
>   advantage of not violating the defined clk_[enable,disable] API.
> 
> * Throw in udelay():s after the clk_[enable,disable] calls, with some values
>   that are unfortunately then spread out in the drivers instead of in the
>   clk implementation.
I had a similar problem some time ago, and choosed to let
clk_{en,dis}able sleep.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |