Locking in the clk API

Locking in the clk API

[Jeremy Kerr]

Hi all,

I'd like to define some locking semantics for the clk API, so that device 
driver can have some assurance about when it is safe to call various clk_ 
functions from atomic contexts.

Vincent - you mentioned in a conversation that your code had some specific 
requirements for clock enable/disable at interrupt time - could you reply with 
an outline of this? Also, Sascha and Uwe: do you have any thoughts from your 
work with the common struct clk?

= Requirements =

To get things started, here are some basic requirements from the external API 
side:

1) clk_enable: the clock should be outputting a valid clock signal before
   returning from this function.

    - drivers may require valid clock signal to be present for subsequent
      device interactions.

3) clk_disable: may be called from atomic context

    - Vincent: this is what I recall from our conversation, is it still true?

4) clk_set_rate: clock should change to the new rate before this returns

5) clk_get_rate: may be called from atomic context

6) in general, drivers shouldn't require details about the clock
   implementation

And from the clock implementation side:

7) interactions with clock hardware may require sleeping (eg, clocks on an i2c
   bus)

8) clk_enable() may require enabling a parent, which may also require
   sleeping. Ideally, we shouldn't have to care about the parent's
   implementation.

I'm sure there are others, please feel free to add to this list.

= Implementation =

At present, we can satisfy these with:

* clk_enable: may sleep

* clk_disable: may not sleep, but it's possible to make the global
  clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
  non-atomic context.

* clk_get_rate: may not sleep

* clk_set_rate: may sleep

As we build up our requirements, we can adjust as suitable.

I'm excluding clk_{get,set}_parent at present, as I'm not sure we want these 
as part of the device-driver API (ie, they require knowledge of the platform 
clock infrastructure).

Thanks,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi all,

I'd like to define some locking semantics for the clk API, so that device 
driver can have some assurance about when it is safe to call various clk_ 
functions from atomic contexts.

Vincent - you mentioned in a conversation that your code had some specific 
requirements for clock enable/disable at interrupt time - could you reply with 
an outline of this? Also, Sascha and Uwe: do you have any thoughts from your 
work with the common struct clk?

== Requirements ==

To get things started, here are some basic requirements from the external API 
side:

1) clk_enable: the clock should be outputting a valid clock signal before
   returning from this function.

    - drivers may require valid clock signal to be present for subsequent
      device interactions.

3) clk_disable: may be called from atomic context

    - Vincent: this is what I recall from our conversation, is it still true?

4) clk_set_rate: clock should change to the new rate before this returns

5) clk_get_rate: may be called from atomic context

6) in general, drivers shouldn't require details about the clock
   implementation

And from the clock implementation side:

7) interactions with clock hardware may require sleeping (eg, clocks on an i2c
   bus)

8) clk_enable() may require enabling a parent, which may also require
   sleeping. Ideally, we shouldn't have to care about the parent's
   implementation.

I'm sure there are others, please feel free to add to this list.

== Implementation ==

At present, we can satisfy these with:

* clk_enable: may sleep

* clk_disable: may not sleep, but it's possible to make the global
  clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
  non-atomic context.

* clk_get_rate: may not sleep

* clk_set_rate: may sleep

As we build up our requirements, we can adjust as suitable.

I'm excluding clk_{get,set}_parent at present, as I'm not sure we want these 
as part of the device-driver API (ie, they require knowledge of the platform 
clock infrastructure).

Thanks,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi all,

I'd like to define some locking semantics for the clk API, so that device 
driver can have some assurance about when it is safe to call various clk_ 
functions from atomic contexts.

Vincent - you mentioned in a conversation that your code had some specific 
requirements for clock enable/disable at interrupt time - could you reply with 
an outline of this? Also, Sascha and Uwe: do you have any thoughts from your 
work with the common struct clk?

== Requirements ==

To get things started, here are some basic requirements from the external API 
side:

1) clk_enable: the clock should be outputting a valid clock signal before
   returning from this function.

    - drivers may require valid clock signal to be present for subsequent
      device interactions.

3) clk_disable: may be called from atomic context

    - Vincent: this is what I recall from our conversation, is it still true?

4) clk_set_rate: clock should change to the new rate before this returns

5) clk_get_rate: may be called from atomic context

6) in general, drivers shouldn't require details about the clock
   implementation

And from the clock implementation side:

7) interactions with clock hardware may require sleeping (eg, clocks on an i2c
   bus)

8) clk_enable() may require enabling a parent, which may also require
   sleeping. Ideally, we shouldn't have to care about the parent's
   implementation.

I'm sure there are others, please feel free to add to this list.

== Implementation ==

At present, we can satisfy these with:

* clk_enable: may sleep

* clk_disable: may not sleep, but it's possible to make the global
  clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
  non-atomic context.

* clk_get_rate: may not sleep

* clk_set_rate: may sleep

As we build up our requirements, we can adjust as suitable.

I'm excluding clk_{get,set}_parent at present, as I'm not sure we want these 
as part of the device-driver API (ie, they require knowledge of the platform 
clock infrastructure).

Thanks,


Jeremy

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> * clk_enable: may sleep
> 
> * clk_disable: may not sleep, but it's possible to make the global
>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>   non-atomic context.
> 
> * clk_get_rate: may not sleep
> 
> * clk_set_rate: may sleep
> 
> As we build up our requirements, we can adjust as suitable.
> 
This looks like a complete disaster, and is also completely inconsistent
with how the API is being used by the vast majority of users today. You
have an API that can or can not sleep with no indication as to which is
which based off of the API naming, which is just asking for trouble.

As it is today, most users expect that these are all usable from atomic
context, and as far as I can tell the only special case you have are for
some crap busses with insane latencies. In this case you should simply
pile on _cansleep() versions of the API and make it apparent that those
drivers are the special cases, not the other way around.

Having half of the API sleepable and the other not with no indication of
which is which simply makes it completely unusable and error prone for
both atomic and non-atomic contexts.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> * clk_enable: may sleep
> 
> * clk_disable: may not sleep, but it's possible to make the global
>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>   non-atomic context.
> 
> * clk_get_rate: may not sleep
> 
> * clk_set_rate: may sleep
> 
> As we build up our requirements, we can adjust as suitable.
> 
This looks like a complete disaster, and is also completely inconsistent
with how the API is being used by the vast majority of users today. You
have an API that can or can not sleep with no indication as to which is
which based off of the API naming, which is just asking for trouble.

As it is today, most users expect that these are all usable from atomic
context, and as far as I can tell the only special case you have are for
some crap busses with insane latencies. In this case you should simply
pile on _cansleep() versions of the API and make it apparent that those
drivers are the special cases, not the other way around.

Having half of the API sleepable and the other not with no indication of
which is which simply makes it completely unusable and error prone for
both atomic and non-atomic contexts.

Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> * clk_enable: may sleep
> 
> * clk_disable: may not sleep, but it's possible to make the global
>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>   non-atomic context.
> 
> * clk_get_rate: may not sleep
> 
> * clk_set_rate: may sleep
> 
> As we build up our requirements, we can adjust as suitable.
> 
This looks like a complete disaster, and is also completely inconsistent
with how the API is being used by the vast majority of users today. You
have an API that can or can not sleep with no indication as to which is
which based off of the API naming, which is just asking for trouble.

As it is today, most users expect that these are all usable from atomic
context, and as far as I can tell the only special case you have are for
some crap busses with insane latencies. In this case you should simply
pile on _cansleep() versions of the API and make it apparent that those
drivers are the special cases, not the other way around.

Having half of the API sleepable and the other not with no indication of
which is which simply makes it completely unusable and error prone for
both atomic and non-atomic contexts.

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today.

I've been basing this on the mxc clock code, which acquires a mutex for all 
clk_enable()s. This may not be representative of the majority of clock usage.

From a quick search there are a few other cases of non-atomic clock usage:

tcc:		clk_enable() acquires a global clocks_mutex
tegra:	has a clk_enable_cansleep()
davinci: clk_set_parent() aquires a global clocks_mutex

Excluding the davinci code (we won't worry about set_parent for now...), if we 
can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
purely atomic operations.

We'd still need some method of using sleeping clocks though. How about making 
clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
the cases where clk->ops.enable may sleep.

Do we need something similar for other parts of the API? (clk_set_rate?)

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today.

I've been basing this on the mxc clock code, which acquires a mutex for all 
clk_enable()s. This may not be representative of the majority of clock usage.

>From a quick search there are a few other cases of non-atomic clock usage:

tcc:		clk_enable() acquires a global clocks_mutex
tegra:	has a clk_enable_cansleep()
davinci: clk_set_parent() aquires a global clocks_mutex

Excluding the davinci code (we won't worry about set_parent for now...), if we 
can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
purely atomic operations.

We'd still need some method of using sleeping clocks though. How about making 
clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
the cases where clk->ops.enable may sleep.

Do we need something similar for other parts of the API? (clk_set_rate?)

Cheers,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today.

I've been basing this on the mxc clock code, which acquires a mutex for all 
clk_enable()s. This may not be representative of the majority of clock usage.

>From a quick search there are a few other cases of non-atomic clock usage:

tcc:		clk_enable() acquires a global clocks_mutex
tegra:	has a clk_enable_cansleep()
davinci: clk_set_parent() aquires a global clocks_mutex

Excluding the davinci code (we won't worry about set_parent for now...), if we 
can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
purely atomic operations.

We'd still need some method of using sleeping clocks though. How about making 
clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
the cases where clk->ops.enable may sleep.

Do we need something similar for other parts of the API? (clk_set_rate?)

Cheers,


Jeremy

Re: Locking in the clk API

[Paul Mundt]

Hi Jeremy,

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.
> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.
> 
Yes, that sounds reasonable. I don't particularly care for the atomic
flag on the clock however since that's really the default behaviour for
almost everyone at the moment. On the other hand, the mutex API will
already blow up if someone tries to grab it within atomic context (with
the _trylock exception). Still, making the API explicit and tossing in a
might_sleep() or so will at least help figure out which assumptions are
being made and/or violated.

> Do we need something similar for other parts of the API? (clk_set_rate?)
> 
I suppose that's an inevitable thing at least in terms of keeping the API
balanced and consistent.

One other thing to be aware of is that the clkdev code maintains its own
list mutex, so the addition and deletion of clkdev lookups in addition to
the clkdev-backed clk_get() will all be sleepable. It would however be
possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
for the common cases, but it's not entirely obvious that it would be
worth the complexity it would introduce.

If you're going to do this work it would also be helpful to spell out the
locking semantics within linux/clk.h at the same time (it might even be
worthwhile doing this incrementally and getting all of the platforms
in-line before attempting to consolidate things too aggressively), as
it's apparent from the cases you cite there are at least a couple of
boards that aren't quite in line with what everyone else is doing.

In general we have to accept that the dynamic creation, deletion, and
looking up of clocks is going to be a sleepable case, and the rest will
likely have to be split out in to _cansleep and default atomic-safe
variants.

set_rate/parent and friends likewise are done atomically for some and
sleepable for others, so it doesn't seem like there's going to be much
choice other than simply splitting out the API for these cases.

Also, I'm not sure if you've noticed yet or not, but note that there is
now a drivers/clk due to the shuffling of the clkdev code, so you may
want to piggyback on top of this instead of using the top-level kernel/

Re: Locking in the clk API

[Paul Mundt]

Hi Jeremy,

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.
> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.
> 
Yes, that sounds reasonable. I don't particularly care for the atomic
flag on the clock however since that's really the default behaviour for
almost everyone at the moment. On the other hand, the mutex API will
already blow up if someone tries to grab it within atomic context (with
the _trylock exception). Still, making the API explicit and tossing in a
might_sleep() or so will at least help figure out which assumptions are
being made and/or violated.

> Do we need something similar for other parts of the API? (clk_set_rate?)
> 
I suppose that's an inevitable thing at least in terms of keeping the API
balanced and consistent.

One other thing to be aware of is that the clkdev code maintains its own
list mutex, so the addition and deletion of clkdev lookups in addition to
the clkdev-backed clk_get() will all be sleepable. It would however be
possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
for the common cases, but it's not entirely obvious that it would be
worth the complexity it would introduce.

If you're going to do this work it would also be helpful to spell out the
locking semantics within linux/clk.h at the same time (it might even be
worthwhile doing this incrementally and getting all of the platforms
in-line before attempting to consolidate things too aggressively), as
it's apparent from the cases you cite there are at least a couple of
boards that aren't quite in line with what everyone else is doing.

In general we have to accept that the dynamic creation, deletion, and
looking up of clocks is going to be a sleepable case, and the rest will
likely have to be split out in to _cansleep and default atomic-safe
variants.

set_rate/parent and friends likewise are done atomically for some and
sleepable for others, so it doesn't seem like there's going to be much
choice other than simply splitting out the API for these cases.

Also, I'm not sure if you've noticed yet or not, but note that there is
now a drivers/clk due to the shuffling of the clkdev code, so you may
want to piggyback on top of this instead of using the top-level kernel/

Locking in the clk API

[Paul Mundt]

Hi Jeremy,

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.
> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.
> 
Yes, that sounds reasonable. I don't particularly care for the atomic
flag on the clock however since that's really the default behaviour for
almost everyone at the moment. On the other hand, the mutex API will
already blow up if someone tries to grab it within atomic context (with
the _trylock exception). Still, making the API explicit and tossing in a
might_sleep() or so will at least help figure out which assumptions are
being made and/or violated.

> Do we need something similar for other parts of the API? (clk_set_rate?)
> 
I suppose that's an inevitable thing at least in terms of keeping the API
balanced and consistent.

One other thing to be aware of is that the clkdev code maintains its own
list mutex, so the addition and deletion of clkdev lookups in addition to
the clkdev-backed clk_get() will all be sleepable. It would however be
possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
for the common cases, but it's not entirely obvious that it would be
worth the complexity it would introduce.

If you're going to do this work it would also be helpful to spell out the
locking semantics within linux/clk.h at the same time (it might even be
worthwhile doing this incrementally and getting all of the platforms
in-line before attempting to consolidate things too aggressively), as
it's apparent from the cases you cite there are at least a couple of
boards that aren't quite in line with what everyone else is doing.

In general we have to accept that the dynamic creation, deletion, and
looking up of clocks is going to be a sleepable case, and the rest will
likely have to be split out in to _cansleep and default atomic-safe
variants.

set_rate/parent and friends likewise are done atomically for some and
sleepable for others, so it doesn't seem like there's going to be much
choice other than simply splitting out the API for these cases.

Also, I'm not sure if you've noticed yet or not, but note that there is
now a drivers/clk due to the shuffling of the clkdev code, so you may
want to piggyback on top of this instead of using the top-level kernel/

Re: Locking in the clk API

[Sascha Hauer]

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.

For i.MX we can generally turn this into a spinlock. There are some exceptions
though. Most clocks directly visible for drivers are simple clock gates
which can be made atomic. The root clocks are often enough plls which
can't be enabled atomically, but where we have to spin until the pll is
locked. So we we have exactly the case Russell described: Whether we can
enable a clocks atomically depends on the parent (pll) being enabled or
disabled. We can work around this by calling clk_enable to the pll
explicitely from the platform code.

> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.

Quoting Russell:

> I hate the GPIO APIs for doing this _cansleep crap as the decision of
> whether to use the _cansleep or normal APIs normally can't be made at
> the time when the API is used, but sometime later.  Many people just use
> the non-_cansleep versions irrespective of the context they're in -
> which is unnecessarily restrictive - consider what happens if you then
> have that driver use a GPIO on an I2C peripheral...

Sounds like we should rather have s sleeping clk_enable and a
clk_enable_atomic. This way people can use standard clk_enable until
a 'scheduling while atomic' gives a hint in the right direction.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Locking in the clk API

[Sascha Hauer]

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.

For i.MX we can generally turn this into a spinlock. There are some exceptions
though. Most clocks directly visible for drivers are simple clock gates
which can be made atomic. The root clocks are often enough plls which
can't be enabled atomically, but where we have to spin until the pll is
locked. So we we have exactly the case Russell described: Whether we can
enable a clocks atomically depends on the parent (pll) being enabled or
disabled. We can work around this by calling clk_enable to the pll
explicitely from the platform code.

> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.

Quoting Russell:

> I hate the GPIO APIs for doing this _cansleep crap as the decision of
> whether to use the _cansleep or normal APIs normally can't be made at
> the time when the API is used, but sometime later.  Many people just use
> the non-_cansleep versions irrespective of the context they're in -
> which is unnecessarily restrictive - consider what happens if you then
> have that driver use a GPIO on an I2C peripheral...

Sounds like we should rather have s sleeping clk_enable and a
clk_enable_atomic. This way people can use standard clk_enable until
a 'scheduling while atomic' gives a hint in the right direction.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Locking in the clk API

[Sascha Hauer]

On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > This looks like a complete disaster, and is also completely inconsistent
> > with how the API is being used by the vast majority of users today.
> 
> I've been basing this on the mxc clock code, which acquires a mutex for all 
> clk_enable()s. This may not be representative of the majority of clock usage.

For i.MX we can generally turn this into a spinlock. There are some exceptions
though. Most clocks directly visible for drivers are simple clock gates
which can be made atomic. The root clocks are often enough plls which
can't be enabled atomically, but where we have to spin until the pll is
locked. So we we have exactly the case Russell described: Whether we can
enable a clocks atomically depends on the parent (pll) being enabled or
disabled. We can work around this by calling clk_enable to the pll
explicitely from the platform code.

> 
> From a quick search there are a few other cases of non-atomic clock usage:
> 
> tcc:		clk_enable() acquires a global clocks_mutex
> tegra:	has a clk_enable_cansleep()
> davinci: clk_set_parent() aquires a global clocks_mutex
> 
> Excluding the davinci code (we won't worry about set_parent for now...), if we 
> can port mxc and tcc to a sleepable clk_enable, perhaps we could just go with 
> purely atomic operations.
> 
> We'd still need some method of using sleeping clocks though. How about making 
> clk_enable() BUG if the clock is not atomic, and add clk_enable_cansleep() for 
> the cases where clk->ops.enable may sleep.

Quoting Russell:

> I hate the GPIO APIs for doing this _cansleep crap as the decision of
> whether to use the _cansleep or normal APIs normally can't be made at
> the time when the API is used, but sometime later.  Many people just use
> the non-_cansleep versions irrespective of the context they're in -
> which is unnecessarily restrictive - consider what happens if you then
> have that driver use a GPIO on an I2C peripheral...

Sounds like we should rather have s sleeping clk_enable and a
clk_enable_atomic. This way people can use standard clk_enable until
a 'scheduling while atomic' gives a hint in the right direction.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> At present, we can satisfy these with:
> 
> * clk_enable: may sleep

I object to this as one of the purposes behind the clk API is to allow
power savings to be made, and unless we can perform clk enable/disable
from atomic contexts, the best you can do is enable the clock when the
device is probed and disable it when it's released.

For a lot of systems, modules are loaded at boot, and devices are probed
at boot time.  They're never unloaded.

This means that clocks will be enabled at boot time and never turned off.

If you're lucky, there may be open/release methods which can be used to
enable/disable the clock, which reduces the 'clock on' period down to
the point where userspace opens/closes the device.  That's still
insufficient and in some cases there aren't calls for this.

Sometimes the only point that you know you need the clock enabled is when
your driver has already been called in an atomic context.

If such a requirement is imposed, it means that a driver would either have
to leave the clock always on, or would have to drop such calls if the
clock wasn't already enabled.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> At present, we can satisfy these with:
> 
> * clk_enable: may sleep

I object to this as one of the purposes behind the clk API is to allow
power savings to be made, and unless we can perform clk enable/disable
from atomic contexts, the best you can do is enable the clock when the
device is probed and disable it when it's released.

For a lot of systems, modules are loaded at boot, and devices are probed
at boot time.  They're never unloaded.

This means that clocks will be enabled at boot time and never turned off.

If you're lucky, there may be open/release methods which can be used to
enable/disable the clock, which reduces the 'clock on' period down to
the point where userspace opens/closes the device.  That's still
insufficient and in some cases there aren't calls for this.

Sometimes the only point that you know you need the clock enabled is when
your driver has already been called in an atomic context.

If such a requirement is imposed, it means that a driver would either have
to leave the clock always on, or would have to drop such calls if the
clock wasn't already enabled.

Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
> At present, we can satisfy these with:
> 
> * clk_enable: may sleep

I object to this as one of the purposes behind the clk API is to allow
power savings to be made, and unless we can perform clk enable/disable
from atomic contexts, the best you can do is enable the clock when the
device is probed and disable it when it's released.

For a lot of systems, modules are loaded at boot, and devices are probed
at boot time.  They're never unloaded.

This means that clocks will be enabled at boot time and never turned off.

If you're lucky, there may be open/release methods which can be used to
enable/disable the clock, which reduces the 'clock on' period down to
the point where userspace opens/closes the device.  That's still
insufficient and in some cases there aren't calls for this.

Sometimes the only point that you know you need the clock enabled is when
your driver has already been called in an atomic context.

If such a requirement is imposed, it means that a driver would either have
to leave the clock always on, or would have to drop such calls if the
clock wasn't already enabled.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:03:11AM +0100, Sascha Hauer wrote:
> Quoting Russell:
> 
> > I hate the GPIO APIs for doing this _cansleep crap as the decision of
> > whether to use the _cansleep or normal APIs normally can't be made at
> > the time when the API is used, but sometime later.  Many people just use
> > the non-_cansleep versions irrespective of the context they're in -
> > which is unnecessarily restrictive - consider what happens if you then
> > have that driver use a GPIO on an I2C peripheral...
> 
> Sounds like we should rather have s sleeping clk_enable and a
> clk_enable_atomic. This way people can use standard clk_enable until
> a 'scheduling while atomic' gives a hint in the right direction.

Well, there's a problem lurking here - lets take the PL011 driver.  You
convert the console write calls to use clk_enable_atomic(), leaving the
rest.

The driver will appear to work fine with a sleeping clk, until you get
a console write.  Maybe your SoC developer never tried the console on
the particular port you just tried to use?  Maybe such a driver should
use the _atomic() versions throughout?

Another solution occurs to me: clk_enable() which returns -EAGAIN if
it's called in an atomic context but needs to sleep, and let the driver
deal with the clock not being enabled when it wants it.  The down side
is it requires the driver to have additional code to sort out such a
problem.

Maybe another approach for the time being is to unify in two steps: first
unify the implementations which use a spinlock - and those which can use
a spinlock, and separately those which must use a mutex.

Then this issue can be revisited in the future.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:03:11AM +0100, Sascha Hauer wrote:
> Quoting Russell:
> 
> > I hate the GPIO APIs for doing this _cansleep crap as the decision of
> > whether to use the _cansleep or normal APIs normally can't be made at
> > the time when the API is used, but sometime later.  Many people just use
> > the non-_cansleep versions irrespective of the context they're in -
> > which is unnecessarily restrictive - consider what happens if you then
> > have that driver use a GPIO on an I2C peripheral...
> 
> Sounds like we should rather have s sleeping clk_enable and a
> clk_enable_atomic. This way people can use standard clk_enable until
> a 'scheduling while atomic' gives a hint in the right direction.

Well, there's a problem lurking here - lets take the PL011 driver.  You
convert the console write calls to use clk_enable_atomic(), leaving the
rest.

The driver will appear to work fine with a sleeping clk, until you get
a console write.  Maybe your SoC developer never tried the console on
the particular port you just tried to use?  Maybe such a driver should
use the _atomic() versions throughout?

Another solution occurs to me: clk_enable() which returns -EAGAIN if
it's called in an atomic context but needs to sleep, and let the driver
deal with the clock not being enabled when it wants it.  The down side
is it requires the driver to have additional code to sort out such a
problem.

Maybe another approach for the time being is to unify in two steps: first
unify the implementations which use a spinlock - and those which can use
a spinlock, and separately those which must use a mutex.

Then this issue can be revisited in the future.

Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 10:03:11AM +0100, Sascha Hauer wrote:
> Quoting Russell:
> 
> > I hate the GPIO APIs for doing this _cansleep crap as the decision of
> > whether to use the _cansleep or normal APIs normally can't be made at
> > the time when the API is used, but sometime later.  Many people just use
> > the non-_cansleep versions irrespective of the context they're in -
> > which is unnecessarily restrictive - consider what happens if you then
> > have that driver use a GPIO on an I2C peripheral...
> 
> Sounds like we should rather have s sleeping clk_enable and a
> clk_enable_atomic. This way people can use standard clk_enable until
> a 'scheduling while atomic' gives a hint in the right direction.

Well, there's a problem lurking here - lets take the PL011 driver.  You
convert the console write calls to use clk_enable_atomic(), leaving the
rest.

The driver will appear to work fine with a sleeping clk, until you get
a console write.  Maybe your SoC developer never tried the console on
the particular port you just tried to use?  Maybe such a driver should
use the _atomic() versions throughout?

Another solution occurs to me: clk_enable() which returns -EAGAIN if
it's called in an atomic context but needs to sleep, and let the driver
deal with the clock not being enabled when it wants it.  The down side
is it requires the driver to have additional code to sort out such a
problem.

Maybe another approach for the time being is to unify in two steps: first
unify the implementations which use a spinlock - and those which can use
a spinlock, and separately those which must use a mutex.

Then this issue can be revisited in the future.

Re: Locking in the clk API

[Jeremy Kerr]

Hi Russell,

> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
> 
> [...]
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.

.. provided that the enable (and subsequent things that depend on the clock 
signal to be valid) can't be deferred; I'm not sure how often this will be 
possible.

So, it sounds like the best approach is to provide an atomic clk_enable. I 
agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
most sense, so how about:

int clk_enable(struct clk *clk)
{
	might_sleep();

	[...]
}

int clk_enable_atomic(struct clk *clk)
{
	BUG_ON(!(clk->flags & CLK_ATOMIC));

	[...]
}

Paul: even though you mention that the atomic clocks are the usual case, I 
think that this way around illustrates the atomic 'restriction' at the call 
site more clearly. When the drivers don't care about the atomicity, 
clk_enable() is fine. When drivers do need an atomic clock, 
clk_enable_atomic() shows this requirement.

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi Russell,

> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
> 
> [...]
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.

.. provided that the enable (and subsequent things that depend on the clock 
signal to be valid) can't be deferred; I'm not sure how often this will be 
possible.

So, it sounds like the best approach is to provide an atomic clk_enable. I 
agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
most sense, so how about:

int clk_enable(struct clk *clk)
{
	might_sleep();

	[...]
}

int clk_enable_atomic(struct clk *clk)
{
	BUG_ON(!(clk->flags & CLK_ATOMIC));

	[...]
}

Paul: even though you mention that the atomic clocks are the usual case, I 
think that this way around illustrates the atomic 'restriction' at the call 
site more clearly. When the drivers don't care about the atomicity, 
clk_enable() is fine. When drivers do need an atomic clock, 
clk_enable_atomic() shows this requirement.

Cheers,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi Russell,

> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
> 
> [...]
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.

.. provided that the enable (and subsequent things that depend on the clock 
signal to be valid) can't be deferred; I'm not sure how often this will be 
possible.

So, it sounds like the best approach is to provide an atomic clk_enable. I 
agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
most sense, so how about:

int clk_enable(struct clk *clk)
{
	might_sleep();

	[...]
}

int clk_enable_atomic(struct clk *clk)
{
	BUG_ON(!(clk->flags & CLK_ATOMIC));

	[...]
}

Paul: even though you mention that the atomic clocks are the usual case, I 
think that this way around illustrates the atomic 'restriction' at the call 
site more clearly. When the drivers don't care about the atomicity, 
clk_enable() is fine. When drivers do need an atomic clock, 
clk_enable_atomic() shows this requirement.

Cheers,


Jeremy

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
> 
No, the sleeping clock case is and always will be a corner case, and I
have no interest in pretending otherwise. On SH we have hundreds of
clocks that are all usable in the atomic context and perhaps less than a
dozen that aren't (and even in those cases much of the PLL negotiation is
handled in hardware so there's never any visibility for the lock-down
from the software side, other architectures also have similar behaviour).

Keep in mind that all users except for the few that you cited were
already quite content with the atomic context use, so this 'restriction'
you speak of is just an artificial limitation introduced by a couple of
new platforms that deviated from what everyone else was already doing.

If you want to go this route, then SH and ARM-based SH-Mobiles will at
least not be making use of the generic struct clk.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
> 
No, the sleeping clock case is and always will be a corner case, and I
have no interest in pretending otherwise. On SH we have hundreds of
clocks that are all usable in the atomic context and perhaps less than a
dozen that aren't (and even in those cases much of the PLL negotiation is
handled in hardware so there's never any visibility for the lock-down
from the software side, other architectures also have similar behaviour).

Keep in mind that all users except for the few that you cited were
already quite content with the atomic context use, so this 'restriction'
you speak of is just an artificial limitation introduced by a couple of
new platforms that deviated from what everyone else was already doing.

If you want to go this route, then SH and ARM-based SH-Mobiles will at
least not be making use of the generic struct clk.

Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
> 
No, the sleeping clock case is and always will be a corner case, and I
have no interest in pretending otherwise. On SH we have hundreds of
clocks that are all usable in the atomic context and perhaps less than a
dozen that aren't (and even in those cases much of the PLL negotiation is
handled in hardware so there's never any visibility for the lock-down
from the software side, other architectures also have similar behaviour).

Keep in mind that all users except for the few that you cited were
already quite content with the atomic context use, so this 'restriction'
you speak of is just an artificial limitation introduced by a couple of
new platforms that deviated from what everyone else was already doing.

If you want to go this route, then SH and ARM-based SH-Mobiles will at
least not be making use of the generic struct clk.

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

I'm not too worried about the corner-cases on the *implementation* side, more 
the corner-cases on the API side: are we seeing more users of the API that 
require an atomic clock, or more that don't care?

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

I'm not too worried about the corner-cases on the *implementation* side, more 
the corner-cases on the API side: are we seeing more users of the API that 
require an atomic clock, or more that don't care?

Cheers,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

I'm not too worried about the corner-cases on the *implementation* side, more 
the corner-cases on the API side: are we seeing more users of the API that 
require an atomic clock, or more that don't care?

Cheers,


Jeremy

Re: Locking in the clk API

[@ 2011-01-11 10:39 UTC (permalink / raw)]

Hi,

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> > I object to this as one of the purposes behind the clk API is to allow
> > power savings to be made, and unless we can perform clk enable/disable
> > from atomic contexts, the best you can do is enable the clock when the
> > device is probed and disable it when it's released.
> > 
> > [...]
> >
> > Sometimes the only point that you know you need the clock enabled is when
> > your driver has already been called in an atomic context.
> 
> .. provided that the enable (and subsequent things that depend on the clock 
> signal to be valid) can't be deferred; I'm not sure how often this will be 
> possible.
> 
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
I agree that we should try to make the clk api easy and consistent.  So
if we can go the atomic way we should in my opinion.

On i.mx the roots in the clk hierarchy are plls, so it would be nice to
know how long it takes to enable these.

Back when I implemented clk support for ns921x I had a clock that made
me think that a sleeping implementation would be the way to go.  I don't
remember the exact details.  (It was the rtc clk.)

A quick look into Digi's BSP (digiEL-5.0) shows they implemented
something I suggested earlier here:

	static int clk_enable_haslocknchange(struct clk *clk)
	{
		int ret = 0;

		assert_spin_locked(&clk_lock);
		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));

		if (clk->usage++ = 0) {
			if (clk->parent) {
				ret = clk_enable_haslock(clk->parent);
				if (ret)
					goto err_enable_parent;
			}

			spin_unlock(&clk_lock);

			if (clk->endisable)
				ret = clk->endisable(clk, 1);

			spin_lock(&clk_lock);

			if (ret) {
				clk_disable_parent_haslock(clk);
	err_enable_parent:
				clk->usage = 0;
			}
		}

		return ret;
	}

	static int clk_enable_haslock(struct clk *clk)
	{
		int ret;
		assert_spin_locked(&clk_lock);
		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
			return -EBUSY;

		ret = clk_enable_haslocknchange(clk);

		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);

		return ret;
	}

	int clk_enable(struct clk *clk)
	{
		...
		spin_lock_irqsave(&clk_lock, flags);
		ret = clk_enable_haslock(clk);
		spin_unlock_irqrestore(&clk_lock, flags);
		return ret;
	}


I think the idea is nice.  At least it allows with a single lock to
implement both, sleeping and atomic clks without the need to mark the
atomicity in a global flag.

In the meantime Sascha checked on mx51 how long it takes to enable one
of the three PLLs: 50us.  Is this fast enough to accept disabled irqs
that long?

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

Hi,

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> > I object to this as one of the purposes behind the clk API is to allow
> > power savings to be made, and unless we can perform clk enable/disable
> > from atomic contexts, the best you can do is enable the clock when the
> > device is probed and disable it when it's released.
> > 
> > [...]
> >
> > Sometimes the only point that you know you need the clock enabled is when
> > your driver has already been called in an atomic context.
> 
> .. provided that the enable (and subsequent things that depend on the clock 
> signal to be valid) can't be deferred; I'm not sure how often this will be 
> possible.
> 
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
I agree that we should try to make the clk api easy and consistent.  So
if we can go the atomic way we should in my opinion.

On i.mx the roots in the clk hierarchy are plls, so it would be nice to
know how long it takes to enable these.

Back when I implemented clk support for ns921x I had a clock that made
me think that a sleeping implementation would be the way to go.  I don't
remember the exact details.  (It was the rtc clk.)

A quick look into Digi's BSP (digiEL-5.0) shows they implemented
something I suggested earlier here:

	static int clk_enable_haslocknchange(struct clk *clk)
	{
		int ret = 0;

		assert_spin_locked(&clk_lock);
		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));

		if (clk->usage++ == 0) {
			if (clk->parent) {
				ret = clk_enable_haslock(clk->parent);
				if (ret)
					goto err_enable_parent;
			}

			spin_unlock(&clk_lock);

			if (clk->endisable)
				ret = clk->endisable(clk, 1);

			spin_lock(&clk_lock);

			if (ret) {
				clk_disable_parent_haslock(clk);
	err_enable_parent:
				clk->usage = 0;
			}
		}

		return ret;
	}

	static int clk_enable_haslock(struct clk *clk)
	{
		int ret;
		assert_spin_locked(&clk_lock);
		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
			return -EBUSY;

		ret = clk_enable_haslocknchange(clk);

		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);

		return ret;
	}

	int clk_enable(struct clk *clk)
	{
		...
		spin_lock_irqsave(&clk_lock, flags);
		ret = clk_enable_haslock(clk);
		spin_unlock_irqrestore(&clk_lock, flags);
		return ret;
	}


I think the idea is nice.  At least it allows with a single lock to
implement both, sleeping and atomic clks without the need to mark the
atomicity in a global flag.

In the meantime Sascha checked on mx51 how long it takes to enable one
of the three PLLs: 50us.  Is this fast enough to accept disabled irqs
that long?

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

Hi,

On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
> > I object to this as one of the purposes behind the clk API is to allow
> > power savings to be made, and unless we can perform clk enable/disable
> > from atomic contexts, the best you can do is enable the clock when the
> > device is probed and disable it when it's released.
> > 
> > [...]
> >
> > Sometimes the only point that you know you need the clock enabled is when
> > your driver has already been called in an atomic context.
> 
> .. provided that the enable (and subsequent things that depend on the clock 
> signal to be valid) can't be deferred; I'm not sure how often this will be 
> possible.
> 
> So, it sounds like the best approach is to provide an atomic clk_enable. I 
> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
> most sense, so how about:
> 
> int clk_enable(struct clk *clk)
> {
> 	might_sleep();
> 
> 	[...]
> }
> 
> int clk_enable_atomic(struct clk *clk)
> {
> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
> 
> 	[...]
> }
> 
> Paul: even though you mention that the atomic clocks are the usual case, I 
> think that this way around illustrates the atomic 'restriction' at the call 
> site more clearly. When the drivers don't care about the atomicity, 
> clk_enable() is fine. When drivers do need an atomic clock, 
> clk_enable_atomic() shows this requirement.
I agree that we should try to make the clk api easy and consistent.  So
if we can go the atomic way we should in my opinion.

On i.mx the roots in the clk hierarchy are plls, so it would be nice to
know how long it takes to enable these.

Back when I implemented clk support for ns921x I had a clock that made
me think that a sleeping implementation would be the way to go.  I don't
remember the exact details.  (It was the rtc clk.)

A quick look into Digi's BSP (digiEL-5.0) shows they implemented
something I suggested earlier here:

	static int clk_enable_haslocknchange(struct clk *clk)
	{
		int ret = 0;

		assert_spin_locked(&clk_lock);
		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));

		if (clk->usage++ == 0) {
			if (clk->parent) {
				ret = clk_enable_haslock(clk->parent);
				if (ret)
					goto err_enable_parent;
			}

			spin_unlock(&clk_lock);

			if (clk->endisable)
				ret = clk->endisable(clk, 1);

			spin_lock(&clk_lock);

			if (ret) {
				clk_disable_parent_haslock(clk);
	err_enable_parent:
				clk->usage = 0;
			}
		}

		return ret;
	}

	static int clk_enable_haslock(struct clk *clk)
	{
		int ret;
		assert_spin_locked(&clk_lock);
		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
			return -EBUSY;

		ret = clk_enable_haslocknchange(clk);

		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);

		return ret;
	}

	int clk_enable(struct clk *clk)
	{
		...
		spin_lock_irqsave(&clk_lock, flags);
		ret = clk_enable_haslock(clk);
		spin_unlock_irqrestore(&clk_lock, flags);
		return ret;
	}


I think the idea is nice.  At least it allows with a single lock to
implement both, sleeping and atomic clks without the need to mark the
atomicity in a global flag.

In the meantime Sascha checked on mx51 how long it takes to enable one
of the three PLLs: 50us.  Is this fast enough to accept disabled irqs
that long?

Best regards
Uwe

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

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
> 
> 	static int clk_enable_haslocknchange(struct clk *clk)
> 	{
> 		int ret = 0;
> 
> 		assert_spin_locked(&clk_lock);
> 		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
> 
> 		if (clk->usage++ = 0) {
> 			if (clk->parent) {
> 				ret = clk_enable_haslock(clk->parent);
> 				if (ret)
> 					goto err_enable_parent;
> 			}
> 
> 			spin_unlock(&clk_lock);
> 
> 			if (clk->endisable)
> 				ret = clk->endisable(clk, 1);
> 
> 			spin_lock(&clk_lock);
> 
> 			if (ret) {
> 				clk_disable_parent_haslock(clk);
> 	err_enable_parent:
> 				clk->usage = 0;
> 			}
> 		}
> 
> 		return ret;
> 	}
> 
> 	static int clk_enable_haslock(struct clk *clk)
> 	{
> 		int ret;
> 		assert_spin_locked(&clk_lock);
> 		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> 			return -EBUSY;
> 
> 		ret = clk_enable_haslocknchange(clk);
> 
> 		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
> 
> 		return ret;
> 	}
> 
> 	int clk_enable(struct clk *clk)
> 	{
> 		...
> 		spin_lock_irqsave(&clk_lock, flags);
> 		ret = clk_enable_haslock(clk);
> 		spin_unlock_irqrestore(&clk_lock, flags);
> 		return ret;
> 	}
> 
> 
> I think the idea is nice.  At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.

It doesn't.  clk_enable() here can still end up trying to sleep when
it's called from IRQ context - the code doesn't solve that.  All it
means is that the intermediate code doesn't care whether clk->endisable
ends up sleeping or not.

What it does do is return -EBUSY if there are two concurrent attempts
to enable the same clock.  How many drivers today deal sanely with
such an error from clk_enable(), and how many would just fail their
probe() call on such an occurance?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
> 
> 	static int clk_enable_haslocknchange(struct clk *clk)
> 	{
> 		int ret = 0;
> 
> 		assert_spin_locked(&clk_lock);
> 		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
> 
> 		if (clk->usage++ == 0) {
> 			if (clk->parent) {
> 				ret = clk_enable_haslock(clk->parent);
> 				if (ret)
> 					goto err_enable_parent;
> 			}
> 
> 			spin_unlock(&clk_lock);
> 
> 			if (clk->endisable)
> 				ret = clk->endisable(clk, 1);
> 
> 			spin_lock(&clk_lock);
> 
> 			if (ret) {
> 				clk_disable_parent_haslock(clk);
> 	err_enable_parent:
> 				clk->usage = 0;
> 			}
> 		}
> 
> 		return ret;
> 	}
> 
> 	static int clk_enable_haslock(struct clk *clk)
> 	{
> 		int ret;
> 		assert_spin_locked(&clk_lock);
> 		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> 			return -EBUSY;
> 
> 		ret = clk_enable_haslocknchange(clk);
> 
> 		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
> 
> 		return ret;
> 	}
> 
> 	int clk_enable(struct clk *clk)
> 	{
> 		...
> 		spin_lock_irqsave(&clk_lock, flags);
> 		ret = clk_enable_haslock(clk);
> 		spin_unlock_irqrestore(&clk_lock, flags);
> 		return ret;
> 	}
> 
> 
> I think the idea is nice.  At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.

It doesn't.  clk_enable() here can still end up trying to sleep when
it's called from IRQ context - the code doesn't solve that.  All it
means is that the intermediate code doesn't care whether clk->endisable
ends up sleeping or not.

What it does do is return -EBUSY if there are two concurrent attempts
to enable the same clock.  How many drivers today deal sanely with
such an error from clk_enable(), and how many would just fail their
probe() call on such an occurance?

Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-K?nig wrote:
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
> 
> 	static int clk_enable_haslocknchange(struct clk *clk)
> 	{
> 		int ret = 0;
> 
> 		assert_spin_locked(&clk_lock);
> 		BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
> 
> 		if (clk->usage++ == 0) {
> 			if (clk->parent) {
> 				ret = clk_enable_haslock(clk->parent);
> 				if (ret)
> 					goto err_enable_parent;
> 			}
> 
> 			spin_unlock(&clk_lock);
> 
> 			if (clk->endisable)
> 				ret = clk->endisable(clk, 1);
> 
> 			spin_lock(&clk_lock);
> 
> 			if (ret) {
> 				clk_disable_parent_haslock(clk);
> 	err_enable_parent:
> 				clk->usage = 0;
> 			}
> 		}
> 
> 		return ret;
> 	}
> 
> 	static int clk_enable_haslock(struct clk *clk)
> 	{
> 		int ret;
> 		assert_spin_locked(&clk_lock);
> 		if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> 			return -EBUSY;
> 
> 		ret = clk_enable_haslocknchange(clk);
> 
> 		clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
> 
> 		return ret;
> 	}
> 
> 	int clk_enable(struct clk *clk)
> 	{
> 		...
> 		spin_lock_irqsave(&clk_lock, flags);
> 		ret = clk_enable_haslock(clk);
> 		spin_unlock_irqrestore(&clk_lock, flags);
> 		return ret;
> 	}
> 
> 
> I think the idea is nice.  At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.

It doesn't.  clk_enable() here can still end up trying to sleep when
it's called from IRQ context - the code doesn't solve that.  All it
means is that the intermediate code doesn't care whether clk->endisable
ends up sleeping or not.

What it does do is return -EBUSY if there are two concurrent attempts
to enable the same clock.  How many drivers today deal sanely with
such an error from clk_enable(), and how many would just fail their
probe() call on such an occurance?

Re: Locking in the clk API

[@ 2011-01-11 10:56 UTC (permalink / raw)]

Hello Russell,

On Tue, Jan 11, 2011 at 10:47:09AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> > A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> > something I suggested earlier here:
> >
> > [...]
> > 
> > 
> > I think the idea is nice.  At least it allows with a single lock to
> > implement both, sleeping and atomic clks without the need to mark the
> > atomicity in a global flag.
> 
> It doesn't.  clk_enable() here can still end up trying to sleep when
> it's called from IRQ context - the code doesn't solve that.  All it
> means is that the intermediate code doesn't care whether clk->endisable
> ends up sleeping or not.
Obviousley you're right and your last sentence is all I intended to
claim.

> What it does do is return -EBUSY if there are two concurrent attempts
> to enable the same clock.  How many drivers today deal sanely with
> such an error from clk_enable(), and how many would just fail their
> probe() call on such an occurance?
Yes, that's the ugly part.

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

Hello Russell,

On Tue, Jan 11, 2011 at 10:47:09AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-König wrote:
> > A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> > something I suggested earlier here:
> >
> > [...]
> > 
> > 
> > I think the idea is nice.  At least it allows with a single lock to
> > implement both, sleeping and atomic clks without the need to mark the
> > atomicity in a global flag.
> 
> It doesn't.  clk_enable() here can still end up trying to sleep when
> it's called from IRQ context - the code doesn't solve that.  All it
> means is that the intermediate code doesn't care whether clk->endisable
> ends up sleeping or not.
Obviousley you're right and your last sentence is all I intended to
claim.

> What it does do is return -EBUSY if there are two concurrent attempts
> to enable the same clock.  How many drivers today deal sanely with
> such an error from clk_enable(), and how many would just fail their
> probe() call on such an occurance?
Yes, that's the ugly part.

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

Hello Russell,

On Tue, Jan 11, 2011 at 10:47:09AM +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 11:39:29AM +0100, Uwe Kleine-K?nig wrote:
> > A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> > something I suggested earlier here:
> >
> > [...]
> > 
> > 
> > I think the idea is nice.  At least it allows with a single lock to
> > implement both, sleeping and atomic clks without the need to mark the
> > atomicity in a global flag.
> 
> It doesn't.  clk_enable() here can still end up trying to sleep when
> it's called from IRQ context - the code doesn't solve that.  All it
> means is that the intermediate code doesn't care whether clk->endisable
> ends up sleeping or not.
Obviousley you're right and your last sentence is all I intended to
claim.

> What it does do is return -EBUSY if there are two concurrent attempts
> to enable the same clock.  How many drivers today deal sanely with
> such an error from clk_enable(), and how many would just fail their
> probe() call on such an occurance?
Yes, that's the ugly part.

Best regards
Uwe

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

Re: Locking in the clk API

[Richard Zhao]

2011/1/11 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hi,
>
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> > I object to this as one of the purposes behind the clk API is to allow
>> > power savings to be made, and unless we can perform clk enable/disable
>> > from atomic contexts, the best you can do is enable the clock when the
>> > device is probed and disable it when it's released.
>> >
>> > [...]
>> >
>> > Sometimes the only point that you know you need the clock enabled is when
>> > your driver has already been called in an atomic context.
>>
>> .. provided that the enable (and subsequent things that depend on the clock
>> signal to be valid) can't be deferred; I'm not sure how often this will be
>> possible.
>>
>> So, it sounds like the best approach is to provide an atomic clk_enable. I
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>>       might_sleep();
>>
>>       [...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>>       BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>>       [...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I
>> think that this way around illustrates the atomic 'restriction' at the call
>> site more clearly. When the drivers don't care about the atomicity,
>> clk_enable() is fine. When drivers do need an atomic clock,
>> clk_enable_atomic() shows this requirement.
> I agree that we should try to make the clk api easy and consistent.  So
> if we can go the atomic way we should in my opinion.
>
> On i.mx the roots in the clk hierarchy are plls, so it would be nice to
> know how long it takes to enable these.
>
> Back when I implemented clk support for ns921x I had a clock that made
> me think that a sleeping implementation would be the way to go.  I don't
> remember the exact details.  (It was the rtc clk.)
>
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
>
>        static int clk_enable_haslocknchange(struct clk *clk)
>        {
>                int ret = 0;
>
>                assert_spin_locked(&clk_lock);
>                BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
>
>                if (clk->usage++ = 0) {
>                        if (clk->parent) {
>                                ret = clk_enable_haslock(clk->parent);
>                                if (ret)
>                                        goto err_enable_parent;
>                        }
>
>                        spin_unlock(&clk_lock);
>
>                        if (clk->endisable)
>                                ret = clk->endisable(clk, 1);
>
>                        spin_lock(&clk_lock);
>
>                        if (ret) {
>                                clk_disable_parent_haslock(clk);
>        err_enable_parent:
>                                clk->usage = 0;
>                        }
>                }
>
>                return ret;
>        }
>
>        static int clk_enable_haslock(struct clk *clk)
>        {
>                int ret;
>                assert_spin_locked(&clk_lock);
>                if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
>                        return -EBUSY;
>
>                ret = clk_enable_haslocknchange(clk);
>
>                clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
>
>                return ret;
>        }
>
>        int clk_enable(struct clk *clk)
>        {
>                ...
>                spin_lock_irqsave(&clk_lock, flags);
>                ret = clk_enable_haslock(clk);
>                spin_unlock_irqrestore(&clk_lock, flags);
>                return ret;
>        }
>
>
> I think the idea is nice.  At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.
>
> In the meantime Sascha checked on mx51 how long it takes to enable one
> of the three PLLs: 50us.  Is this fast enough to accept disabled irqs
> that long?
A well running board will not enable/disable PLLs frequently. It don't
make sense. PLLs are normally disabled on request to enter low power
mode, rather not because all their child clocks are disabled.   So we
don't have to consider the time here.

Thanks
Richard
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: Locking in the clk API

[Richard Zhao]

2011/1/11 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> Hi,
>
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> > I object to this as one of the purposes behind the clk API is to allow
>> > power savings to be made, and unless we can perform clk enable/disable
>> > from atomic contexts, the best you can do is enable the clock when the
>> > device is probed and disable it when it's released.
>> >
>> > [...]
>> >
>> > Sometimes the only point that you know you need the clock enabled is when
>> > your driver has already been called in an atomic context.
>>
>> .. provided that the enable (and subsequent things that depend on the clock
>> signal to be valid) can't be deferred; I'm not sure how often this will be
>> possible.
>>
>> So, it sounds like the best approach is to provide an atomic clk_enable. I
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>>       might_sleep();
>>
>>       [...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>>       BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>>       [...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I
>> think that this way around illustrates the atomic 'restriction' at the call
>> site more clearly. When the drivers don't care about the atomicity,
>> clk_enable() is fine. When drivers do need an atomic clock,
>> clk_enable_atomic() shows this requirement.
> I agree that we should try to make the clk api easy and consistent.  So
> if we can go the atomic way we should in my opinion.
>
> On i.mx the roots in the clk hierarchy are plls, so it would be nice to
> know how long it takes to enable these.
>
> Back when I implemented clk support for ns921x I had a clock that made
> me think that a sleeping implementation would be the way to go.  I don't
> remember the exact details.  (It was the rtc clk.)
>
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
>
>        static int clk_enable_haslocknchange(struct clk *clk)
>        {
>                int ret = 0;
>
>                assert_spin_locked(&clk_lock);
>                BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
>
>                if (clk->usage++ == 0) {
>                        if (clk->parent) {
>                                ret = clk_enable_haslock(clk->parent);
>                                if (ret)
>                                        goto err_enable_parent;
>                        }
>
>                        spin_unlock(&clk_lock);
>
>                        if (clk->endisable)
>                                ret = clk->endisable(clk, 1);
>
>                        spin_lock(&clk_lock);
>
>                        if (ret) {
>                                clk_disable_parent_haslock(clk);
>        err_enable_parent:
>                                clk->usage = 0;
>                        }
>                }
>
>                return ret;
>        }
>
>        static int clk_enable_haslock(struct clk *clk)
>        {
>                int ret;
>                assert_spin_locked(&clk_lock);
>                if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
>                        return -EBUSY;
>
>                ret = clk_enable_haslocknchange(clk);
>
>                clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
>
>                return ret;
>        }
>
>        int clk_enable(struct clk *clk)
>        {
>                ...
>                spin_lock_irqsave(&clk_lock, flags);
>                ret = clk_enable_haslock(clk);
>                spin_unlock_irqrestore(&clk_lock, flags);
>                return ret;
>        }
>
>
> I think the idea is nice.  At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.
>
> In the meantime Sascha checked on mx51 how long it takes to enable one
> of the three PLLs: 50us.  Is this fast enough to accept disabled irqs
> that long?
A well running board will not enable/disable PLLs frequently. It don't
make sense. PLLs are normally disabled on request to enter low power
mode, rather not because all their child clocks are disabled.   So we
don't have to consider the time here.

Thanks
Richard
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Locking in the clk API

[Richard Zhao]

2011/1/11 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hi,
>
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> > I object to this as one of the purposes behind the clk API is to allow
>> > power savings to be made, and unless we can perform clk enable/disable
>> > from atomic contexts, the best you can do is enable the clock when the
>> > device is probed and disable it when it's released.
>> >
>> > [...]
>> >
>> > Sometimes the only point that you know you need the clock enabled is when
>> > your driver has already been called in an atomic context.
>>
>> .. provided that the enable (and subsequent things that depend on the clock
>> signal to be valid) can't be deferred; I'm not sure how often this will be
>> possible.
>>
>> So, it sounds like the best approach is to provide an atomic clk_enable. I
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>> ? ? ? might_sleep();
>>
>> ? ? ? [...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>> ? ? ? BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>> ? ? ? [...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I
>> think that this way around illustrates the atomic 'restriction' at the call
>> site more clearly. When the drivers don't care about the atomicity,
>> clk_enable() is fine. When drivers do need an atomic clock,
>> clk_enable_atomic() shows this requirement.
> I agree that we should try to make the clk api easy and consistent. ?So
> if we can go the atomic way we should in my opinion.
>
> On i.mx the roots in the clk hierarchy are plls, so it would be nice to
> know how long it takes to enable these.
>
> Back when I implemented clk support for ns921x I had a clock that made
> me think that a sleeping implementation would be the way to go. ?I don't
> remember the exact details. ?(It was the rtc clk.)
>
> A quick look into Digi's BSP (digiEL-5.0) shows they implemented
> something I suggested earlier here:
>
> ? ? ? ?static int clk_enable_haslocknchange(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?int ret = 0;
>
> ? ? ? ? ? ? ? ?assert_spin_locked(&clk_lock);
> ? ? ? ? ? ? ? ?BUG_ON(!test_bit(CLK_FLAG_CHANGESTATE, &clk->flags));
>
> ? ? ? ? ? ? ? ?if (clk->usage++ == 0) {
> ? ? ? ? ? ? ? ? ? ? ? ?if (clk->parent) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ret = clk_enable_haslock(clk->parent);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?goto err_enable_parent;
> ? ? ? ? ? ? ? ? ? ? ? ?}
>
> ? ? ? ? ? ? ? ? ? ? ? ?spin_unlock(&clk_lock);
>
> ? ? ? ? ? ? ? ? ? ? ? ?if (clk->endisable)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ret = clk->endisable(clk, 1);
>
> ? ? ? ? ? ? ? ? ? ? ? ?spin_lock(&clk_lock);
>
> ? ? ? ? ? ? ? ? ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clk_disable_parent_haslock(clk);
> ? ? ? ?err_enable_parent:
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?clk->usage = 0;
> ? ? ? ? ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?}
>
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
> ? ? ? ?static int clk_enable_haslock(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?int ret;
> ? ? ? ? ? ? ? ?assert_spin_locked(&clk_lock);
> ? ? ? ? ? ? ? ?if (__test_and_set_bit(CLK_FLAG_CHANGESTATE, &clk->flags))
> ? ? ? ? ? ? ? ? ? ? ? ?return -EBUSY;
>
> ? ? ? ? ? ? ? ?ret = clk_enable_haslocknchange(clk);
>
> ? ? ? ? ? ? ? ?clear_bit(CLK_FLAG_CHANGESTATE, &clk->flags);
>
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
> ? ? ? ?int clk_enable(struct clk *clk)
> ? ? ? ?{
> ? ? ? ? ? ? ? ?...
> ? ? ? ? ? ? ? ?spin_lock_irqsave(&clk_lock, flags);
> ? ? ? ? ? ? ? ?ret = clk_enable_haslock(clk);
> ? ? ? ? ? ? ? ?spin_unlock_irqrestore(&clk_lock, flags);
> ? ? ? ? ? ? ? ?return ret;
> ? ? ? ?}
>
>
> I think the idea is nice. ?At least it allows with a single lock to
> implement both, sleeping and atomic clks without the need to mark the
> atomicity in a global flag.
>
> In the meantime Sascha checked on mx51 how long it takes to enable one
> of the three PLLs: 50us. ?Is this fast enough to accept disabled irqs
> that long?
A well running board will not enable/disable PLLs frequently. It don't
make sense. PLLs are normally disabled on request to enter low power
mode, rather not because all their child clocks are disabled.   So we
don't have to consider the time here.

Thanks
Richard
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. ? ? ? ? ? ? ? ? ? ? ? ? ? | Uwe Kleine-K?nig ? ? ? ? ? ?|
> Industrial Linux Solutions ? ? ? ? ? ? ? ? | http://www.pengutronix.de/ ?|
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

Re: Locking in the clk API

[Jassi Brar]

On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
>
> For a lot of systems, modules are loaded at boot, and devices are probed
> at boot time.  They're never unloaded.
>
> This means that clocks will be enabled at boot time and never turned off.
>
> If you're lucky, there may be open/release methods which can be used to
> enable/disable the clock, which reduces the 'clock on' period down to
> the point where userspace opens/closes the device.  That's still
> insufficient and in some cases there aren't calls for this.
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.
>
> If such a requirement is imposed, it means that a driver would either have
> to leave the clock always on, or would have to drop such calls if the
> clock wasn't already enabled.

Perhaps we should factor the conventional clk_enable into two parts (say) :-
 a)  clk_setup  : Which does exactly what can't be done in atomic context.
                         Like setting PLLs i.e, if that needs to sleep.
b)  clk_enable : Everything else that gets the clock signals running.

The drivers could do clk_setup in probe/open and clk_enable right before the
the actual need of the clock. That way, drivers don't have to bother
with platform/clock
peculiarities while trying their best to save power.
Of course, power that can't be saved now, won't be saved then.

Locking in the clk API

[Jassi Brar]

On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
>
> For a lot of systems, modules are loaded at boot, and devices are probed
> at boot time. ?They're never unloaded.
>
> This means that clocks will be enabled at boot time and never turned off.
>
> If you're lucky, there may be open/release methods which can be used to
> enable/disable the clock, which reduces the 'clock on' period down to
> the point where userspace opens/closes the device. ?That's still
> insufficient and in some cases there aren't calls for this.
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.
>
> If such a requirement is imposed, it means that a driver would either have
> to leave the clock always on, or would have to drop such calls if the
> clock wasn't already enabled.

Perhaps we should factor the conventional clk_enable into two parts (say) :-
 a)  clk_setup  : Which does exactly what can't be done in atomic context.
                         Like setting PLLs i.e, if that needs to sleep.
b)  clk_enable : Everything else that gets the clock signals running.

The drivers could do clk_setup in probe/open and clk_enable right before the
the actual need of the clock. That way, drivers don't have to bother
with platform/clock
peculiarities while trying their best to save power.
Of course, power that can't be saved now, won't be saved then.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > No, the sleeping clock case is and always will be a corner case, and I
> > have no interest in pretending otherwise. On SH we have hundreds of
> > clocks that are all usable in the atomic context and perhaps less than a
> > dozen that aren't (and even in those cases much of the PLL negotiation is
> > handled in hardware so there's never any visibility for the lock-down
> > from the software side, other architectures also have similar behaviour).
> 
> I'm not too worried about the corner-cases on the *implementation* side, more 
> the corner-cases on the API side: are we seeing more users of the API that 
> require an atomic clock, or more that don't care?
> 
Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.

It's unfortunate that you managed to pick one of the three or so
platforms with broken semantics to base your implementation off of, but
rest assured, everyone else did infact get it right, at least so far.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > No, the sleeping clock case is and always will be a corner case, and I
> > have no interest in pretending otherwise. On SH we have hundreds of
> > clocks that are all usable in the atomic context and perhaps less than a
> > dozen that aren't (and even in those cases much of the PLL negotiation is
> > handled in hardware so there's never any visibility for the lock-down
> > from the software side, other architectures also have similar behaviour).
> 
> I'm not too worried about the corner-cases on the *implementation* side, more 
> the corner-cases on the API side: are we seeing more users of the API that 
> require an atomic clock, or more that don't care?
> 
Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.

It's unfortunate that you managed to pick one of the three or so
platforms with broken semantics to base your implementation off of, but
rest assured, everyone else did infact get it right, at least so far.

Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> Hi Paul,
> 
> > No, the sleeping clock case is and always will be a corner case, and I
> > have no interest in pretending otherwise. On SH we have hundreds of
> > clocks that are all usable in the atomic context and perhaps less than a
> > dozen that aren't (and even in those cases much of the PLL negotiation is
> > handled in hardware so there's never any visibility for the lock-down
> > from the software side, other architectures also have similar behaviour).
> 
> I'm not too worried about the corner-cases on the *implementation* side, more 
> the corner-cases on the API side: are we seeing more users of the API that 
> require an atomic clock, or more that don't care?
> 
Again, you are approaching it from the angle that an atomic clock is a
special requirement rather than the default behaviour. Sleeping for
lookup, addition, and deletion are all quite acceptable, but
enable/disable pairs have always been intended to be usable from atomic
context. Anyone that doesn't count on that fact is either dealing with
special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
implementing any sort of fine grained runtime power management for their
platform.

It's unfortunate that you managed to pick one of the three or so
platforms with broken semantics to base your implementation off of, but
rest assured, everyone else did infact get it right, at least so far.

Re: Locking in the clk API

[Jassi Brar]

On Tue, Jan 11, 2011 at 2:46 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.
>
> For a lot of systems, modules are loaded at boot, and devices are probed
> at boot time.  They're never unloaded.
>
> This means that clocks will be enabled at boot time and never turned off.
>
> If you're lucky, there may be open/release methods which can be used to
> enable/disable the clock, which reduces the 'clock on' period down to
> the point where userspace opens/closes the device.  That's still
> insufficient and in some cases there aren't calls for this.
>
> Sometimes the only point that you know you need the clock enabled is when
> your driver has already been called in an atomic context.
>
> If such a requirement is imposed, it means that a driver would either have
> to leave the clock always on, or would have to drop such calls if the
> clock wasn't already enabled.

Perhaps we should factor the conventional clk_enable into two parts (say) :-
 a)  clk_setup  : Which does exactly what can't be done in atomic context.
                         Like setting PLLs i.e, if that needs to sleep.
b)  clk_enable : Everything else that gets the clock signals running.

The drivers could do clk_setup in probe/open and clk_enable right before the
the actual need of the clock. That way, drivers don't have to bother
with platform/clock
peculiarities while trying their best to save power.
Of course, power that can't be saved now, won't be saved then.

Re: Locking in the clk API

[@ 2011-01-11 13:52 UTC (permalink / raw)]

On Tue, Jan 11, 2011 at 09:18:16PM +0900, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> > Hi Paul,
> > 
> > > No, the sleeping clock case is and always will be a corner case, and I
> > > have no interest in pretending otherwise. On SH we have hundreds of
> > > clocks that are all usable in the atomic context and perhaps less than a
> > > dozen that aren't (and even in those cases much of the PLL negotiation is
> > > handled in hardware so there's never any visibility for the lock-down
> > > from the software side, other architectures also have similar behaviour).
> > 
> > I'm not too worried about the corner-cases on the *implementation* side, more 
> > the corner-cases on the API side: are we seeing more users of the API that 
> > require an atomic clock, or more that don't care?
> > 
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
particularly if atomic behaviour is the common behaviour it's important
to get it right, because the less common sleeping clocks don't get much
test covering.

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

On Tue, Jan 11, 2011 at 09:18:16PM +0900, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> > Hi Paul,
> > 
> > > No, the sleeping clock case is and always will be a corner case, and I
> > > have no interest in pretending otherwise. On SH we have hundreds of
> > > clocks that are all usable in the atomic context and perhaps less than a
> > > dozen that aren't (and even in those cases much of the PLL negotiation is
> > > handled in hardware so there's never any visibility for the lock-down
> > > from the software side, other architectures also have similar behaviour).
> > 
> > I'm not too worried about the corner-cases on the *implementation* side, more 
> > the corner-cases on the API side: are we seeing more users of the API that 
> > require an atomic clock, or more that don't care?
> > 
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
particularly if atomic behaviour is the common behaviour it's important
to get it right, because the less common sleeping clocks don't get much
test covering.

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

On Tue, Jan 11, 2011 at 09:18:16PM +0900, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
> > Hi Paul,
> > 
> > > No, the sleeping clock case is and always will be a corner case, and I
> > > have no interest in pretending otherwise. On SH we have hundreds of
> > > clocks that are all usable in the atomic context and perhaps less than a
> > > dozen that aren't (and even in those cases much of the PLL negotiation is
> > > handled in hardware so there's never any visibility for the lock-down
> > > from the software side, other architectures also have similar behaviour).
> > 
> > I'm not too worried about the corner-cases on the *implementation* side, more 
> > the corner-cases on the API side: are we seeing more users of the API that 
> > require an atomic clock, or more that don't care?
> > 
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
particularly if atomic behaviour is the common behaviour it's important
to get it right, because the less common sleeping clocks don't get much
test covering.

Best regards
Uwe

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

Re: Locking in the clk API

[Pavel Machek]

Hi!

> Another solution occurs to me: clk_enable() which returns -EAGAIN if
> it's called in an atomic context but needs to sleep, and let the driver
> deal with the clock not being enabled when it wants it.  The down side
> is it requires the driver to have additional code to sort out such a
> problem.

I do not think that "atomic context" is possible to reliably detect
inside a function like that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Locking in the clk API

[Pavel Machek]

Hi!

> Another solution occurs to me: clk_enable() which returns -EAGAIN if
> it's called in an atomic context but needs to sleep, and let the driver
> deal with the clock not being enabled when it wants it.  The down side
> is it requires the driver to have additional code to sort out such a
> problem.

I do not think that "atomic context" is possible to reliably detect
inside a function like that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Locking in the clk API

[Pavel Machek]

Hi!

> Another solution occurs to me: clk_enable() which returns -EAGAIN if
> it's called in an atomic context but needs to sleep, and let the driver
> deal with the clock not being enabled when it wants it.  The down side
> is it requires the driver to have additional code to sort out such a
> problem.

I do not think that "atomic context" is possible to reliably detect
inside a function like that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour.

I'm not considering it a special requirement, but it's still a requirement 
(that the called function does not sleep).

The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that 
now you've made the caller need to know what kind of clock it has, or might 
have one day.

 * For clk_enable/clk_enable_atomic, the decision is: is this call in an
   atomic context?

 * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
   have given us a sleeping clock?

Note that it's much easier to guarantee correctness for the first than it is 
for the second.

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour.

I'm not considering it a special requirement, but it's still a requirement 
(that the called function does not sleep).

The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that 
now you've made the caller need to know what kind of clock it has, or might 
have one day.

 * For clk_enable/clk_enable_atomic, the decision is: is this call in an
   atomic context?

 * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
   have given us a sleeping clock?

Note that it's much easier to guarantee correctness for the first than it is 
for the second.

Cheers,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi Paul,

> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour.

I'm not considering it a special requirement, but it's still a requirement 
(that the called function does not sleep).

The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that 
now you've made the caller need to know what kind of clock it has, or might 
have one day.

 * For clk_enable/clk_enable_atomic, the decision is: is this call in an
   atomic context?

 * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
   have given us a sleeping clock?

Note that it's much easier to guarantee correctness for the first than it is 
for the second.

Cheers,


Jeremy

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 04:18 AM, Paul Mundt wrote:
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

Paul,

I see you repeating this point a couple of times and I'm a bit confused 
how you handle the clock tree/dependencies.

Does your clock driver NOT hide the details of what root clock/PLL a 
branch clock is sourced from? If you do hide the details of the root/PLL 
source, how do you get the branch clk_enable() to be done atomically if 
the root/PLL enables are not possible in atomic context?

Is it simply a matter of your hardware having PLLs and root clocks that 
can be turned on/off quickly?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 04:18 AM, Paul Mundt wrote:
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

Paul,

I see you repeating this point a couple of times and I'm a bit confused 
how you handle the clock tree/dependencies.

Does your clock driver NOT hide the details of what root clock/PLL a 
branch clock is sourced from? If you do hide the details of the root/PLL 
source, how do you get the branch clk_enable() to be done atomically if 
the root/PLL enables are not possible in atomic context?

Is it simply a matter of your hardware having PLLs and root clocks that 
can be turned on/off quickly?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/11/2011 04:18 AM, Paul Mundt wrote:
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

Paul,

I see you repeating this point a couple of times and I'm a bit confused 
how you handle the clock tree/dependencies.

Does your clock driver NOT hide the details of what root clock/PLL a 
branch clock is sourced from? If you do hide the details of the root/PLL 
source, how do you get the branch clk_enable() to be done atomically if 
the root/PLL enables are not possible in atomic context?

Is it simply a matter of your hardware having PLLs and root clocks that 
can be turned on/off quickly?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
> On 01/11/2011 04:18 AM, Paul Mundt wrote:
> >Again, you are approaching it from the angle that an atomic clock is a
> >special requirement rather than the default behaviour. Sleeping for
> >lookup, addition, and deletion are all quite acceptable, but
> >enable/disable pairs have always been intended to be usable from atomic
> >context. Anyone that doesn't count on that fact is either dealing with
> >special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> >implementing any sort of fine grained runtime power management for their
> >platform.
> 
> Paul,
> 
> I see you repeating this point a couple of times and I'm a bit confused 
> how you handle the clock tree/dependencies.
> 
> Does your clock driver NOT hide the details of what root clock/PLL a 
> branch clock is sourced from? If you do hide the details of the root/PLL 
> source, how do you get the branch clk_enable() to be done atomically if 
> the root/PLL enables are not possible in atomic context?
> 
> Is it simply a matter of your hardware having PLLs and root clocks that 
> can be turned on/off quickly?
> 
There are a few cases where PLL clocks would benefit from a clk_enable()
that can sleep, but for us these are almost all in the device space. Most
of the SoCs however have fairly straightforward clock topologies where
the root clock in question is an external oscillator that can't be
disabled, and anything chained below that sits behind a PLL divider or
multiplier bank that can likewise be adjusted atomically. The vast
majority of the clocks below that can likewise be trivially
enabled/disabled from atomic context.

In response to your query, no, we do not hide those details. Each on-chip
clock generator is fed by a default oscillator via one input or a board
specific one via another, with a frequency that can vary wildly depending
on the implementation. In general we require the SoC code to register its
clock topology, the board code to work out which source its fed from (and
at what frequency), and then also providing an initial rate propagation
kick down the tree to make sure that all of the core clocks are set up
sensibly and to synchronize hardware/software state.

Having said that, we _do_ have clocks where rate changes are non-trivial
due to it being necessary to synchronize with internal timing circuitry,
but at the moment we don't really deal with those (this is something we'd
have to deal with for dynamically scaling the bus clock for example,
which requires a special watchdog overflow to relock an internal PLL,
which in general we leave fixed).

In general I would be happy to have a sleepable variant of clk_enable(),
it's just making clk_enable() sleepable by default or treating clocks
usable from atomic context as the special case that I take issue with,
particularly when the opposite is the demonstratable norm.

Re: Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
> On 01/11/2011 04:18 AM, Paul Mundt wrote:
> >Again, you are approaching it from the angle that an atomic clock is a
> >special requirement rather than the default behaviour. Sleeping for
> >lookup, addition, and deletion are all quite acceptable, but
> >enable/disable pairs have always been intended to be usable from atomic
> >context. Anyone that doesn't count on that fact is either dealing with
> >special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> >implementing any sort of fine grained runtime power management for their
> >platform.
> 
> Paul,
> 
> I see you repeating this point a couple of times and I'm a bit confused 
> how you handle the clock tree/dependencies.
> 
> Does your clock driver NOT hide the details of what root clock/PLL a 
> branch clock is sourced from? If you do hide the details of the root/PLL 
> source, how do you get the branch clk_enable() to be done atomically if 
> the root/PLL enables are not possible in atomic context?
> 
> Is it simply a matter of your hardware having PLLs and root clocks that 
> can be turned on/off quickly?
> 
There are a few cases where PLL clocks would benefit from a clk_enable()
that can sleep, but for us these are almost all in the device space. Most
of the SoCs however have fairly straightforward clock topologies where
the root clock in question is an external oscillator that can't be
disabled, and anything chained below that sits behind a PLL divider or
multiplier bank that can likewise be adjusted atomically. The vast
majority of the clocks below that can likewise be trivially
enabled/disabled from atomic context.

In response to your query, no, we do not hide those details. Each on-chip
clock generator is fed by a default oscillator via one input or a board
specific one via another, with a frequency that can vary wildly depending
on the implementation. In general we require the SoC code to register its
clock topology, the board code to work out which source its fed from (and
at what frequency), and then also providing an initial rate propagation
kick down the tree to make sure that all of the core clocks are set up
sensibly and to synchronize hardware/software state.

Having said that, we _do_ have clocks where rate changes are non-trivial
due to it being necessary to synchronize with internal timing circuitry,
but at the moment we don't really deal with those (this is something we'd
have to deal with for dynamically scaling the bus clock for example,
which requires a special watchdog overflow to relock an internal PLL,
which in general we leave fixed).

In general I would be happy to have a sleepable variant of clk_enable(),
it's just making clk_enable() sleepable by default or treating clocks
usable from atomic context as the special case that I take issue with,
particularly when the opposite is the demonstratable norm.

Locking in the clk API

[Paul Mundt]

On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
> On 01/11/2011 04:18 AM, Paul Mundt wrote:
> >Again, you are approaching it from the angle that an atomic clock is a
> >special requirement rather than the default behaviour. Sleeping for
> >lookup, addition, and deletion are all quite acceptable, but
> >enable/disable pairs have always been intended to be usable from atomic
> >context. Anyone that doesn't count on that fact is either dealing with
> >special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> >implementing any sort of fine grained runtime power management for their
> >platform.
> 
> Paul,
> 
> I see you repeating this point a couple of times and I'm a bit confused 
> how you handle the clock tree/dependencies.
> 
> Does your clock driver NOT hide the details of what root clock/PLL a 
> branch clock is sourced from? If you do hide the details of the root/PLL 
> source, how do you get the branch clk_enable() to be done atomically if 
> the root/PLL enables are not possible in atomic context?
> 
> Is it simply a matter of your hardware having PLLs and root clocks that 
> can be turned on/off quickly?
> 
There are a few cases where PLL clocks would benefit from a clk_enable()
that can sleep, but for us these are almost all in the device space. Most
of the SoCs however have fairly straightforward clock topologies where
the root clock in question is an external oscillator that can't be
disabled, and anything chained below that sits behind a PLL divider or
multiplier bank that can likewise be adjusted atomically. The vast
majority of the clocks below that can likewise be trivially
enabled/disabled from atomic context.

In response to your query, no, we do not hide those details. Each on-chip
clock generator is fed by a default oscillator via one input or a board
specific one via another, with a frequency that can vary wildly depending
on the implementation. In general we require the SoC code to register its
clock topology, the board code to work out which source its fed from (and
at what frequency), and then also providing an initial rate propagation
kick down the tree to make sure that all of the core clocks are set up
sensibly and to synchronize hardware/software state.

Having said that, we _do_ have clocks where rate changes are non-trivial
due to it being necessary to synchronize with internal timing circuitry,
but at the moment we don't really deal with those (this is something we'd
have to deal with for dynamically scaling the bus clock for example,
which requires a special watchdog overflow to relock an internal PLL,
which in general we leave fixed).

In general I would be happy to have a sleepable variant of clk_enable(),
it's just making clk_enable() sleepable by default or treating clocks
usable from atomic context as the special case that I take issue with,
particularly when the opposite is the demonstratable norm.

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.

Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is 
the atomic context that you are having in mind that's related to power 
savings? How often do we really need to call clk enable/disable in that 
atomic context?

If the system VDD needed to be increased when a clock/core in enabled 
(in reality, when a core is enabled), how do we make sure that the 
voltage is reduced when the clock/core is turned off? Do we simply punt 
the voltage change problem to the driver and say "not our problem"?

I'm not saying that the voltage change should or shouldn't be handled by 
the clock driver. But it looks like the same methods used to handle the 
voltage change problem could be applied to how we could handle the clk 
enable/disable problem.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.

Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is 
the atomic context that you are having in mind that's related to power 
savings? How often do we really need to call clk enable/disable in that 
atomic context?

If the system VDD needed to be increased when a clock/core in enabled 
(in reality, when a core is enabled), how do we make sure that the 
voltage is reduced when the clock/core is turned off? Do we simply punt 
the voltage change problem to the driver and say "not our problem"?

I'm not saying that the voltage change should or shouldn't be handled by 
the clock driver. But it looks like the same methods used to handle the 
voltage change problem could be applied to how we could handle the clk 
enable/disable problem.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> At present, we can satisfy these with:
>>
>> * clk_enable: may sleep
>
> I object to this as one of the purposes behind the clk API is to allow
> power savings to be made, and unless we can perform clk enable/disable
> from atomic contexts, the best you can do is enable the clock when the
> device is probed and disable it when it's released.

Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is 
the atomic context that you are having in mind that's related to power 
savings? How often do we really need to call clk enable/disable in that 
atomic context?

If the system VDD needed to be increased when a clock/core in enabled 
(in reality, when a core is enabled), how do we make sure that the 
voltage is reduced when the clock/core is turned off? Do we simply punt 
the voltage change problem to the driver and say "not our problem"?

I'm not saying that the voltage change should or shouldn't be handled by 
the clock driver. But it looks like the same methods used to handle the 
voltage change problem could be applied to how we could handle the clk 
enable/disable problem.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> Hi Paul,
>
>> Again, you are approaching it from the angle that an atomic clock is a
>> special requirement rather than the default behaviour.
>
> I'm not considering it a special requirement, but it's still a requirement
> (that the called function does not sleep).
>
> The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> now you've made the caller need to know what kind of clock it has, or might
> have one day.

I think it's just a matter of how you interpret the name of the API in 
English. It doesn't make the decision making of the developer any easier.

Just having a _atomic suffix doesn't mean the driver developer doesn't 
need to know what type of clock it is. They are still making the 
assumption that the enable/disable for that clock can be done atomically 
-- namely an "atomic clock".

Similarly, when a driver developer calls the _sleepable APIs in their 
code, for all practical purposes, they are making an assumption that the 
enable/disable for that clock *needs to* (not may) sleep.

>   * For clk_enable/clk_enable_atomic, the decision is: is this call in an
>     atomic context?
>
>   * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
>     have given us a sleeping clock?

Having said the above, I'm slightly leaning towards 
clk_enable/disable_atomic since it lines up with the 
.suspend/.suspend_noirq functions in pm_ops.

Also, since it's good to reduce the amount of work that needs to be done 
atomically, I think it would be good to make a developer explicitly 
state they need _atomic functions and make them think about if they 
really need to do that.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> Hi Paul,
>
>> Again, you are approaching it from the angle that an atomic clock is a
>> special requirement rather than the default behaviour.
>
> I'm not considering it a special requirement, but it's still a requirement
> (that the called function does not sleep).
>
> The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> now you've made the caller need to know what kind of clock it has, or might
> have one day.

I think it's just a matter of how you interpret the name of the API in 
English. It doesn't make the decision making of the developer any easier.

Just having a _atomic suffix doesn't mean the driver developer doesn't 
need to know what type of clock it is. They are still making the 
assumption that the enable/disable for that clock can be done atomically 
-- namely an "atomic clock".

Similarly, when a driver developer calls the _sleepable APIs in their 
code, for all practical purposes, they are making an assumption that the 
enable/disable for that clock *needs to* (not may) sleep.

>   * For clk_enable/clk_enable_atomic, the decision is: is this call in an
>     atomic context?
>
>   * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
>     have given us a sleeping clock?

Having said the above, I'm slightly leaning towards 
clk_enable/disable_atomic since it lines up with the 
.suspend/.suspend_noirq functions in pm_ops.

Also, since it's good to reduce the amount of work that needs to be done 
atomically, I think it would be good to make a developer explicitly 
state they need _atomic functions and make them think about if they 
really need to do that.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> Hi Paul,
>
>> Again, you are approaching it from the angle that an atomic clock is a
>> special requirement rather than the default behaviour.
>
> I'm not considering it a special requirement, but it's still a requirement
> (that the called function does not sleep).
>
> The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> now you've made the caller need to know what kind of clock it has, or might
> have one day.

I think it's just a matter of how you interpret the name of the API in 
English. It doesn't make the decision making of the developer any easier.

Just having a _atomic suffix doesn't mean the driver developer doesn't 
need to know what type of clock it is. They are still making the 
assumption that the enable/disable for that clock can be done atomically 
-- namely an "atomic clock".

Similarly, when a driver developer calls the _sleepable APIs in their 
code, for all practical purposes, they are making an assumption that the 
enable/disable for that clock *needs to* (not may) sleep.

>   * For clk_enable/clk_enable_atomic, the decision is: is this call in an
>     atomic context?
>
>   * For clk_enable/clk_enable_sleepable, the decision is: might the clock code
>     have given us a sleeping clock?

Having said the above, I'm slightly leaning towards 
clk_enable/disable_atomic since it lines up with the 
.suspend/.suspend_noirq functions in pm_ops.

Also, since it's good to reduce the amount of work that needs to be done 
atomically, I think it would be good to make a developer explicitly 
state they need _atomic functions and make them think about if they 
really need to do that.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[@ 2011-01-12 7:40 UTC (permalink / raw)]

Hi Saravana,

On Tue, Jan 11, 2011 at 07:25:01PM -0800, Saravana Kannan wrote:
> On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> >Hi Paul,
> >
> >>Again, you are approaching it from the angle that an atomic clock is a
> >>special requirement rather than the default behaviour.
> >
> >I'm not considering it a special requirement, but it's still a requirement
> >(that the called function does not sleep).
> >
> >The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> >now you've made the caller need to know what kind of clock it has, or might
> >have one day.
> 
> I think it's just a matter of how you interpret the name of the API
> in English. It doesn't make the decision making of the developer any
> easier.
> 
> Just having a _atomic suffix doesn't mean the driver developer
> doesn't need to know what type of clock it is. They are still making
> the assumption that the enable/disable for that clock can be done
> atomically -- namely an "atomic clock".
But there is a difference to 'one function to rule both sleepable and
atomic clocks'.  When calling _atomic on a sleepable clock you get
-ESOMETHING back (and the clock stays off).  With a generic clk_enable
you get an oops and so cannot handle the error.

> Similarly, when a driver developer calls the _sleepable APIs in
> their code, for all practical purposes, they are making an
> assumption that the enable/disable for that clock *needs to* (not
> may) sleep.
IMHO this is not right.  If the driver developer doesn't care if the
clock sleeps or not (which is the norm I think) he calls the _sleepable
function and if the clock happen to be an atomic one it doesn't hurt
him.

And looking at the usage of the sleeping functions in the gpio API, I'd
bet that at least 50% of the calls to gpio_set_value can/should be
gpio_set_value_cansleep.  That's because driver developers don't care or
are not aware of the issue.  If it would be gpio_set_value
vs.gpio_set_value_atomic most developers would use the sleeping variant
and the few that should use the _atomic function would notice that when
seeing the corresponding oops.

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

Hi Saravana,

On Tue, Jan 11, 2011 at 07:25:01PM -0800, Saravana Kannan wrote:
> On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> >Hi Paul,
> >
> >>Again, you are approaching it from the angle that an atomic clock is a
> >>special requirement rather than the default behaviour.
> >
> >I'm not considering it a special requirement, but it's still a requirement
> >(that the called function does not sleep).
> >
> >The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> >now you've made the caller need to know what kind of clock it has, or might
> >have one day.
> 
> I think it's just a matter of how you interpret the name of the API
> in English. It doesn't make the decision making of the developer any
> easier.
> 
> Just having a _atomic suffix doesn't mean the driver developer
> doesn't need to know what type of clock it is. They are still making
> the assumption that the enable/disable for that clock can be done
> atomically -- namely an "atomic clock".
But there is a difference to 'one function to rule both sleepable and
atomic clocks'.  When calling _atomic on a sleepable clock you get
-ESOMETHING back (and the clock stays off).  With a generic clk_enable
you get an oops and so cannot handle the error.

> Similarly, when a driver developer calls the _sleepable APIs in
> their code, for all practical purposes, they are making an
> assumption that the enable/disable for that clock *needs to* (not
> may) sleep.
IMHO this is not right.  If the driver developer doesn't care if the
clock sleeps or not (which is the norm I think) he calls the _sleepable
function and if the clock happen to be an atomic one it doesn't hurt
him.

And looking at the usage of the sleeping functions in the gpio API, I'd
bet that at least 50% of the calls to gpio_set_value can/should be
gpio_set_value_cansleep.  That's because driver developers don't care or
are not aware of the issue.  If it would be gpio_set_value
vs.gpio_set_value_atomic most developers would use the sleeping variant
and the few that should use the _atomic function would notice that when
seeing the corresponding oops.

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

Hi Saravana,

On Tue, Jan 11, 2011 at 07:25:01PM -0800, Saravana Kannan wrote:
> On 01/11/2011 06:35 AM, Jeremy Kerr wrote:
> >Hi Paul,
> >
> >>Again, you are approaching it from the angle that an atomic clock is a
> >>special requirement rather than the default behaviour.
> >
> >I'm not considering it a special requirement, but it's still a requirement
> >(that the called function does not sleep).
> >
> >The problem with the inverse logic (clk_enable/clk_enable_sleepable) is that
> >now you've made the caller need to know what kind of clock it has, or might
> >have one day.
> 
> I think it's just a matter of how you interpret the name of the API
> in English. It doesn't make the decision making of the developer any
> easier.
> 
> Just having a _atomic suffix doesn't mean the driver developer
> doesn't need to know what type of clock it is. They are still making
> the assumption that the enable/disable for that clock can be done
> atomically -- namely an "atomic clock".
But there is a difference to 'one function to rule both sleepable and
atomic clocks'.  When calling _atomic on a sleepable clock you get
-ESOMETHING back (and the clock stays off).  With a generic clk_enable
you get an oops and so cannot handle the error.

> Similarly, when a driver developer calls the _sleepable APIs in
> their code, for all practical purposes, they are making an
> assumption that the enable/disable for that clock *needs to* (not
> may) sleep.
IMHO this is not right.  If the driver developer doesn't care if the
clock sleeps or not (which is the norm I think) he calls the _sleepable
function and if the clock happen to be an atomic one it doesn't hurt
him.

And looking at the usage of the sleeping functions in the gpio API, I'd
bet that at least 50% of the calls to gpio_set_value can/should be
gpio_set_value_cansleep.  That's because driver developers don't care or
are not aware of the issue.  If it would be gpio_set_value
vs.gpio_set_value_atomic most developers would use the sleeping variant
and the few that should use the _atomic function would notice that when
seeing the corresponding oops.

Best regards
Uwe

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

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 06:56:10PM -0800, Saravana Kannan wrote:
> On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
>> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>>> At present, we can satisfy these with:
>>>
>>> * clk_enable: may sleep
>>
>> I object to this as one of the purposes behind the clk API is to allow
>> power savings to be made, and unless we can perform clk enable/disable
>> from atomic contexts, the best you can do is enable the clock when the
>> device is probed and disable it when it's released.
>
> Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is  

That never has been, and that is called for the _system_ going into
suspend.  That's not what I'm talking about.  I'm talking about drivers
doing their own power management in response to (a) their knowledge of
how the device behaves and (b) in response to the user state they know.

In the case of a UART, that means enabling the clock when the user opens
the device and turning it off when the user closes the device - and in
the case of the UART being used as the system console, enabled when
printk calls it, disabled when finished outputting the message.

The latter is a case where you're called in atomic context.

Another case - a storage device.  While you may receive open/close calls,
these are meaningless for power management - you'll receive an open call
when you mount a filesystem, and a close call when you finally unmount it.
That doesn't mean it's going to be used.  Your request handler will
generally run in an atomic context, so in order to do dynamic power
saving you need to be able to enable/disable clocks in that context.

A touchscreen controller which you communicate with over a dedicated bus.
The touchscreen controller doesn't require the host to be constantly
clocked - it only needs to be clocked when communicating with the
touchscreen.  The touchscreen controller raises an interrupt for service.
You'd want to enable the clock in the interrupt handler to communicate
with the device and turn it off afterwards.

Shall I continue?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 06:56:10PM -0800, Saravana Kannan wrote:
> On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
>> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>>> At present, we can satisfy these with:
>>>
>>> * clk_enable: may sleep
>>
>> I object to this as one of the purposes behind the clk API is to allow
>> power savings to be made, and unless we can perform clk enable/disable
>> from atomic contexts, the best you can do is enable the clock when the
>> device is probed and disable it when it's released.
>
> Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is  

That never has been, and that is called for the _system_ going into
suspend.  That's not what I'm talking about.  I'm talking about drivers
doing their own power management in response to (a) their knowledge of
how the device behaves and (b) in response to the user state they know.

In the case of a UART, that means enabling the clock when the user opens
the device and turning it off when the user closes the device - and in
the case of the UART being used as the system console, enabled when
printk calls it, disabled when finished outputting the message.

The latter is a case where you're called in atomic context.

Another case - a storage device.  While you may receive open/close calls,
these are meaningless for power management - you'll receive an open call
when you mount a filesystem, and a close call when you finally unmount it.
That doesn't mean it's going to be used.  Your request handler will
generally run in an atomic context, so in order to do dynamic power
saving you need to be able to enable/disable clocks in that context.

A touchscreen controller which you communicate with over a dedicated bus.
The touchscreen controller doesn't require the host to be constantly
clocked - it only needs to be clocked when communicating with the
touchscreen.  The touchscreen controller raises an interrupt for service.
You'd want to enable the clock in the interrupt handler to communicate
with the device and turn it off afterwards.

Shall I continue?

Locking in the clk API

[Russell King - ARM Linux]

On Tue, Jan 11, 2011 at 06:56:10PM -0800, Saravana Kannan wrote:
> On 01/11/2011 01:16 AM, Russell King - ARM Linux wrote:
>> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>>> At present, we can satisfy these with:
>>>
>>> * clk_enable: may sleep
>>
>> I object to this as one of the purposes behind the clk API is to allow
>> power savings to be made, and unless we can perform clk enable/disable
>> from atomic contexts, the best you can do is enable the clock when the
>> device is probed and disable it when it's released.
>
> Since dev_pm_ops.suspend is not atomic anymore (am I wrong?), what is  

That never has been, and that is called for the _system_ going into
suspend.  That's not what I'm talking about.  I'm talking about drivers
doing their own power management in response to (a) their knowledge of
how the device behaves and (b) in response to the user state they know.

In the case of a UART, that means enabling the clock when the user opens
the device and turning it off when the user closes the device - and in
the case of the UART being used as the system console, enabled when
printk calls it, disabled when finished outputting the message.

The latter is a case where you're called in atomic context.

Another case - a storage device.  While you may receive open/close calls,
these are meaningless for power management - you'll receive an open call
when you mount a filesystem, and a close call when you finally unmount it.
That doesn't mean it's going to be used.  Your request handler will
generally run in an atomic context, so in order to do dynamic power
saving you need to be able to enable/disable clocks in that context.

A touchscreen controller which you communicate with over a dedicated bus.
The touchscreen controller doesn't require the host to be constantly
clocked - it only needs to be clocked when communicating with the
touchscreen.  The touchscreen controller raises an interrupt for service.
You'd want to enable the clock in the interrupt handler to communicate
with the device and turn it off afterwards.

Shall I continue?

Re: Locking in the clk API

[Christer Weinigel]

On 01/12/2011 10:03 AM, Russell King - ARM Linux wrote:

> That never has been, and that is called for the _system_ going into
> suspend.  That's not what I'm talking about.  I'm talking about drivers
> doing their own power management in response to (a) their knowledge of
> how the device behaves and (b) in response to the user state they know.
>
> In the case of a UART, that means enabling the clock when the user opens
> the device and turning it off when the user closes the device - and in
> the case of the UART being used as the system console, enabled when
> printk calls it, disabled when finished outputting the message.

 >

> The latter is a case where you're called in atomic context.


This feels a bit like perfect being the enemy of good.

On platforms that need to sleep to enable the UART clock, configuring 
the UART as the kernel console should be equivalent to userspace opening 
the UART device, i.e. enable the clock.  At least to me that feels like 
an acceptable tradeoff, and if I wanted to save the last bit of power 
I'll have to refrain from using UART as the kernel console.

If both printk to the console and disabling the clock is really really 
neccesary, add a clk_enable_busywait, but that will be a bit of a hack.


> Another case - a storage device.  While you may receive open/close calls,
> these are meaningless for power management - you'll receive an open call
> when you mount a filesystem, and a close call when you finally unmount it.
> That doesn't mean it's going to be used.  Your request handler will
> generally run in an atomic context, so in order to do dynamic power
> saving you need to be able to enable/disable clocks in that context.



> A touchscreen controller which you communicate with over a dedicated bus.
> The touchscreen controller doesn't require the host to be constantly
> clocked - it only needs to be clocked when communicating with the
> touchscreen.  The touchscreen controller raises an interrupt for service.
> You'd want to enable the clock in the interrupt handler to communicate
> with the device and turn it off afterwards.


Both of these feel like they should use a call such as clk_get_atomic 
and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used 
to indicate that it would have to sleep) and delegate to a worker thread 
to enable the clock.  To catch uses of plain clk_enable from atomic 
contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything, 
but would help a bit at least.

Someone suggested splitting clk_enable into a part that can sleep and a 
part that can't, would that be workable?  I.e. extend clk_get so that it 
knows what requirements the driver has on the clock.  So a driver that does:

     clk_get(dev, "my_clk", CLK_CANSLEEP);

must then either use clk_enable from contexts which can sleep or use 
clk_enable_atomic and be able to handle EWOULDBLOCK.

A driver which can't handle EWOULDBLOCK would do:

     clk_get(dev, "my_clk", CLK_ATOMIC)

informing the clock subsystem that clk_enable_atomic must always 
succeed.  If the clock source driver can't do that it has to enable the 
clock at clk_get time instead of at clk_enable time.  If a clock 
requires a potentially slow PLL setup which needs to sleep but can gate 
the clock atomically, do the PLL setup from clk_get and the gating from 
clk_enable.  This means that a clock might be on when it strictly isn't 
necessary, but at least it will be correct and assuming that Peter Mundt 
is correct in saying that the sleeping clock case is a corner case this 
will usually not be a problem.

For the corner cases where someone ports a driver that uses CLK_ATOMIC 
to a system with sleeping clocks and wants the last bit of power saving, 
the burden is on that someone to add EWOULDBLOCK support to the driver.

Regarding the other functions in the clock API, generic code in 
clk_disable_atomic could check if it is a sleeping clock and based on 
that call clk_disable directly or delegate the call to a worker thread. 
  All other functions should be able to sleep, with the possible 
exception of clk_get_rate which could be useful so that a driver can 
check if the clock is running at the correct rate from atomic context 
and delegate to a worker thread to change the clock rate if it is not.

To avoid unnecessary code churn it might be better to say that plain 
clk_enable is the atomic variant and if it is a sleeping clock it will 
be enbled at the time plain clk_get is called.  People who want to use 
sleeping clocks can then modify a driver at a time to use 
clk_get_cansleep and clk_enable_cansleep.  But I must say that the name 
clk_enable_atomic feels a lot cleaner.

   /Christer

Re: Locking in the clk API

[Christer Weinigel]

On 01/12/2011 10:03 AM, Russell King - ARM Linux wrote:

> That never has been, and that is called for the _system_ going into
> suspend.  That's not what I'm talking about.  I'm talking about drivers
> doing their own power management in response to (a) their knowledge of
> how the device behaves and (b) in response to the user state they know.
>
> In the case of a UART, that means enabling the clock when the user opens
> the device and turning it off when the user closes the device - and in
> the case of the UART being used as the system console, enabled when
> printk calls it, disabled when finished outputting the message.

 >

> The latter is a case where you're called in atomic context.


This feels a bit like perfect being the enemy of good.

On platforms that need to sleep to enable the UART clock, configuring 
the UART as the kernel console should be equivalent to userspace opening 
the UART device, i.e. enable the clock.  At least to me that feels like 
an acceptable tradeoff, and if I wanted to save the last bit of power 
I'll have to refrain from using UART as the kernel console.

If both printk to the console and disabling the clock is really really 
neccesary, add a clk_enable_busywait, but that will be a bit of a hack.


> Another case - a storage device.  While you may receive open/close calls,
> these are meaningless for power management - you'll receive an open call
> when you mount a filesystem, and a close call when you finally unmount it.
> That doesn't mean it's going to be used.  Your request handler will
> generally run in an atomic context, so in order to do dynamic power
> saving you need to be able to enable/disable clocks in that context.



> A touchscreen controller which you communicate with over a dedicated bus.
> The touchscreen controller doesn't require the host to be constantly
> clocked - it only needs to be clocked when communicating with the
> touchscreen.  The touchscreen controller raises an interrupt for service.
> You'd want to enable the clock in the interrupt handler to communicate
> with the device and turn it off afterwards.


Both of these feel like they should use a call such as clk_get_atomic 
and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used 
to indicate that it would have to sleep) and delegate to a worker thread 
to enable the clock.  To catch uses of plain clk_enable from atomic 
contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything, 
but would help a bit at least.

Someone suggested splitting clk_enable into a part that can sleep and a 
part that can't, would that be workable?  I.e. extend clk_get so that it 
knows what requirements the driver has on the clock.  So a driver that does:

     clk_get(dev, "my_clk", CLK_CANSLEEP);

must then either use clk_enable from contexts which can sleep or use 
clk_enable_atomic and be able to handle EWOULDBLOCK.

A driver which can't handle EWOULDBLOCK would do:

     clk_get(dev, "my_clk", CLK_ATOMIC)

informing the clock subsystem that clk_enable_atomic must always 
succeed.  If the clock source driver can't do that it has to enable the 
clock at clk_get time instead of at clk_enable time.  If a clock 
requires a potentially slow PLL setup which needs to sleep but can gate 
the clock atomically, do the PLL setup from clk_get and the gating from 
clk_enable.  This means that a clock might be on when it strictly isn't 
necessary, but at least it will be correct and assuming that Peter Mundt 
is correct in saying that the sleeping clock case is a corner case this 
will usually not be a problem.

For the corner cases where someone ports a driver that uses CLK_ATOMIC 
to a system with sleeping clocks and wants the last bit of power saving, 
the burden is on that someone to add EWOULDBLOCK support to the driver.

Regarding the other functions in the clock API, generic code in 
clk_disable_atomic could check if it is a sleeping clock and based on 
that call clk_disable directly or delegate the call to a worker thread. 
  All other functions should be able to sleep, with the possible 
exception of clk_get_rate which could be useful so that a driver can 
check if the clock is running at the correct rate from atomic context 
and delegate to a worker thread to change the clock rate if it is not.

To avoid unnecessary code churn it might be better to say that plain 
clk_enable is the atomic variant and if it is a sleeping clock it will 
be enbled at the time plain clk_get is called.  People who want to use 
sleeping clocks can then modify a driver at a time to use 
clk_get_cansleep and clk_enable_cansleep.  But I must say that the name 
clk_enable_atomic feels a lot cleaner.

   /Christer

Locking in the clk API

[Christer Weinigel]

On 01/12/2011 10:03 AM, Russell King - ARM Linux wrote:

> That never has been, and that is called for the _system_ going into
> suspend.  That's not what I'm talking about.  I'm talking about drivers
> doing their own power management in response to (a) their knowledge of
> how the device behaves and (b) in response to the user state they know.
>
> In the case of a UART, that means enabling the clock when the user opens
> the device and turning it off when the user closes the device - and in
> the case of the UART being used as the system console, enabled when
> printk calls it, disabled when finished outputting the message.

 >

> The latter is a case where you're called in atomic context.


This feels a bit like perfect being the enemy of good.

On platforms that need to sleep to enable the UART clock, configuring 
the UART as the kernel console should be equivalent to userspace opening 
the UART device, i.e. enable the clock.  At least to me that feels like 
an acceptable tradeoff, and if I wanted to save the last bit of power 
I'll have to refrain from using UART as the kernel console.

If both printk to the console and disabling the clock is really really 
neccesary, add a clk_enable_busywait, but that will be a bit of a hack.


> Another case - a storage device.  While you may receive open/close calls,
> these are meaningless for power management - you'll receive an open call
> when you mount a filesystem, and a close call when you finally unmount it.
> That doesn't mean it's going to be used.  Your request handler will
> generally run in an atomic context, so in order to do dynamic power
> saving you need to be able to enable/disable clocks in that context.



> A touchscreen controller which you communicate with over a dedicated bus.
> The touchscreen controller doesn't require the host to be constantly
> clocked - it only needs to be clocked when communicating with the
> touchscreen.  The touchscreen controller raises an interrupt for service.
> You'd want to enable the clock in the interrupt handler to communicate
> with the device and turn it off afterwards.


Both of these feel like they should use a call such as clk_get_atomic 
and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used 
to indicate that it would have to sleep) and delegate to a worker thread 
to enable the clock.  To catch uses of plain clk_enable from atomic 
contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything, 
but would help a bit at least.

Someone suggested splitting clk_enable into a part that can sleep and a 
part that can't, would that be workable?  I.e. extend clk_get so that it 
knows what requirements the driver has on the clock.  So a driver that does:

     clk_get(dev, "my_clk", CLK_CANSLEEP);

must then either use clk_enable from contexts which can sleep or use 
clk_enable_atomic and be able to handle EWOULDBLOCK.

A driver which can't handle EWOULDBLOCK would do:

     clk_get(dev, "my_clk", CLK_ATOMIC)

informing the clock subsystem that clk_enable_atomic must always 
succeed.  If the clock source driver can't do that it has to enable the 
clock at clk_get time instead of at clk_enable time.  If a clock 
requires a potentially slow PLL setup which needs to sleep but can gate 
the clock atomically, do the PLL setup from clk_get and the gating from 
clk_enable.  This means that a clock might be on when it strictly isn't 
necessary, but at least it will be correct and assuming that Peter Mundt 
is correct in saying that the sleeping clock case is a corner case this 
will usually not be a problem.

For the corner cases where someone ports a driver that uses CLK_ATOMIC 
to a system with sleeping clocks and wants the last bit of power saving, 
the burden is on that someone to add EWOULDBLOCK support to the driver.

Regarding the other functions in the clock API, generic code in 
clk_disable_atomic could check if it is a sleeping clock and based on 
that call clk_disable directly or delegate the call to a worker thread. 
  All other functions should be able to sleep, with the possible 
exception of clk_get_rate which could be useful so that a driver can 
check if the clock is running at the correct rate from atomic context 
and delegate to a worker thread to change the clock rate if it is not.

To avoid unnecessary code churn it might be better to say that plain 
clk_enable is the atomic variant and if it is a sleeping clock it will 
be enbled at the time plain clk_get is called.  People who want to use 
sleeping clocks can then modify a driver at a time to use 
clk_get_cansleep and clk_enable_cansleep.  But I must say that the name 
clk_enable_atomic feels a lot cleaner.

   /Christer

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
> This feels a bit like perfect being the enemy of good.
>
> On platforms that need to sleep to enable the UART clock, configuring  
> the UART as the kernel console should be equivalent to userspace opening  
> the UART device, i.e. enable the clock.  At least to me that feels like  
> an acceptable tradeoff, and if I wanted to save the last bit of power  
> I'll have to refrain from using UART as the kernel console.
>
> If both printk to the console and disabling the clock is really really  
> neccesary, add a clk_enable_busywait, but that will be a bit of a hack.

Well, we're not discussing a _new_ API here - we're discussing an API
with existing users which works completely fine on the devices its
used, with differing expectations between implementations.

> Both of these feel like they should use a call such as clk_get_atomic  
> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used  
> to indicate that it would have to sleep) and delegate to a worker thread  
> to enable the clock.  To catch uses of plain clk_enable from atomic  
> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,  
> but would help a bit at least.

We've never allowed clk_get() to be called in interruptible context,
so that's not the issue.  The issue is purely about clk_enable() and
clk_disable() and whether they should be able to be called in atomic
context or not.

We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.

There's been a lot of talk on this issue for ages with no real progress
that I'm just going to repeat: let's unify those implementations which
use a spinlock for their clks into one consolidated solution, and
a separate consolidated solution for those which use a mutex.

This will at least allow us to have _some_ consolidation of the existing
implementations - and it doesn't add anything to the problem at hand.
It might actually help identify what can be done at code level to resolve
this issue.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
> This feels a bit like perfect being the enemy of good.
>
> On platforms that need to sleep to enable the UART clock, configuring  
> the UART as the kernel console should be equivalent to userspace opening  
> the UART device, i.e. enable the clock.  At least to me that feels like  
> an acceptable tradeoff, and if I wanted to save the last bit of power  
> I'll have to refrain from using UART as the kernel console.
>
> If both printk to the console and disabling the clock is really really  
> neccesary, add a clk_enable_busywait, but that will be a bit of a hack.

Well, we're not discussing a _new_ API here - we're discussing an API
with existing users which works completely fine on the devices its
used, with differing expectations between implementations.

> Both of these feel like they should use a call such as clk_get_atomic  
> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used  
> to indicate that it would have to sleep) and delegate to a worker thread  
> to enable the clock.  To catch uses of plain clk_enable from atomic  
> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,  
> but would help a bit at least.

We've never allowed clk_get() to be called in interruptible context,
so that's not the issue.  The issue is purely about clk_enable() and
clk_disable() and whether they should be able to be called in atomic
context or not.

We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.

There's been a lot of talk on this issue for ages with no real progress
that I'm just going to repeat: let's unify those implementations which
use a spinlock for their clks into one consolidated solution, and
a separate consolidated solution for those which use a mutex.

This will at least allow us to have _some_ consolidation of the existing
implementations - and it doesn't add anything to the problem at hand.
It might actually help identify what can be done at code level to resolve
this issue.

Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
> This feels a bit like perfect being the enemy of good.
>
> On platforms that need to sleep to enable the UART clock, configuring  
> the UART as the kernel console should be equivalent to userspace opening  
> the UART device, i.e. enable the clock.  At least to me that feels like  
> an acceptable tradeoff, and if I wanted to save the last bit of power  
> I'll have to refrain from using UART as the kernel console.
>
> If both printk to the console and disabling the clock is really really  
> neccesary, add a clk_enable_busywait, but that will be a bit of a hack.

Well, we're not discussing a _new_ API here - we're discussing an API
with existing users which works completely fine on the devices its
used, with differing expectations between implementations.

> Both of these feel like they should use a call such as clk_get_atomic  
> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used  
> to indicate that it would have to sleep) and delegate to a worker thread  
> to enable the clock.  To catch uses of plain clk_enable from atomic  
> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,  
> but would help a bit at least.

We've never allowed clk_get() to be called in interruptible context,
so that's not the issue.  The issue is purely about clk_enable() and
clk_disable() and whether they should be able to be called in atomic
context or not.

We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.

There's been a lot of talk on this issue for ages with no real progress
that I'm just going to repeat: let's unify those implementations which
use a spinlock for their clks into one consolidated solution, and
a separate consolidated solution for those which use a mutex.

This will at least allow us to have _some_ consolidation of the existing
implementations - and it doesn't add anything to the problem at hand.
It might actually help identify what can be done at code level to resolve
this issue.

Re: Locking in the clk API

[@ 2011-01-15 15:03 UTC (permalink / raw)]

Hi Russell,

On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> 
> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
> 
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.
Great, so how should we do it?  Take Jeremy's patch and make the
differenciation between sleeping and atomic implementation a Kconfig
variable?

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

Hi Russell,

On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> 
> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
> 
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.
Great, so how should we do it?  Take Jeremy's patch and make the
differenciation between sleeping and atomic implementation a Kconfig
variable?

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

Hi Russell,

On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> 
> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
> 
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.
Great, so how should we do it?  Take Jeremy's patch and make the
differenciation between sleeping and atomic implementation a Kconfig
variable?

Best regards
Uwe

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

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
> Hi Russell,
> 
> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > 
> > There's been a lot of talk on this issue for ages with no real progress
> > that I'm just going to repeat: let's unify those implementations which
> > use a spinlock for their clks into one consolidated solution, and
> > a separate consolidated solution for those which use a mutex.
> > 
> > This will at least allow us to have _some_ consolidation of the existing
> > implementations - and it doesn't add anything to the problem at hand.
> > It might actually help identify what can be done at code level to resolve
> > this issue.
> Great, so how should we do it?  Take Jeremy's patch and make the
> differenciation between sleeping and atomic implementation a Kconfig
> variable?

No - I've been suggesting for about a week now about doing two entirely
separate consolidations.

I think it would be insane to do the consolidation of the two different
implementations in one patch or even one patch set.  There needs to be
a consolidation of spinlock-based clks as one patch set, which is
entirely separate and independent from the consolidation of mutex-based
clks.

What if one of the consolidations turns out to be a problem?  Do we want
to throw both out, or do we want to keep as much as we possibly can?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
> Hi Russell,
> 
> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > 
> > There's been a lot of talk on this issue for ages with no real progress
> > that I'm just going to repeat: let's unify those implementations which
> > use a spinlock for their clks into one consolidated solution, and
> > a separate consolidated solution for those which use a mutex.
> > 
> > This will at least allow us to have _some_ consolidation of the existing
> > implementations - and it doesn't add anything to the problem at hand.
> > It might actually help identify what can be done at code level to resolve
> > this issue.
> Great, so how should we do it?  Take Jeremy's patch and make the
> differenciation between sleeping and atomic implementation a Kconfig
> variable?

No - I've been suggesting for about a week now about doing two entirely
separate consolidations.

I think it would be insane to do the consolidation of the two different
implementations in one patch or even one patch set.  There needs to be
a consolidation of spinlock-based clks as one patch set, which is
entirely separate and independent from the consolidation of mutex-based
clks.

What if one of the consolidations turns out to be a problem?  Do we want
to throw both out, or do we want to keep as much as we possibly can?

Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
> Hi Russell,
> 
> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > 
> > There's been a lot of talk on this issue for ages with no real progress
> > that I'm just going to repeat: let's unify those implementations which
> > use a spinlock for their clks into one consolidated solution, and
> > a separate consolidated solution for those which use a mutex.
> > 
> > This will at least allow us to have _some_ consolidation of the existing
> > implementations - and it doesn't add anything to the problem at hand.
> > It might actually help identify what can be done at code level to resolve
> > this issue.
> Great, so how should we do it?  Take Jeremy's patch and make the
> differenciation between sleeping and atomic implementation a Kconfig
> variable?

No - I've been suggesting for about a week now about doing two entirely
separate consolidations.

I think it would be insane to do the consolidation of the two different
implementations in one patch or even one patch set.  There needs to be
a consolidation of spinlock-based clks as one patch set, which is
entirely separate and independent from the consolidation of mutex-based
clks.

What if one of the consolidations turns out to be a problem?  Do we want
to throw both out, or do we want to keep as much as we possibly can?

Re: Locking in the clk API

[@ 2011-01-15 16:03 UTC (permalink / raw)]

On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
> > Hi Russell,
> > 
> > On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > > 
> > > There's been a lot of talk on this issue for ages with no real progress
> > > that I'm just going to repeat: let's unify those implementations which
> > > use a spinlock for their clks into one consolidated solution, and
> > > a separate consolidated solution for those which use a mutex.
> > > 
> > > This will at least allow us to have _some_ consolidation of the existing
> > > implementations - and it doesn't add anything to the problem at hand.
> > > It might actually help identify what can be done at code level to resolve
> > > this issue.
> > Great, so how should we do it?  Take Jeremy's patch and make the
> > differenciation between sleeping and atomic implementation a Kconfig
> > variable?
> 
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
I didn't read that out of your mails.
 
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set.  There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.
I think they should share most of the code.  Apart from calling
different locking functions they should be pretty much identical, no?

> What if one of the consolidations turns out to be a problem?  Do we want
> to throw both out, or do we want to keep as much as we possibly can?
Do you really expect fundamental problems that make it necessary to
switch all platforms that use the (say) sleeping variant back to their
original implementation?  I don't think that when the general idea of
using clk_ops prooves for the atomic case it cannot happen that a
"native" implementation for a sleeping clk is better that a sleeping
clk_ops implementation.

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
> > Hi Russell,
> > 
> > On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > > 
> > > There's been a lot of talk on this issue for ages with no real progress
> > > that I'm just going to repeat: let's unify those implementations which
> > > use a spinlock for their clks into one consolidated solution, and
> > > a separate consolidated solution for those which use a mutex.
> > > 
> > > This will at least allow us to have _some_ consolidation of the existing
> > > implementations - and it doesn't add anything to the problem at hand.
> > > It might actually help identify what can be done at code level to resolve
> > > this issue.
> > Great, so how should we do it?  Take Jeremy's patch and make the
> > differenciation between sleeping and atomic implementation a Kconfig
> > variable?
> 
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
I didn't read that out of your mails.
 
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set.  There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.
I think they should share most of the code.  Apart from calling
different locking functions they should be pretty much identical, no?

> What if one of the consolidations turns out to be a problem?  Do we want
> to throw both out, or do we want to keep as much as we possibly can?
Do you really expect fundamental problems that make it necessary to
switch all platforms that use the (say) sleeping variant back to their
original implementation?  I don't think that when the general idea of
using clk_ops prooves for the atomic case it cannot happen that a
"native" implementation for a sleeping clk is better that a sleeping
clk_ops implementation.

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
> > Hi Russell,
> > 
> > On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
> > > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
> > > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
> > > 
> > > There's been a lot of talk on this issue for ages with no real progress
> > > that I'm just going to repeat: let's unify those implementations which
> > > use a spinlock for their clks into one consolidated solution, and
> > > a separate consolidated solution for those which use a mutex.
> > > 
> > > This will at least allow us to have _some_ consolidation of the existing
> > > implementations - and it doesn't add anything to the problem at hand.
> > > It might actually help identify what can be done at code level to resolve
> > > this issue.
> > Great, so how should we do it?  Take Jeremy's patch and make the
> > differenciation between sleeping and atomic implementation a Kconfig
> > variable?
> 
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
I didn't read that out of your mails.
 
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set.  There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.
I think they should share most of the code.  Apart from calling
different locking functions they should be pretty much identical, no?

> What if one of the consolidations turns out to be a problem?  Do we want
> to throw both out, or do we want to keep as much as we possibly can?
Do you really expect fundamental problems that make it necessary to
switch all platforms that use the (say) sleeping variant back to their
original implementation?  I don't think that when the general idea of
using clk_ops prooves for the atomic case it cannot happen that a
"native" implementation for a sleeping clk is better that a sleeping
clk_ops implementation.

Best regards
Uwe

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

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-König wrote:
> On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > No - I've been suggesting for about a week now about doing two entirely
> > separate consolidations.
> I didn't read that out of your mails.

It was actually four days ago:
| Maybe another approach for the time being is to unify in two steps: first
| unify the implementations which use a spinlock - and those which can use
| a spinlock, and separately those which must use a mutex.
| 
| Then this issue can be revisited in the future.

> > I think it would be insane to do the consolidation of the two different
> > implementations in one patch or even one patch set.  There needs to be
> > a consolidation of spinlock-based clks as one patch set, which is
> > entirely separate and independent from the consolidation of mutex-based
> > clks.
> I think they should share most of the code.  Apart from calling
> different locking functions they should be pretty much identical, no?

That way you get unions of mutexes and spinlocks (which is one thing
we're trying to avoid) and conditionals controlling whether a mutex
or spinlock is taken - which we've already ascertained was strongly
objected to by folk in mainline (and quite rightfully so IMHO.)

> > What if one of the consolidations turns out to be a problem?  Do we want
> > to throw both out, or do we want to keep as much as we possibly can?
> Do you really expect fundamental problems that make it necessary to
> switch all platforms that use the (say) sleeping variant back to their
> original implementation?  I don't think that when the general idea of
> using clk_ops prooves for the atomic case it cannot happen that a
> "native" implementation for a sleeping clk is better that a sleeping
> clk_ops implementation.

I'm saying keep all the options open until we've got the whole thing
sorted out.  If you think it's possible to do without creating a mess
in the process - and without unions of mutexes and spinlocks or
conditionals controlling whether we use mutex_lock vs spin_lock then
please show the patches.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-König wrote:
> On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > No - I've been suggesting for about a week now about doing two entirely
> > separate consolidations.
> I didn't read that out of your mails.

It was actually four days ago:
| Maybe another approach for the time being is to unify in two steps: first
| unify the implementations which use a spinlock - and those which can use
| a spinlock, and separately those which must use a mutex.
| 
| Then this issue can be revisited in the future.

> > I think it would be insane to do the consolidation of the two different
> > implementations in one patch or even one patch set.  There needs to be
> > a consolidation of spinlock-based clks as one patch set, which is
> > entirely separate and independent from the consolidation of mutex-based
> > clks.
> I think they should share most of the code.  Apart from calling
> different locking functions they should be pretty much identical, no?

That way you get unions of mutexes and spinlocks (which is one thing
we're trying to avoid) and conditionals controlling whether a mutex
or spinlock is taken - which we've already ascertained was strongly
objected to by folk in mainline (and quite rightfully so IMHO.)

> > What if one of the consolidations turns out to be a problem?  Do we want
> > to throw both out, or do we want to keep as much as we possibly can?
> Do you really expect fundamental problems that make it necessary to
> switch all platforms that use the (say) sleeping variant back to their
> original implementation?  I don't think that when the general idea of
> using clk_ops prooves for the atomic case it cannot happen that a
> "native" implementation for a sleeping clk is better that a sleeping
> clk_ops implementation.

I'm saying keep all the options open until we've got the whole thing
sorted out.  If you think it's possible to do without creating a mess
in the process - and without unions of mutexes and spinlocks or
conditionals controlling whether we use mutex_lock vs spin_lock then
please show the patches.

Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-K?nig wrote:
> On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > No - I've been suggesting for about a week now about doing two entirely
> > separate consolidations.
> I didn't read that out of your mails.

It was actually four days ago:
| Maybe another approach for the time being is to unify in two steps: first
| unify the implementations which use a spinlock - and those which can use
| a spinlock, and separately those which must use a mutex.
| 
| Then this issue can be revisited in the future.

> > I think it would be insane to do the consolidation of the two different
> > implementations in one patch or even one patch set.  There needs to be
> > a consolidation of spinlock-based clks as one patch set, which is
> > entirely separate and independent from the consolidation of mutex-based
> > clks.
> I think they should share most of the code.  Apart from calling
> different locking functions they should be pretty much identical, no?

That way you get unions of mutexes and spinlocks (which is one thing
we're trying to avoid) and conditionals controlling whether a mutex
or spinlock is taken - which we've already ascertained was strongly
objected to by folk in mainline (and quite rightfully so IMHO.)

> > What if one of the consolidations turns out to be a problem?  Do we want
> > to throw both out, or do we want to keep as much as we possibly can?
> Do you really expect fundamental problems that make it necessary to
> switch all platforms that use the (say) sleeping variant back to their
> original implementation?  I don't think that when the general idea of
> using clk_ops prooves for the atomic case it cannot happen that a
> "native" implementation for a sleeping clk is better that a sleeping
> clk_ops implementation.

I'm saying keep all the options open until we've got the whole thing
sorted out.  If you think it's possible to do without creating a mess
in the process - and without unions of mutexes and spinlocks or
conditionals controlling whether we use mutex_lock vs spin_lock then
please show the patches.

Re: Locking in the clk API

[@ 2011-01-15 16:31 UTC (permalink / raw)]

On Sat, Jan 15, 2011 at 04:21:21PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-König wrote:
> > On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > > No - I've been suggesting for about a week now about doing two entirely
> > > separate consolidations.
> > I didn't read that out of your mails.
> 
> It was actually four days ago:
> | Maybe another approach for the time being is to unify in two steps: first
> | unify the implementations which use a spinlock - and those which can use
> | a spinlock, and separately those which must use a mutex.
> | 
> | Then this issue can be revisited in the future.
> 
> > > I think it would be insane to do the consolidation of the two different
> > > implementations in one patch or even one patch set.  There needs to be
> > > a consolidation of spinlock-based clks as one patch set, which is
> > > entirely separate and independent from the consolidation of mutex-based
> > > clks.
> > I think they should share most of the code.  Apart from calling
> > different locking functions they should be pretty much identical, no?
> 
> That way you get unions of mutexes and spinlocks (which is one thing
> we're trying to avoid) and conditionals controlling whether a mutex
> or spinlock is taken - which we've already ascertained was strongly
> objected to by folk in mainline (and quite rightfully so IMHO.)
If the decision is done basing on a Kconfig symbol it's an #ifdef.
That's not great but IMHO much better than a runtime decision.
 
> > > What if one of the consolidations turns out to be a problem?  Do we want
> > > to throw both out, or do we want to keep as much as we possibly can?
> > Do you really expect fundamental problems that make it necessary to
> > switch all platforms that use the (say) sleeping variant back to their
> > original implementation?  I don't think that when the general idea of
> > using clk_ops prooves for the atomic case it cannot happen that a
> > "native" implementation for a sleeping clk is better that a sleeping
> > clk_ops implementation.
> 
> I'm saying keep all the options open until we've got the whole thing
> sorted out.  If you think it's possible to do without creating a mess
> in the process - and without unions of mutexes and spinlocks or
> conditionals controlling whether we use mutex_lock vs spin_lock then
> please show the patches.

Jeremy: I think it would be quite easy to convert your series to use an
#ifdef instead of the flag.  I don't want to do this (at least not
without asking first) because it's your series, not mine.  How should we
proceed?

Best regards
Uwe

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

Re: Locking in the clk API

[Uwe Kleine-König]

On Sat, Jan 15, 2011 at 04:21:21PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-König wrote:
> > On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > > No - I've been suggesting for about a week now about doing two entirely
> > > separate consolidations.
> > I didn't read that out of your mails.
> 
> It was actually four days ago:
> | Maybe another approach for the time being is to unify in two steps: first
> | unify the implementations which use a spinlock - and those which can use
> | a spinlock, and separately those which must use a mutex.
> | 
> | Then this issue can be revisited in the future.
> 
> > > I think it would be insane to do the consolidation of the two different
> > > implementations in one patch or even one patch set.  There needs to be
> > > a consolidation of spinlock-based clks as one patch set, which is
> > > entirely separate and independent from the consolidation of mutex-based
> > > clks.
> > I think they should share most of the code.  Apart from calling
> > different locking functions they should be pretty much identical, no?
> 
> That way you get unions of mutexes and spinlocks (which is one thing
> we're trying to avoid) and conditionals controlling whether a mutex
> or spinlock is taken - which we've already ascertained was strongly
> objected to by folk in mainline (and quite rightfully so IMHO.)
If the decision is done basing on a Kconfig symbol it's an #ifdef.
That's not great but IMHO much better than a runtime decision.
 
> > > What if one of the consolidations turns out to be a problem?  Do we want
> > > to throw both out, or do we want to keep as much as we possibly can?
> > Do you really expect fundamental problems that make it necessary to
> > switch all platforms that use the (say) sleeping variant back to their
> > original implementation?  I don't think that when the general idea of
> > using clk_ops prooves for the atomic case it cannot happen that a
> > "native" implementation for a sleeping clk is better that a sleeping
> > clk_ops implementation.
> 
> I'm saying keep all the options open until we've got the whole thing
> sorted out.  If you think it's possible to do without creating a mess
> in the process - and without unions of mutexes and spinlocks or
> conditionals controlling whether we use mutex_lock vs spin_lock then
> please show the patches.

Jeremy: I think it would be quite easy to convert your series to use an
#ifdef instead of the flag.  I don't want to do this (at least not
without asking first) because it's your series, not mine.  How should we
proceed?

Best regards
Uwe

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

Locking in the clk API

[Uwe Kleine-König]

On Sat, Jan 15, 2011 at 04:21:21PM +0000, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 05:03:29PM +0100, Uwe Kleine-K?nig wrote:
> > On Sat, Jan 15, 2011 at 03:15:07PM +0000, Russell King - ARM Linux wrote:
> > > No - I've been suggesting for about a week now about doing two entirely
> > > separate consolidations.
> > I didn't read that out of your mails.
> 
> It was actually four days ago:
> | Maybe another approach for the time being is to unify in two steps: first
> | unify the implementations which use a spinlock - and those which can use
> | a spinlock, and separately those which must use a mutex.
> | 
> | Then this issue can be revisited in the future.
> 
> > > I think it would be insane to do the consolidation of the two different
> > > implementations in one patch or even one patch set.  There needs to be
> > > a consolidation of spinlock-based clks as one patch set, which is
> > > entirely separate and independent from the consolidation of mutex-based
> > > clks.
> > I think they should share most of the code.  Apart from calling
> > different locking functions they should be pretty much identical, no?
> 
> That way you get unions of mutexes and spinlocks (which is one thing
> we're trying to avoid) and conditionals controlling whether a mutex
> or spinlock is taken - which we've already ascertained was strongly
> objected to by folk in mainline (and quite rightfully so IMHO.)
If the decision is done basing on a Kconfig symbol it's an #ifdef.
That's not great but IMHO much better than a runtime decision.
 
> > > What if one of the consolidations turns out to be a problem?  Do we want
> > > to throw both out, or do we want to keep as much as we possibly can?
> > Do you really expect fundamental problems that make it necessary to
> > switch all platforms that use the (say) sleeping variant back to their
> > original implementation?  I don't think that when the general idea of
> > using clk_ops prooves for the atomic case it cannot happen that a
> > "native" implementation for a sleeping clk is better that a sleeping
> > clk_ops implementation.
> 
> I'm saying keep all the options open until we've got the whole thing
> sorted out.  If you think it's possible to do without creating a mess
> in the process - and without unions of mutexes and spinlocks or
> conditionals controlling whether we use mutex_lock vs spin_lock then
> please show the patches.

Jeremy: I think it would be quite easy to convert your series to use an
#ifdef instead of the flag.  I don't want to do this (at least not
without asking first) because it's your series, not mine.  How should we
proceed?

Best regards
Uwe

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

Re: Locking in the clk API

[Christer Weinigel]

On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>> On platforms that need to sleep to enable the UART clock, configuring
>> the UART as the kernel console should be equivalent to userspace opening
>> the UART device, i.e. enable the clock.  At least to me that feels like
>> an acceptable tradeoff, and if I wanted to save the last bit of power
>> I'll have to refrain from using UART as the kernel console.
>
> Well, we're not discussing a _new_ API here - we're discussing an API
> with existing users which works completely fine on the devices its
> used, with differing expectations between implementations.

Yes, so to fulfil the requirement that printk needs to call clk_enable 
from atomic contexts, document that clk_enable can not sleep.  Or add 
the clk_enable_atomic call and modify printk to use it.

>> Both of these feel like they should use a call such as clk_get_atomic
>> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used
>> to indicate that it would have to sleep) and delegate to a worker thread
>> to enable the clock.  To catch uses of plain clk_enable from atomic
>> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,
>> but would help a bit at least.
>
> We've never allowed clk_get() to be called in interruptible context,
> so that's not the issue.  The issue is purely about clk_enable() and
> clk_disable() and whether they should be able to be called in atomic
> context or not.

My bad, it should have said "clk_enable_atomic".

> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
>
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.

Won't that cause a lot of code duplication?  If it's possible to have 
one sane implementation, why not go for it at once?

   /Christer

Re: Locking in the clk API

[Christer Weinigel]

On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>> On platforms that need to sleep to enable the UART clock, configuring
>> the UART as the kernel console should be equivalent to userspace opening
>> the UART device, i.e. enable the clock.  At least to me that feels like
>> an acceptable tradeoff, and if I wanted to save the last bit of power
>> I'll have to refrain from using UART as the kernel console.
>
> Well, we're not discussing a _new_ API here - we're discussing an API
> with existing users which works completely fine on the devices its
> used, with differing expectations between implementations.

Yes, so to fulfil the requirement that printk needs to call clk_enable 
from atomic contexts, document that clk_enable can not sleep.  Or add 
the clk_enable_atomic call and modify printk to use it.

>> Both of these feel like they should use a call such as clk_get_atomic
>> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used
>> to indicate that it would have to sleep) and delegate to a worker thread
>> to enable the clock.  To catch uses of plain clk_enable from atomic
>> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,
>> but would help a bit at least.
>
> We've never allowed clk_get() to be called in interruptible context,
> so that's not the issue.  The issue is purely about clk_enable() and
> clk_disable() and whether they should be able to be called in atomic
> context or not.

My bad, it should have said "clk_enable_atomic".

> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
>
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.

Won't that cause a lot of code duplication?  If it's possible to have 
one sane implementation, why not go for it at once?

   /Christer

Locking in the clk API

[Christer Weinigel]

On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>> On platforms that need to sleep to enable the UART clock, configuring
>> the UART as the kernel console should be equivalent to userspace opening
>> the UART device, i.e. enable the clock.  At least to me that feels like
>> an acceptable tradeoff, and if I wanted to save the last bit of power
>> I'll have to refrain from using UART as the kernel console.
>
> Well, we're not discussing a _new_ API here - we're discussing an API
> with existing users which works completely fine on the devices its
> used, with differing expectations between implementations.

Yes, so to fulfil the requirement that printk needs to call clk_enable 
from atomic contexts, document that clk_enable can not sleep.  Or add 
the clk_enable_atomic call and modify printk to use it.

>> Both of these feel like they should use a call such as clk_get_atomic
>> and be able to handle EWOULDBLOCK/EAGAIN (or whatever error code is used
>> to indicate that it would have to sleep) and delegate to a worker thread
>> to enable the clock.  To catch uses of plain clk_enable from atomic
>> contects, add a WARN_ON/BUG_ON(in_atomic()).  It won't catch everything,
>> but would help a bit at least.
>
> We've never allowed clk_get() to be called in interruptible context,
> so that's not the issue.  The issue is purely about clk_enable() and
> clk_disable() and whether they should be able to be called in atomic
> context or not.

My bad, it should have said "clk_enable_atomic".

> There's been a lot of talk on this issue for ages with no real progress
> that I'm just going to repeat: let's unify those implementations which
> use a spinlock for their clks into one consolidated solution, and
> a separate consolidated solution for those which use a mutex.
>
> This will at least allow us to have _some_ consolidation of the existing
> implementations - and it doesn't add anything to the problem at hand.
> It might actually help identify what can be done at code level to resolve
> this issue.

Won't that cause a lot of code duplication?  If it's possible to have 
one sane implementation, why not go for it at once?

   /Christer

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:07:38PM +0100, Christer Weinigel wrote:
> On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
>> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>>> On platforms that need to sleep to enable the UART clock, configuring
>>> the UART as the kernel console should be equivalent to userspace opening
>>> the UART device, i.e. enable the clock.  At least to me that feels like
>>> an acceptable tradeoff, and if I wanted to save the last bit of power
>>> I'll have to refrain from using UART as the kernel console.
>>
>> Well, we're not discussing a _new_ API here - we're discussing an API
>> with existing users which works completely fine on the devices its
>> used, with differing expectations between implementations.
>
> Yes, so to fulfil the requirement that printk needs to call clk_enable  
> from atomic contexts, document that clk_enable can not sleep.  Or add  
> the clk_enable_atomic call and modify printk to use it.

You really need to read the entire thread - I've already said that yet
discussion continues about how to solve the problem.  This thread which
has been running for a number of days now has been entirely about how
to solve this.

>> There's been a lot of talk on this issue for ages with no real progress
>> that I'm just going to repeat: let's unify those implementations which
>> use a spinlock for their clks into one consolidated solution, and
>> a separate consolidated solution for those which use a mutex.
>>
>> This will at least allow us to have _some_ consolidation of the existing
>> implementations - and it doesn't add anything to the problem at hand.
>> It might actually help identify what can be done at code level to resolve
>> this issue.
>
> Won't that cause a lot of code duplication?  If it's possible to have  
> one sane implementation, why not go for it at once?

No one can agree on what the one sane implementation should be.

Consider this: is it better to continue talking about this for the next
six months, while still having N spinlock based implementations, and M
mutex based implementations.

Or is it better to consolidate the N spinlock based implementations
down to one spinlock implementation, and M mutex based implementations
down to one mutex implementation, and then discuss how to resolve the
differences between the two implementations?

I personally don't care whether we stick with the ever growing number of
clk API implementations, whether we continue discussing it for the next
six months, or whether we consolidate what we can.  I suspect there are
people who do care greatly, so I'm trying to suggest a way we can see
_some_ kind of progress on this consolidation effort.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:07:38PM +0100, Christer Weinigel wrote:
> On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
>> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>>> On platforms that need to sleep to enable the UART clock, configuring
>>> the UART as the kernel console should be equivalent to userspace opening
>>> the UART device, i.e. enable the clock.  At least to me that feels like
>>> an acceptable tradeoff, and if I wanted to save the last bit of power
>>> I'll have to refrain from using UART as the kernel console.
>>
>> Well, we're not discussing a _new_ API here - we're discussing an API
>> with existing users which works completely fine on the devices its
>> used, with differing expectations between implementations.
>
> Yes, so to fulfil the requirement that printk needs to call clk_enable  
> from atomic contexts, document that clk_enable can not sleep.  Or add  
> the clk_enable_atomic call and modify printk to use it.

You really need to read the entire thread - I've already said that yet
discussion continues about how to solve the problem.  This thread which
has been running for a number of days now has been entirely about how
to solve this.

>> There's been a lot of talk on this issue for ages with no real progress
>> that I'm just going to repeat: let's unify those implementations which
>> use a spinlock for their clks into one consolidated solution, and
>> a separate consolidated solution for those which use a mutex.
>>
>> This will at least allow us to have _some_ consolidation of the existing
>> implementations - and it doesn't add anything to the problem at hand.
>> It might actually help identify what can be done at code level to resolve
>> this issue.
>
> Won't that cause a lot of code duplication?  If it's possible to have  
> one sane implementation, why not go for it at once?

No one can agree on what the one sane implementation should be.

Consider this: is it better to continue talking about this for the next
six months, while still having N spinlock based implementations, and M
mutex based implementations.

Or is it better to consolidate the N spinlock based implementations
down to one spinlock implementation, and M mutex based implementations
down to one mutex implementation, and then discuss how to resolve the
differences between the two implementations?

I personally don't care whether we stick with the ever growing number of
clk API implementations, whether we continue discussing it for the next
six months, or whether we consolidate what we can.  I suspect there are
people who do care greatly, so I'm trying to suggest a way we can see
_some_ kind of progress on this consolidation effort.

Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:07:38PM +0100, Christer Weinigel wrote:
> On 01/15/2011 03:53 PM, Russell King - ARM Linux wrote:
>> On Sat, Jan 15, 2011 at 03:02:25PM +0100, Christer Weinigel wrote:
>>> On platforms that need to sleep to enable the UART clock, configuring
>>> the UART as the kernel console should be equivalent to userspace opening
>>> the UART device, i.e. enable the clock.  At least to me that feels like
>>> an acceptable tradeoff, and if I wanted to save the last bit of power
>>> I'll have to refrain from using UART as the kernel console.
>>
>> Well, we're not discussing a _new_ API here - we're discussing an API
>> with existing users which works completely fine on the devices its
>> used, with differing expectations between implementations.
>
> Yes, so to fulfil the requirement that printk needs to call clk_enable  
> from atomic contexts, document that clk_enable can not sleep.  Or add  
> the clk_enable_atomic call and modify printk to use it.

You really need to read the entire thread - I've already said that yet
discussion continues about how to solve the problem.  This thread which
has been running for a number of days now has been entirely about how
to solve this.

>> There's been a lot of talk on this issue for ages with no real progress
>> that I'm just going to repeat: let's unify those implementations which
>> use a spinlock for their clks into one consolidated solution, and
>> a separate consolidated solution for those which use a mutex.
>>
>> This will at least allow us to have _some_ consolidation of the existing
>> implementations - and it doesn't add anything to the problem at hand.
>> It might actually help identify what can be done at code level to resolve
>> this issue.
>
> Won't that cause a lot of code duplication?  If it's possible to have  
> one sane implementation, why not go for it at once?

No one can agree on what the one sane implementation should be.

Consider this: is it better to continue talking about this for the next
six months, while still having N spinlock based implementations, and M
mutex based implementations.

Or is it better to consolidate the N spinlock based implementations
down to one spinlock implementation, and M mutex based implementations
down to one mutex implementation, and then discuss how to resolve the
differences between the two implementations?

I personally don't care whether we stick with the ever growing number of
clk API implementations, whether we continue discussing it for the next
six months, or whether we consolidate what we can.  I suspect there are
people who do care greatly, so I'm trying to suggest a way we can see
_some_ kind of progress on this consolidation effort.

Re: Locking in the clk API

[Christer Weinigel]

On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
 > You really need to read the entire thread - I've already said that yet

> discussion continues about how to solve the problem.  This thread which
> has been running for a number of days now has been entirely about how
> to solve this.


Sigh, the always oh so polite Russell.  I have read the thread before; I 
reread the whole thread one more time before posting.

> Consider this: is it better to continue talking about this for the next
> six months, while still having N spinlock based implementations, and M
> mutex based implementations.
>
> Or is it better to consolidate the N spinlock based implementations
> down to one spinlock implementation, and M mutex based implementations
> down to one mutex implementation, and then discuss how to resolve the
> differences between the two implementations?


Going that way might very well mean that you will be stuck with two 
implementations forever.  But yes, it might be better with two working 
ones than one which takes a bit longer to finish.

But my impression is that the different suggestions in the thread aren't 
that far apart.  Except for the discussion if clk_enable/disable should 
be able to sleep or not, people seem to agree on most of the rest of the 
API.

   /Christer

Re: Locking in the clk API

[Christer Weinigel]

On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
 > You really need to read the entire thread - I've already said that yet

> discussion continues about how to solve the problem.  This thread which
> has been running for a number of days now has been entirely about how
> to solve this.


Sigh, the always oh so polite Russell.  I have read the thread before; I 
reread the whole thread one more time before posting.

> Consider this: is it better to continue talking about this for the next
> six months, while still having N spinlock based implementations, and M
> mutex based implementations.
>
> Or is it better to consolidate the N spinlock based implementations
> down to one spinlock implementation, and M mutex based implementations
> down to one mutex implementation, and then discuss how to resolve the
> differences between the two implementations?


Going that way might very well mean that you will be stuck with two 
implementations forever.  But yes, it might be better with two working 
ones than one which takes a bit longer to finish.

But my impression is that the different suggestions in the thread aren't 
that far apart.  Except for the discussion if clk_enable/disable should 
be able to sleep or not, people seem to agree on most of the rest of the 
API.

   /Christer

Locking in the clk API

[Christer Weinigel]

On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
 > You really need to read the entire thread - I've already said that yet

> discussion continues about how to solve the problem.  This thread which
> has been running for a number of days now has been entirely about how
> to solve this.


Sigh, the always oh so polite Russell.  I have read the thread before; I 
reread the whole thread one more time before posting.

> Consider this: is it better to continue talking about this for the next
> six months, while still having N spinlock based implementations, and M
> mutex based implementations.
>
> Or is it better to consolidate the N spinlock based implementations
> down to one spinlock implementation, and M mutex based implementations
> down to one mutex implementation, and then discuss how to resolve the
> differences between the two implementations?


Going that way might very well mean that you will be stuck with two 
implementations forever.  But yes, it might be better with two working 
ones than one which takes a bit longer to finish.

But my impression is that the different suggestions in the thread aren't 
that far apart.  Except for the discussion if clk_enable/disable should 
be able to sleep or not, people seem to agree on most of the rest of the 
API.

   /Christer

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:44:22PM +0100, Christer Weinigel wrote:
> On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
> > You really need to read the entire thread - I've already said that yet
>
>> discussion continues about how to solve the problem.  This thread which
>> has been running for a number of days now has been entirely about how
>> to solve this.
>
>
> Sigh, the always oh so polite Russell.  I have read the thread before; I  
> reread the whole thread one more time before posting.

Look, the clk API unification issue has been rattling around for six months
or more not making very much progress.  Should it continue to be discussed
for another six months while nothing happens because agreement can't be
reached?

Do you not realise what you suggested has already been proposed?

Does it help the discussion to have more people coming into the discussion
saying "we should do X" when we've already had people suggesting that we
should already do X - and we've had people saying afterwards "we should
do Y"?

Do you really think that you saying "we should do X" means that we'll have
lots of people suddenly saying "oh yes, you're right" when they didn't
before?

It's covering old ground over and over again.  Raising the same points
over and over again is just a pointless waste of time - it just sends the
discussion around the same loops time and time again.  Nothing actually
ever gets resolved but lots of time gets wasted discussing it.

>> Consider this: is it better to continue talking about this for the next
>> six months, while still having N spinlock based implementations, and M
>> mutex based implementations.
>>
>> Or is it better to consolidate the N spinlock based implementations
>> down to one spinlock implementation, and M mutex based implementations
>> down to one mutex implementation, and then discuss how to resolve the
>> differences between the two implementations?
>
>
> Going that way might very well mean that you will be stuck with two  
> implementations forever.  But yes, it might be better with two working  
> ones than one which takes a bit longer to finish.
>
> But my impression is that the different suggestions in the thread aren't  
> that far apart.  Except for the discussion if clk_enable/disable should  
> be able to sleep or not, people seem to agree on most of the rest of the  
> API.

As I said, at this point I _really_ don't care what happens provided
it doesn't end up screwing the facilities enjoyed by the existing
implementations.

I'm tired of reading this discussion.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:44:22PM +0100, Christer Weinigel wrote:
> On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
> > You really need to read the entire thread - I've already said that yet
>
>> discussion continues about how to solve the problem.  This thread which
>> has been running for a number of days now has been entirely about how
>> to solve this.
>
>
> Sigh, the always oh so polite Russell.  I have read the thread before; I  
> reread the whole thread one more time before posting.

Look, the clk API unification issue has been rattling around for six months
or more not making very much progress.  Should it continue to be discussed
for another six months while nothing happens because agreement can't be
reached?

Do you not realise what you suggested has already been proposed?

Does it help the discussion to have more people coming into the discussion
saying "we should do X" when we've already had people suggesting that we
should already do X - and we've had people saying afterwards "we should
do Y"?

Do you really think that you saying "we should do X" means that we'll have
lots of people suddenly saying "oh yes, you're right" when they didn't
before?

It's covering old ground over and over again.  Raising the same points
over and over again is just a pointless waste of time - it just sends the
discussion around the same loops time and time again.  Nothing actually
ever gets resolved but lots of time gets wasted discussing it.

>> Consider this: is it better to continue talking about this for the next
>> six months, while still having N spinlock based implementations, and M
>> mutex based implementations.
>>
>> Or is it better to consolidate the N spinlock based implementations
>> down to one spinlock implementation, and M mutex based implementations
>> down to one mutex implementation, and then discuss how to resolve the
>> differences between the two implementations?
>
>
> Going that way might very well mean that you will be stuck with two  
> implementations forever.  But yes, it might be better with two working  
> ones than one which takes a bit longer to finish.
>
> But my impression is that the different suggestions in the thread aren't  
> that far apart.  Except for the discussion if clk_enable/disable should  
> be able to sleep or not, people seem to agree on most of the rest of the  
> API.

As I said, at this point I _really_ don't care what happens provided
it doesn't end up screwing the facilities enjoyed by the existing
implementations.

I'm tired of reading this discussion.

Locking in the clk API

[Russell King - ARM Linux]

On Sat, Jan 15, 2011 at 06:44:22PM +0100, Christer Weinigel wrote:
> On 01/15/2011 06:20 PM, Russell King - ARM Linux wrote:
> > You really need to read the entire thread - I've already said that yet
>
>> discussion continues about how to solve the problem.  This thread which
>> has been running for a number of days now has been entirely about how
>> to solve this.
>
>
> Sigh, the always oh so polite Russell.  I have read the thread before; I  
> reread the whole thread one more time before posting.

Look, the clk API unification issue has been rattling around for six months
or more not making very much progress.  Should it continue to be discussed
for another six months while nothing happens because agreement can't be
reached?

Do you not realise what you suggested has already been proposed?

Does it help the discussion to have more people coming into the discussion
saying "we should do X" when we've already had people suggesting that we
should already do X - and we've had people saying afterwards "we should
do Y"?

Do you really think that you saying "we should do X" means that we'll have
lots of people suddenly saying "oh yes, you're right" when they didn't
before?

It's covering old ground over and over again.  Raising the same points
over and over again is just a pointless waste of time - it just sends the
discussion around the same loops time and time again.  Nothing actually
ever gets resolved but lots of time gets wasted discussing it.

>> Consider this: is it better to continue talking about this for the next
>> six months, while still having N spinlock based implementations, and M
>> mutex based implementations.
>>
>> Or is it better to consolidate the N spinlock based implementations
>> down to one spinlock implementation, and M mutex based implementations
>> down to one mutex implementation, and then discuss how to resolve the
>> differences between the two implementations?
>
>
> Going that way might very well mean that you will be stuck with two  
> implementations forever.  But yes, it might be better with two working  
> ones than one which takes a bit longer to finish.
>
> But my impression is that the different suggestions in the thread aren't  
> that far apart.  Except for the discussion if clk_enable/disable should  
> be able to sleep or not, people seem to agree on most of the rest of the  
> API.

As I said, at this point I _really_ don't care what happens provided
it doesn't end up screwing the facilities enjoyed by the existing
implementations.

I'm tired of reading this discussion.

Re: Locking in the clk API

[Grant Likely]

2011/1/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
>> Hi Russell,
>>
>> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
>> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
>> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
>> >
>> > There's been a lot of talk on this issue for ages with no real progress
>> > that I'm just going to repeat: let's unify those implementations which
>> > use a spinlock for their clks into one consolidated solution, and
>> > a separate consolidated solution for those which use a mutex.
>> >
>> > This will at least allow us to have _some_ consolidation of the existing
>> > implementations - and it doesn't add anything to the problem at hand.
>> > It might actually help identify what can be done at code level to resolve
>> > this issue.
>> Great, so how should we do it?  Take Jeremy's patch and make the
>> differenciation between sleeping and atomic implementation a Kconfig
>> variable?
>
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
>
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set.  There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.

+1

>
> What if one of the consolidations turns out to be a problem?  Do we want
> to throw both out, or do we want to keep as much as we possibly can?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Locking in the clk API

[Grant Likely]

2011/1/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-König wrote:
>> Hi Russell,
>>
>> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
>> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
>> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
>> >
>> > There's been a lot of talk on this issue for ages with no real progress
>> > that I'm just going to repeat: let's unify those implementations which
>> > use a spinlock for their clks into one consolidated solution, and
>> > a separate consolidated solution for those which use a mutex.
>> >
>> > This will at least allow us to have _some_ consolidation of the existing
>> > implementations - and it doesn't add anything to the problem at hand.
>> > It might actually help identify what can be done at code level to resolve
>> > this issue.
>> Great, so how should we do it?  Take Jeremy's patch and make the
>> differenciation between sleeping and atomic implementation a Kconfig
>> variable?
>
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
>
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set.  There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.

+1

>
> What if one of the consolidations turns out to be a problem?  Do we want
> to throw both out, or do we want to keep as much as we possibly can?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Locking in the clk API

[Grant Likely]

2011/1/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jan 15, 2011 at 04:03:31PM +0100, Uwe Kleine-K?nig wrote:
>> Hi Russell,
>>
>> On Sat, Jan 15, 2011 at 02:53:58PM +0000, Russell King - ARM Linux wrote:
>> > We've been around returning EAGAIN, WARN_ONs, BUG_ONs, having clk_enable()
>> > vs clk_enable_atomic(), clk_enable_cansleep() vs clk_enable(), etc.
>> >
>> > There's been a lot of talk on this issue for ages with no real progress
>> > that I'm just going to repeat: let's unify those implementations which
>> > use a spinlock for their clks into one consolidated solution, and
>> > a separate consolidated solution for those which use a mutex.
>> >
>> > This will at least allow us to have _some_ consolidation of the existing
>> > implementations - and it doesn't add anything to the problem at hand.
>> > It might actually help identify what can be done at code level to resolve
>> > this issue.
>> Great, so how should we do it? ?Take Jeremy's patch and make the
>> differenciation between sleeping and atomic implementation a Kconfig
>> variable?
>
> No - I've been suggesting for about a week now about doing two entirely
> separate consolidations.
>
> I think it would be insane to do the consolidation of the two different
> implementations in one patch or even one patch set. ?There needs to be
> a consolidation of spinlock-based clks as one patch set, which is
> entirely separate and independent from the consolidation of mutex-based
> clks.

+1

>
> What if one of the consolidations turns out to be a problem? ?Do we want
> to throw both out, or do we want to keep as much as we possibly can?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Locking in the clk API

[Jeremy Kerr]

Hi all,

Based on the discussion from this thread, my plan is to:

* Change the 'common struct clk' patches to only use a spinlock for locking. 
This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable 
counts), and be callable from atomic contexts.

* Rework the initial docs (posted in the first mail of this thread) document 
to illustrate the new locking requirements.

* Request input from the platforms that require clk_enable (etc) to sleep, 
about how we can merge the two implementations.

Russell - is this OK?

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi all,

Based on the discussion from this thread, my plan is to:

* Change the 'common struct clk' patches to only use a spinlock for locking. 
This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable 
counts), and be callable from atomic contexts.

* Rework the initial docs (posted in the first mail of this thread) document 
to illustrate the new locking requirements.

* Request input from the platforms that require clk_enable (etc) to sleep, 
about how we can merge the two implementations.

Russell - is this OK?

Cheers,


Jeremy

Locking in the clk API

[Jeremy Kerr]

Hi all,

Based on the discussion from this thread, my plan is to:

* Change the 'common struct clk' patches to only use a spinlock for locking. 
This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable 
counts), and be callable from atomic contexts.

* Rework the initial docs (posted in the first mail of this thread) document 
to illustrate the new locking requirements.

* Request input from the platforms that require clk_enable (etc) to sleep, 
about how we can merge the two implementations.

Russell - is this OK?

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi all,

Based on the discussion from this thread, my plan is to:

* Change the 'common struct clk' patches to only use a spinlock for locking. 
This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable 
counts), and be callable from atomic contexts.

* Rework the initial docs (posted in the first mail of this thread) to 
illustrate the new locking requirements.

* Request input from the platforms that require clk_enable (etc) to sleep, 
about how we can merge the two implementations.

Russell - is this OK?

Cheers,


Jeremy

Re: Locking in the clk API

[Jeremy Kerr]

Hi all,

Based on the discussion from this thread, my plan is to:

* Change the 'common struct clk' patches to only use a spinlock for locking. 
This means that clk_{en,dis}able will acquire a per-clk spinlock (for enable 
counts), and be callable from atomic contexts.

* Rework the initial docs (posted in the first mail of this thread) to 
illustrate the new locking requirements.

* Request input from the platforms that require clk_enable (etc) to sleep, 
about how we can merge the two implementations.

Russell - is this OK?

Cheers,


Jeremy

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 03:15, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> * clk_enable: may sleep
>>
>> * clk_disable: may not sleep, but it's possible to make the global
>>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>>   non-atomic context.
>>
>> * clk_get_rate: may not sleep
>>
>> * clk_set_rate: may sleep
>>
>> As we build up our requirements, we can adjust as suitable.
>>
> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today. You
> have an API that can or can not sleep with no indication as to which is
> which based off of the API naming, which is just asking for trouble.
> 
> As it is today, most users expect that these are all usable from atomic
> context, and as far as I can tell the only special case you have are for
> some crap busses with insane latencies. In this case you should simply
> pile on _cansleep() versions of the API and make it apparent that those
> drivers are the special cases, not the other way around.

The trouble is not with the drivers, is the fact there could be a clock
tree where, say the closest to the driver is easy to control but the
base of the tree may be a PLL which requires time to settle.

Now, there's a lot of work in the 'embedded' space where the focus is on
the power consumption, so powering down PLLs when they are not needed is
a good thing to have/

> Having half of the API sleepable and the other not with no indication of
> which is which simply makes it completely unusable and error prone for
> both atomic and non-atomic contexts.

I really don't like the fact that people are doing these things in
atomic contexts, and I think we should apply some pressure to move
the atomic caller cases to use systems where they can sleep such as
using threaded-irq handlers (they work very nicely)

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 03:15, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> * clk_enable: may sleep
>>
>> * clk_disable: may not sleep, but it's possible to make the global
>>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>>   non-atomic context.
>>
>> * clk_get_rate: may not sleep
>>
>> * clk_set_rate: may sleep
>>
>> As we build up our requirements, we can adjust as suitable.
>>
> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today. You
> have an API that can or can not sleep with no indication as to which is
> which based off of the API naming, which is just asking for trouble.
> 
> As it is today, most users expect that these are all usable from atomic
> context, and as far as I can tell the only special case you have are for
> some crap busses with insane latencies. In this case you should simply
> pile on _cansleep() versions of the API and make it apparent that those
> drivers are the special cases, not the other way around.

The trouble is not with the drivers, is the fact there could be a clock
tree where, say the closest to the driver is easy to control but the
base of the tree may be a PLL which requires time to settle.

Now, there's a lot of work in the 'embedded' space where the focus is on
the power consumption, so powering down PLLs when they are not needed is
a good thing to have/

> Having half of the API sleepable and the other not with no indication of
> which is which simply makes it completely unusable and error prone for
> both atomic and non-atomic contexts.

I really don't like the fact that people are doing these things in
atomic contexts, and I think we should apply some pressure to move
the atomic caller cases to use systems where they can sleep such as
using threaded-irq handlers (they work very nicely)

Locking in the clk API

[Ben Dooks]

On 11/01/11 03:15, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 10:16:42AM +0800, Jeremy Kerr wrote:
>> * clk_enable: may sleep
>>
>> * clk_disable: may not sleep, but it's possible to make the global
>>   clk_disable() atomic and defer the actual disable (clk->ops.disable()) to a
>>   non-atomic context.
>>
>> * clk_get_rate: may not sleep
>>
>> * clk_set_rate: may sleep
>>
>> As we build up our requirements, we can adjust as suitable.
>>
> This looks like a complete disaster, and is also completely inconsistent
> with how the API is being used by the vast majority of users today. You
> have an API that can or can not sleep with no indication as to which is
> which based off of the API naming, which is just asking for trouble.
> 
> As it is today, most users expect that these are all usable from atomic
> context, and as far as I can tell the only special case you have are for
> some crap busses with insane latencies. In this case you should simply
> pile on _cansleep() versions of the API and make it apparent that those
> drivers are the special cases, not the other way around.

The trouble is not with the drivers, is the fact there could be a clock
tree where, say the closest to the driver is easy to control but the
base of the tree may be a PLL which requires time to settle.

Now, there's a lot of work in the 'embedded' space where the focus is on
the power consumption, so powering down PLLs when they are not needed is
a good thing to have/

> Having half of the API sleepable and the other not with no indication of
> which is which simply makes it completely unusable and error prone for
> both atomic and non-atomic contexts.

I really don't like the fact that people are doing these things in
atomic contexts, and I think we should apply some pressure to move
the atomic caller cases to use systems where they can sleep such as
using threaded-irq handlers (they work very nicely)

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 04:54, Paul Mundt wrote:
> Hi Jeremy,
> 
> On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
>>> This looks like a complete disaster, and is also completely inconsistent
>>> with how the API is being used by the vast majority of users today.
>>
>> I've been basing this on the mxc clock code, which acquires a mutex for all 
>> clk_enable()s. This may not be representative of the majority of clock usage.
>>
>> From a qui

[snip]

> One other thing to be aware of is that the clkdev code maintains its own
> list mutex, so the addition and deletion of clkdev lookups in addition to
> the clkdev-backed clk_get() will all be sleepable. It would however be
> possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
> for the common cases, but it's not entirely obvious that it would be
> worth the complexity it would introduce.

Anyone looking up clks on the fly really should think more carefully
about this, as it is firstly possible to be an expensive operation on
systems with multiple clocks, and secondly, in my view, stupid.

> If you're going to do this work it would also be helpful to spell out the
> locking semantics within linux/clk.h at the same time (it might even be
> worthwhile doing this incrementally and getting all of the platforms
> in-line before attempting to consolidate things too aggressively), as
> it's apparent from the cases you cite there are at least a couple of
> boards that aren't quite in line with what everyone else is doing.
> 
> In general we have to accept that the dynamic creation, deletion, and
> looking up of clocks is going to be a sleepable case, and the rest will
> likely have to be split out in to _cansleep and default atomic-safe
> variants.

I would vote for all clk lookup and reference counting code be made
sleep-able and define it as such.

> set_rate/parent and friends likewise are done atomically for some and
> sleepable for others, so it doesn't seem like there's going to be much
> choice other than simply splitting out the API for these cases.

And we fall into another problem here, if we set_parent of a clock,
which causes one clock to start and another to stop, then what
happens with non-atomic clocks?

if not, we're going to have drivers either keeping clocks on all
the time, or having to put duplicated enable/set-parent/disable
logic in all over the place.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 04:54, Paul Mundt wrote:
> Hi Jeremy,
> 
> On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
>>> This looks like a complete disaster, and is also completely inconsistent
>>> with how the API is being used by the vast majority of users today.
>>
>> I've been basing this on the mxc clock code, which acquires a mutex for all 
>> clk_enable()s. This may not be representative of the majority of clock usage.
>>
>> From a qui

[snip]

> One other thing to be aware of is that the clkdev code maintains its own
> list mutex, so the addition and deletion of clkdev lookups in addition to
> the clkdev-backed clk_get() will all be sleepable. It would however be
> possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
> for the common cases, but it's not entirely obvious that it would be
> worth the complexity it would introduce.

Anyone looking up clks on the fly really should think more carefully
about this, as it is firstly possible to be an expensive operation on
systems with multiple clocks, and secondly, in my view, stupid.

> If you're going to do this work it would also be helpful to spell out the
> locking semantics within linux/clk.h at the same time (it might even be
> worthwhile doing this incrementally and getting all of the platforms
> in-line before attempting to consolidate things too aggressively), as
> it's apparent from the cases you cite there are at least a couple of
> boards that aren't quite in line with what everyone else is doing.
> 
> In general we have to accept that the dynamic creation, deletion, and
> looking up of clocks is going to be a sleepable case, and the rest will
> likely have to be split out in to _cansleep and default atomic-safe
> variants.

I would vote for all clk lookup and reference counting code be made
sleep-able and define it as such.

> set_rate/parent and friends likewise are done atomically for some and
> sleepable for others, so it doesn't seem like there's going to be much
> choice other than simply splitting out the API for these cases.

And we fall into another problem here, if we set_parent of a clock,
which causes one clock to start and another to stop, then what
happens with non-atomic clocks?

if not, we're going to have drivers either keeping clocks on all
the time, or having to put duplicated enable/set-parent/disable
logic in all over the place.

Locking in the clk API

[Ben Dooks]

On 11/01/11 04:54, Paul Mundt wrote:
> Hi Jeremy,
> 
> On Tue, Jan 11, 2011 at 12:11:29PM +0800, Jeremy Kerr wrote:
>>> This looks like a complete disaster, and is also completely inconsistent
>>> with how the API is being used by the vast majority of users today.
>>
>> I've been basing this on the mxc clock code, which acquires a mutex for all 
>> clk_enable()s. This may not be representative of the majority of clock usage.
>>
>> From a qui

[snip]

> One other thing to be aware of is that the clkdev code maintains its own
> list mutex, so the addition and deletion of clkdev lookups in addition to
> the clkdev-backed clk_get() will all be sleepable. It would however be
> possible to back a one-shot atomic-safe clk_get() with a mutex_trylock()
> for the common cases, but it's not entirely obvious that it would be
> worth the complexity it would introduce.

Anyone looking up clks on the fly really should think more carefully
about this, as it is firstly possible to be an expensive operation on
systems with multiple clocks, and secondly, in my view, stupid.

> If you're going to do this work it would also be helpful to spell out the
> locking semantics within linux/clk.h at the same time (it might even be
> worthwhile doing this incrementally and getting all of the platforms
> in-line before attempting to consolidate things too aggressively), as
> it's apparent from the cases you cite there are at least a couple of
> boards that aren't quite in line with what everyone else is doing.
> 
> In general we have to accept that the dynamic creation, deletion, and
> looking up of clocks is going to be a sleepable case, and the rest will
> likely have to be split out in to _cansleep and default atomic-safe
> variants.

I would vote for all clk lookup and reference counting code be made
sleep-able and define it as such.

> set_rate/parent and friends likewise are done atomically for some and
> sleepable for others, so it doesn't seem like there's going to be much
> choice other than simply splitting out the API for these cases.

And we fall into another problem here, if we set_parent of a clock,
which causes one clock to start and another to stop, then what
happens with non-atomic clocks?

if not, we're going to have drivers either keeping clocks on all
the time, or having to put duplicated enable/set-parent/disable
logic in all over the place.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 10:13, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> So, it sounds like the best approach is to provide an atomic clk_enable. I 
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>> 	might_sleep();
>>
>> 	[...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>> 	[...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I 
>> think that this way around illustrates the atomic 'restriction' at the call 
>> site more clearly. When the drivers don't care about the atomicity, 
>> clk_enable() is fine. When drivers do need an atomic clock, 
>> clk_enable_atomic() shows this requirement.
>>
> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

So, how does the software deal with the clock not being available if the
PLL powers up and takes time to lock and the software goes and tries to
use the device? We need to ensure the clock is on and stable before the
clk_enable() call returns.

For all the drivers I've written so far, clk_enable() and disable()
calls are done from sleep-able contexts such as the mmc work queue
or other such systems.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 10:13, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> So, it sounds like the best approach is to provide an atomic clk_enable. I 
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>> 	might_sleep();
>>
>> 	[...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>> 	[...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I 
>> think that this way around illustrates the atomic 'restriction' at the call 
>> site more clearly. When the drivers don't care about the atomicity, 
>> clk_enable() is fine. When drivers do need an atomic clock, 
>> clk_enable_atomic() shows this requirement.
>>
> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

So, how does the software deal with the clock not being available if the
PLL powers up and takes time to lock and the software goes and tries to
use the device? We need to ensure the clock is on and stable before the
clk_enable() call returns.

For all the drivers I've written so far, clk_enable() and disable()
calls are done from sleep-able contexts such as the mmc work queue
or other such systems.

Locking in the clk API

[Ben Dooks]

On 11/01/11 10:13, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:44:59PM +0800, Jeremy Kerr wrote:
>> So, it sounds like the best approach is to provide an atomic clk_enable. I 
>> agree with Sascha that the clk_enable and clk_enable_atomic polarity makes the 
>> most sense, so how about:
>>
>> int clk_enable(struct clk *clk)
>> {
>> 	might_sleep();
>>
>> 	[...]
>> }
>>
>> int clk_enable_atomic(struct clk *clk)
>> {
>> 	BUG_ON(!(clk->flags & CLK_ATOMIC));
>>
>> 	[...]
>> }
>>
>> Paul: even though you mention that the atomic clocks are the usual case, I 
>> think that this way around illustrates the atomic 'restriction' at the call 
>> site more clearly. When the drivers don't care about the atomicity, 
>> clk_enable() is fine. When drivers do need an atomic clock, 
>> clk_enable_atomic() shows this requirement.
>>
> No, the sleeping clock case is and always will be a corner case, and I
> have no interest in pretending otherwise. On SH we have hundreds of
> clocks that are all usable in the atomic context and perhaps less than a
> dozen that aren't (and even in those cases much of the PLL negotiation is
> handled in hardware so there's never any visibility for the lock-down
> from the software side, other architectures also have similar behaviour).

So, how does the software deal with the clock not being available if the
PLL powers up and takes time to lock and the software goes and tries to
use the device? We need to ensure the clock is on and stable before the
clk_enable() call returns.

For all the drivers I've written so far, clk_enable() and disable()
calls are done from sleep-able contexts such as the mmc work queue
or other such systems.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 12:18, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
>> Hi Paul,
>>
>>> No, the sleeping clock case is and always will be a corner case, and I
>>> have no interest in pretending otherwise. On SH we have hundreds of
>>> clocks that are all usable in the atomic context and perhaps less than a
>>> dozen that aren't (and even in those cases much of the PLL negotiation is
>>> handled in hardware so there's never any visibility for the lock-down
>>> from the software side, other architectures also have similar behaviour).
>>
>> I'm not too worried about the corner-cases on the *implementation* side, more 
>> the corner-cases on the API side: are we seeing more users of the API that 
>> require an atomic clock, or more that don't care?
>>
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

No, the API has always been defined to ensure clk_enable() returns once
a clock is running and usable, so if the case where there are PLLs in
the way is inconvenient to you, then sorry but they exist already.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 12:18, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
>> Hi Paul,
>>
>>> No, the sleeping clock case is and always will be a corner case, and I
>>> have no interest in pretending otherwise. On SH we have hundreds of
>>> clocks that are all usable in the atomic context and perhaps less than a
>>> dozen that aren't (and even in those cases much of the PLL negotiation is
>>> handled in hardware so there's never any visibility for the lock-down
>>> from the software side, other architectures also have similar behaviour).
>>
>> I'm not too worried about the corner-cases on the *implementation* side, more 
>> the corner-cases on the API side: are we seeing more users of the API that 
>> require an atomic clock, or more that don't care?
>>
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

No, the API has always been defined to ensure clk_enable() returns once
a clock is running and usable, so if the case where there are PLLs in
the way is inconvenient to you, then sorry but they exist already.

Locking in the clk API

[Ben Dooks]

On 11/01/11 12:18, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 06:30:18PM +0800, Jeremy Kerr wrote:
>> Hi Paul,
>>
>>> No, the sleeping clock case is and always will be a corner case, and I
>>> have no interest in pretending otherwise. On SH we have hundreds of
>>> clocks that are all usable in the atomic context and perhaps less than a
>>> dozen that aren't (and even in those cases much of the PLL negotiation is
>>> handled in hardware so there's never any visibility for the lock-down
>>> from the software side, other architectures also have similar behaviour).
>>
>> I'm not too worried about the corner-cases on the *implementation* side, more 
>> the corner-cases on the API side: are we seeing more users of the API that 
>> require an atomic clock, or more that don't care?
>>
> Again, you are approaching it from the angle that an atomic clock is a
> special requirement rather than the default behaviour. Sleeping for
> lookup, addition, and deletion are all quite acceptable, but
> enable/disable pairs have always been intended to be usable from atomic
> context. Anyone that doesn't count on that fact is either dealing with
> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
> implementing any sort of fine grained runtime power management for their
> platform.

No, the API has always been defined to ensure clk_enable() returns once
a clock is running and usable, so if the case where there are PLLs in
the way is inconvenient to you, then sorry but they exist already.

Re: Locking in the clk API

[Ben Dooks]

On 12/01/11 02:25, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
>> On 01/11/2011 04:18 AM, Paul Mundt wrote:
>>> Again, you are approaching it from the angle that an atomic clock is a
>>> special requirement rather than the default behaviour. Sleeping for
>>> lookup, addition, and deletion are all quite acceptable, but
>>> enable/disable pairs have always been intended to be usable from atomic
>>> context. Anyone that doesn't count on that fact is either dealing with
>>> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
>>> implementing any sort of fine grained runtime power management for their
>>> platform.
>>
>> Paul,
>>
>> I see you repeating this point a couple of times and I'm a bit confused 
>> how you handle the clock tree/dependencies.
>>
>> Does your clock driver NOT hide the details of what root clock/PLL a 
>> branch clock is sourced from? If you do hide the details of the root/PLL 
>> source, how do you get the branch clk_enable() to be done atomically if 
>> the root/PLL enables are not possible in atomic context?
>>
>> Is it simply a matter of your hardware having PLLs and root clocks that 
>> can be turned on/off quickly?
>>
> There are a few cases where PLL clocks would benefit from a clk_enable()
> that can sleep, but for us these are almost all in the device space. Most
> of the SoCs however have fairly straightforward clock topologies where
> the root clock in question is an external oscillator that can't be
> disabled, and anything chained below that sits behind a PLL divider or
> multiplier bank that can likewise be adjusted atomically. The vast
> majority of the clocks below that can likewise be trivially
> enabled/disabled from atomic context.

All the Samsung SoCs have multiple PLLs as the root of their clock
trees, with some muxing options to feed in oscillator inputs. Many
of the systems I've seen have a 48MHz source for the USB, 12MHz
as a PLL source and then generate a pile of different frequencies for
various peripherals via the PLLs...

this is especially important for the cases where you need very specific
frequencies such as audio playback of tv encoding.

Re: Locking in the clk API

[Ben Dooks]

On 12/01/11 02:25, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
>> On 01/11/2011 04:18 AM, Paul Mundt wrote:
>>> Again, you are approaching it from the angle that an atomic clock is a
>>> special requirement rather than the default behaviour. Sleeping for
>>> lookup, addition, and deletion are all quite acceptable, but
>>> enable/disable pairs have always been intended to be usable from atomic
>>> context. Anyone that doesn't count on that fact is either dealing with
>>> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
>>> implementing any sort of fine grained runtime power management for their
>>> platform.
>>
>> Paul,
>>
>> I see you repeating this point a couple of times and I'm a bit confused 
>> how you handle the clock tree/dependencies.
>>
>> Does your clock driver NOT hide the details of what root clock/PLL a 
>> branch clock is sourced from? If you do hide the details of the root/PLL 
>> source, how do you get the branch clk_enable() to be done atomically if 
>> the root/PLL enables are not possible in atomic context?
>>
>> Is it simply a matter of your hardware having PLLs and root clocks that 
>> can be turned on/off quickly?
>>
> There are a few cases where PLL clocks would benefit from a clk_enable()
> that can sleep, but for us these are almost all in the device space. Most
> of the SoCs however have fairly straightforward clock topologies where
> the root clock in question is an external oscillator that can't be
> disabled, and anything chained below that sits behind a PLL divider or
> multiplier bank that can likewise be adjusted atomically. The vast
> majority of the clocks below that can likewise be trivially
> enabled/disabled from atomic context.

All the Samsung SoCs have multiple PLLs as the root of their clock
trees, with some muxing options to feed in oscillator inputs. Many
of the systems I've seen have a 48MHz source for the USB, 12MHz
as a PLL source and then generate a pile of different frequencies for
various peripherals via the PLLs...

this is especially important for the cases where you need very specific
frequencies such as audio playback of tv encoding.

Locking in the clk API

[Ben Dooks]

On 12/01/11 02:25, Paul Mundt wrote:
> On Tue, Jan 11, 2011 at 05:54:42PM -0800, Saravana Kannan wrote:
>> On 01/11/2011 04:18 AM, Paul Mundt wrote:
>>> Again, you are approaching it from the angle that an atomic clock is a
>>> special requirement rather than the default behaviour. Sleeping for
>>> lookup, addition, and deletion are all quite acceptable, but
>>> enable/disable pairs have always been intended to be usable from atomic
>>> context. Anyone that doesn't count on that fact is either dealing with
>>> special case clocks (PLLs, root clocks, etc.) or simply hasn't bothered
>>> implementing any sort of fine grained runtime power management for their
>>> platform.
>>
>> Paul,
>>
>> I see you repeating this point a couple of times and I'm a bit confused 
>> how you handle the clock tree/dependencies.
>>
>> Does your clock driver NOT hide the details of what root clock/PLL a 
>> branch clock is sourced from? If you do hide the details of the root/PLL 
>> source, how do you get the branch clk_enable() to be done atomically if 
>> the root/PLL enables are not possible in atomic context?
>>
>> Is it simply a matter of your hardware having PLLs and root clocks that 
>> can be turned on/off quickly?
>>
> There are a few cases where PLL clocks would benefit from a clk_enable()
> that can sleep, but for us these are almost all in the device space. Most
> of the SoCs however have fairly straightforward clock topologies where
> the root clock in question is an external oscillator that can't be
> disabled, and anything chained below that sits behind a PLL divider or
> multiplier bank that can likewise be adjusted atomically. The vast
> majority of the clocks below that can likewise be trivially
> enabled/disabled from atomic context.

All the Samsung SoCs have multiple PLLs as the root of their clock
trees, with some muxing options to feed in oscillator inputs. Many
of the systems I've seen have a 48MHz source for the USB, 12MHz
as a PLL source and then generate a pile of different frequencies for
various peripherals via the PLLs...

this is especially important for the cases where you need very specific
frequencies such as audio playback of tv encoding.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 11:15, Richard Zhao wrote:
> 2011/1/11 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

[snip]

> A well running board will not enable/disable PLLs frequently. It don't
> make sense. PLLs are normally disabled on request to enter low power
> mode, rather not because all their child clocks are disabled.   So we
> don't have to consider the time here.

I'd rather see that if all child clocks are disabled the PLL is
powered down then. It means PLLs _could_ be left running even
when power-down mode is selected because the system still thinks
that a peripheral is using them.

If you want to make it so that each low-power mode has to work
out what PLLs need to be disabled and then re-enabled makes me
want to be sick. Hiding this stuff behind specific implementations
is a recipe for disaster.

Re: Locking in the clk API

[Ben Dooks]

On 11/01/11 11:15, Richard Zhao wrote:
> 2011/1/11 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

[snip]

> A well running board will not enable/disable PLLs frequently. It don't
> make sense. PLLs are normally disabled on request to enter low power
> mode, rather not because all their child clocks are disabled.   So we
> don't have to consider the time here.

I'd rather see that if all child clocks are disabled the PLL is
powered down then. It means PLLs _could_ be left running even
when power-down mode is selected because the system still thinks
that a peripheral is using them.

If you want to make it so that each low-power mode has to work
out what PLLs need to be disabled and then re-enabled makes me
want to be sick. Hiding this stuff behind specific implementations
is a recipe for disaster.

Locking in the clk API

[Ben Dooks]

On 11/01/11 11:15, Richard Zhao wrote:
> 2011/1/11 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:

[snip]

> A well running board will not enable/disable PLLs frequently. It don't
> make sense. PLLs are normally disabled on request to enter low power
> mode, rather not because all their child clocks are disabled.   So we
> don't have to consider the time here.

I'd rather see that if all child clocks are disabled the PLL is
powered down then. It means PLLs _could_ be left running even
when power-down mode is selected because the system still thinks
that a peripheral is using them.

If you want to make it so that each low-power mode has to work
out what PLLs need to be disabled and then re-enabled makes me
want to be sick. Hiding this stuff behind specific implementations
is a recipe for disaster.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> I really don't like the fact that people are doing these things in
> atomic contexts, and I think we should apply some pressure to move
> the atomic caller cases to use systems where they can sleep such as
> using threaded-irq handlers (they work very nicely)

How do you ensure that printk is always called from a non-atomic
context?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> I really don't like the fact that people are doing these things in
> atomic contexts, and I think we should apply some pressure to move
> the atomic caller cases to use systems where they can sleep such as
> using threaded-irq handlers (they work very nicely)

How do you ensure that printk is always called from a non-atomic
context?

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> I really don't like the fact that people are doing these things in
> atomic contexts, and I think we should apply some pressure to move
> the atomic caller cases to use systems where they can sleep such as
> using threaded-irq handlers (they work very nicely)

How do you ensure that printk is always called from a non-atomic
context?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
> I would vote for all clk lookup and reference counting code be made
> sleep-able and define it as such.

Always has been and probably always will be.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
> I would vote for all clk lookup and reference counting code be made
> sleep-able and define it as such.

Always has been and probably always will be.

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
> I would vote for all clk lookup and reference counting code be made
> sleep-able and define it as such.

Always has been and probably always will be.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> If you want to make it so that each low-power mode has to work
> out what PLLs need to be disabled and then re-enabled makes me
> want to be sick. Hiding this stuff behind specific implementations
> is a recipe for disaster.

Why should systems which don't suffer from such problems be prevented
from gaining power saving from turning off their clocks when devices
are not being used (eg, the console serial port.)

One solution to your root PLL issue would be to have a separate set of
enable/disable API calls which get called at setup/release time (or
whatever you'd like to call it) which can only be called from non-atomic
context.  Maybe clk_prepare() and clk_unprepare().  These functions
should perform whatever is necessary to ensure that the clock source
is available for use atomically when clk_enable() is called.

So, in your case, clk_prepare() ensures that the root PLL is enabled,
clk_unprepare() allows it to be turned off.

In the case of a console driver, clk_prepare() can be called when we
know the port will be used as a console.  clk_enable() is then called
before writing out the string, and clk_disable() after we've completely
sent the last character.

This allows the best of both worlds.  We now have a clk_enable() which
can be used to turn the clocks off through the clock tree up to the first
non-atomic clock, and we also have a way to deal with those which need
to sleep.  So not only do "sleeping clock" implementations become possible
but these "sleeping clock" implementations also get the opportunity to
shutdown some of their clock tree with minimal latency for doing so.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> If you want to make it so that each low-power mode has to work
> out what PLLs need to be disabled and then re-enabled makes me
> want to be sick. Hiding this stuff behind specific implementations
> is a recipe for disaster.

Why should systems which don't suffer from such problems be prevented
from gaining power saving from turning off their clocks when devices
are not being used (eg, the console serial port.)

One solution to your root PLL issue would be to have a separate set of
enable/disable API calls which get called at setup/release time (or
whatever you'd like to call it) which can only be called from non-atomic
context.  Maybe clk_prepare() and clk_unprepare().  These functions
should perform whatever is necessary to ensure that the clock source
is available for use atomically when clk_enable() is called.

So, in your case, clk_prepare() ensures that the root PLL is enabled,
clk_unprepare() allows it to be turned off.

In the case of a console driver, clk_prepare() can be called when we
know the port will be used as a console.  clk_enable() is then called
before writing out the string, and clk_disable() after we've completely
sent the last character.

This allows the best of both worlds.  We now have a clk_enable() which
can be used to turn the clocks off through the clock tree up to the first
non-atomic clock, and we also have a way to deal with those which need
to sleep.  So not only do "sleeping clock" implementations become possible
but these "sleeping clock" implementations also get the opportunity to
shutdown some of their clock tree with minimal latency for doing so.

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> If you want to make it so that each low-power mode has to work
> out what PLLs need to be disabled and then re-enabled makes me
> want to be sick. Hiding this stuff behind specific implementations
> is a recipe for disaster.

Why should systems which don't suffer from such problems be prevented
from gaining power saving from turning off their clocks when devices
are not being used (eg, the console serial port.)

One solution to your root PLL issue would be to have a separate set of
enable/disable API calls which get called at setup/release time (or
whatever you'd like to call it) which can only be called from non-atomic
context.  Maybe clk_prepare() and clk_unprepare().  These functions
should perform whatever is necessary to ensure that the clock source
is available for use atomically when clk_enable() is called.

So, in your case, clk_prepare() ensures that the root PLL is enabled,
clk_unprepare() allows it to be turned off.

In the case of a console driver, clk_prepare() can be called when we
know the port will be used as a console.  clk_enable() is then called
before writing out the string, and clk_disable() after we've completely
sent the last character.

This allows the best of both worlds.  We now have a clk_enable() which
can be used to turn the clocks off through the clock tree up to the first
non-atomic clock, and we also have a way to deal with those which need
to sleep.  So not only do "sleeping clock" implementations become possible
but these "sleeping clock" implementations also get the opportunity to
shutdown some of their clock tree with minimal latency for doing so.

Re: Locking in the clk API

[Nicolas Pitre]

On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> > I really don't like the fact that people are doing these things in
> > atomic contexts, and I think we should apply some pressure to move
> > the atomic caller cases to use systems where they can sleep such as
> > using threaded-irq handlers (they work very nicely)
> 
> How do you ensure that printk is always called from a non-atomic
> context?

Is this a good example?  I don't think that power sensitive systems such 
as a cellphone should keep printk() enabled in the final product.  The 
output from printk() over a serial port is a debugging convenience, and 
trying to aggressively turn on/off the serial clock around each call to 
printk() is a bit silly.  Better simply turn the serial clock on 
whenever its console facility is opened, and turn it off when the 
console is closed, which should be good enough in that context.


Nicolas

Re: Locking in the clk API

[Nicolas Pitre]

On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> > I really don't like the fact that people are doing these things in
> > atomic contexts, and I think we should apply some pressure to move
> > the atomic caller cases to use systems where they can sleep such as
> > using threaded-irq handlers (they work very nicely)
> 
> How do you ensure that printk is always called from a non-atomic
> context?

Is this a good example?  I don't think that power sensitive systems such 
as a cellphone should keep printk() enabled in the final product.  The 
output from printk() over a serial port is a debugging convenience, and 
trying to aggressively turn on/off the serial clock around each call to 
printk() is a bit silly.  Better simply turn the serial clock on 
whenever its console facility is opened, and turn it off when the 
console is closed, which should be good enough in that context.


Nicolas

Locking in the clk API

[Nicolas Pitre]

On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:

> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
> > I really don't like the fact that people are doing these things in
> > atomic contexts, and I think we should apply some pressure to move
> > the atomic caller cases to use systems where they can sleep such as
> > using threaded-irq handlers (they work very nicely)
> 
> How do you ensure that printk is always called from a non-atomic
> context?

Is this a good example?  I don't think that power sensitive systems such 
as a cellphone should keep printk() enabled in the final product.  The 
output from printk() over a serial port is a debugging convenience, and 
trying to aggressively turn on/off the serial clock around each call to 
printk() is a bit silly.  Better simply turn the serial clock on 
whenever its console facility is opened, and turn it off when the 
console is closed, which should be good enough in that context.


Nicolas

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console.  clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds.  We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep.  So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This is exactly what I suggested in my last post, except the console example.
Only to be a part of common clock api because it's not very safe to assume
future SoCs will have the same simple clock topologies that they have today.

Not to mean to teach, but I hope you realize with more and more
device controller being crammed into ever shrinking SoCs,
clock would eventually have to be flexible in functionality
and complicated in hierarchy. Ben already gave examples
of Audio, MFC and Video controllers of latest Samsung SoCs.

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console.  clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds.  We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep.  So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This is exactly what I suggested in my last post, except the console example.
Only to be a part of common clock api because it's not very safe to assume
future SoCs will have the same simple clock topologies that they have today.

Not to mean to teach, but I hope you realize with more and more
device controller being crammed into ever shrinking SoCs,
clock would eventually have to be flexible in functionality
and complicated in hierarchy. Ben already gave examples
of Audio, MFC and Video controllers of latest Samsung SoCs.

Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console. ?clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds. ?We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep. ?So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This is exactly what I suggested in my last post, except the console example.
Only to be a part of common clock api because it's not very safe to assume
future SoCs will have the same simple clock topologies that they have today.

Not to mean to teach, but I hope you realize with more and more
device controller being crammed into ever shrinking SoCs,
clock would eventually have to be flexible in functionality
and complicated in hierarchy. Ben already gave examples
of Audio, MFC and Video controllers of latest Samsung SoCs.

Re: Locking in the clk API

[Dima Zavin]

Here's a better one.

Many devices use serial display panels sitting on either MDDI or MIPI
links. The interface clocks need to be on, but they stay in low-power
mode while the display is on. The display controller however does not
need to be on since the serial panels typically have a local
framebuffer that does the idle panel refresh on it's own. When a new
frame comes in to be displayed, you need to clock on the display
controller, DMA the data to the panel, and when it's done turn the
controller off. The clk_enable may or may not happen at irq context,
depending on whether or not you are starting the DMA from a
vsync/tear-effect irq or simply from the screen_update() function. The
clk_disable will most certainly happen from the DMA_DONE irq.

--Dima

On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>> > I really don't like the fact that people are doing these things in
>> > atomic contexts, and I think we should apply some pressure to move
>> > the atomic caller cases to use systems where they can sleep such as
>> > using threaded-irq handlers (they work very nicely)
>>
>> How do you ensure that printk is always called from a non-atomic
>> context?
>
> Is this a good example?  I don't think that power sensitive systems such
> as a cellphone should keep printk() enabled in the final product.  The
> output from printk() over a serial port is a debugging convenience, and
> trying to aggressively turn on/off the serial clock around each call to
> printk() is a bit silly.  Better simply turn the serial clock on
> whenever its console facility is opened, and turn it off when the
> console is closed, which should be good enough in that context.
>
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Locking in the clk API

[Dima Zavin]

Here's a better one.

Many devices use serial display panels sitting on either MDDI or MIPI
links. The interface clocks need to be on, but they stay in low-power
mode while the display is on. The display controller however does not
need to be on since the serial panels typically have a local
framebuffer that does the idle panel refresh on it's own. When a new
frame comes in to be displayed, you need to clock on the display
controller, DMA the data to the panel, and when it's done turn the
controller off. The clk_enable may or may not happen at irq context,
depending on whether or not you are starting the DMA from a
vsync/tear-effect irq or simply from the screen_update() function. The
clk_disable will most certainly happen from the DMA_DONE irq.

--Dima

On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>> > I really don't like the fact that people are doing these things in
>> > atomic contexts, and I think we should apply some pressure to move
>> > the atomic caller cases to use systems where they can sleep such as
>> > using threaded-irq handlers (they work very nicely)
>>
>> How do you ensure that printk is always called from a non-atomic
>> context?
>
> Is this a good example?  I don't think that power sensitive systems such
> as a cellphone should keep printk() enabled in the final product.  The
> output from printk() over a serial port is a debugging convenience, and
> trying to aggressively turn on/off the serial clock around each call to
> printk() is a bit silly.  Better simply turn the serial clock on
> whenever its console facility is opened, and turn it off when the
> console is closed, which should be good enough in that context.
>
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Locking in the clk API

[Dima Zavin]

Here's a better one.

Many devices use serial display panels sitting on either MDDI or MIPI
links. The interface clocks need to be on, but they stay in low-power
mode while the display is on. The display controller however does not
need to be on since the serial panels typically have a local
framebuffer that does the idle panel refresh on it's own. When a new
frame comes in to be displayed, you need to clock on the display
controller, DMA the data to the panel, and when it's done turn the
controller off. The clk_enable may or may not happen at irq context,
depending on whether or not you are starting the DMA from a
vsync/tear-effect irq or simply from the screen_update() function. The
clk_disable will most certainly happen from the DMA_DONE irq.

--Dima

On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>
>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>> > I really don't like the fact that people are doing these things in
>> > atomic contexts, and I think we should apply some pressure to move
>> > the atomic caller cases to use systems where they can sleep such as
>> > using threaded-irq handlers (they work very nicely)
>>
>> How do you ensure that printk is always called from a non-atomic
>> context?
>
> Is this a good example? ?I don't think that power sensitive systems such
> as a cellphone should keep printk() enabled in the final product. ?The
> output from printk() over a serial port is a debugging convenience, and
> trying to aggressively turn on/off the serial clock around each call to
> printk() is a bit silly. ?Better simply turn the serial clock on
> whenever its console facility is opened, and turn it off when the
> console is closed, which should be good enough in that context.
>
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>> I would vote for all clk lookup and reference counting code be made
>> sleep-able and define it as such.
>
> Always has been and probably always will be.
>

clk_enable/disable APIs have refcounting and they certainly aren't 
sleep-able. I'm not sure if that's what Ben meant though.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>> I would vote for all clk lookup and reference counting code be made
>> sleep-able and define it as such.
>
> Always has been and probably always will be.
>

clk_enable/disable APIs have refcounting and they certainly aren't 
sleep-able. I'm not sure if that's what Ben meant though.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>> I would vote for all clk lookup and reference counting code be made
>> sleep-able and define it as such.
>
> Always has been and probably always will be.
>

clk_enable/disable APIs have refcounting and they certainly aren't 
sleep-able. I'm not sure if that's what Ben meant though.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 06:06 PM, Dima Zavin wrote:
> On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre<nicolas.pitre@linaro.org>  wrote:
>> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>>
>>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>>>> I really don't like the fact that people are doing these things in
>>>> atomic contexts, and I think we should apply some pressure to move
>>>> the atomic caller cases to use systems where they can sleep such as
>>>> using threaded-irq handlers (they work very nicely)
>>>
>>> How do you ensure that printk is always called from a non-atomic
>>> context?
>>
>> Is this a good example?  I don't think that power sensitive systems such
>> as a cellphone should keep printk() enabled in the final product.  The
>> output from printk() over a serial port is a debugging convenience, and
>> trying to aggressively turn on/off the serial clock around each call to
>> printk() is a bit silly.  Better simply turn the serial clock on
>> whenever its console facility is opened, and turn it off when the
>> console is closed, which should be good enough in that context.

[fixing top post]

 > Here's a better one.
 >
 > Many devices use serial display panels sitting on either MDDI or MIPI
 > links. The interface clocks need to be on, but they stay in low-power
 > mode while the display is on. The display controller however does not
 > need to be on since the serial panels typically have a local
 > framebuffer that does the idle panel refresh on it's own. When a new
 > frame comes in to be displayed, you need to clock on the display
 > controller, DMA the data to the panel, and when it's done turn the
 > controller off. The clk_enable may or may not happen at irq context,
 > depending on whether or not you are starting the DMA from a
 > vsync/tear-effect irq or simply from the screen_update() function. The
 > clk_disable will most certainly happen from the DMA_DONE irq.

Why do we need to turn on the clock in the IRQ? Why not defer it to a 
workqueue (or whatever is the method of the day to defer work from an 
IRQ)? The advantage of doing the clk_enable in the IRQ should be 
negligible compared to the time it takes to do the DMA.

In my opinion, the only major reason for needing atomic clk APIs was due 
to device_ops->suspend being atomic. Since that's not the case anymore, 
I really don't see a justification for atomic clocks. Sure, I might have 
missed some exceptions, but in that case we should make the atomic APIs 
an exception (add clk_enable_atomic) and not the norm.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 06:06 PM, Dima Zavin wrote:
> On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre<nicolas.pitre@linaro.org>  wrote:
>> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>>
>>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>>>> I really don't like the fact that people are doing these things in
>>>> atomic contexts, and I think we should apply some pressure to move
>>>> the atomic caller cases to use systems where they can sleep such as
>>>> using threaded-irq handlers (they work very nicely)
>>>
>>> How do you ensure that printk is always called from a non-atomic
>>> context?
>>
>> Is this a good example?  I don't think that power sensitive systems such
>> as a cellphone should keep printk() enabled in the final product.  The
>> output from printk() over a serial port is a debugging convenience, and
>> trying to aggressively turn on/off the serial clock around each call to
>> printk() is a bit silly.  Better simply turn the serial clock on
>> whenever its console facility is opened, and turn it off when the
>> console is closed, which should be good enough in that context.

[fixing top post]

 > Here's a better one.
 >
 > Many devices use serial display panels sitting on either MDDI or MIPI
 > links. The interface clocks need to be on, but they stay in low-power
 > mode while the display is on. The display controller however does not
 > need to be on since the serial panels typically have a local
 > framebuffer that does the idle panel refresh on it's own. When a new
 > frame comes in to be displayed, you need to clock on the display
 > controller, DMA the data to the panel, and when it's done turn the
 > controller off. The clk_enable may or may not happen at irq context,
 > depending on whether or not you are starting the DMA from a
 > vsync/tear-effect irq or simply from the screen_update() function. The
 > clk_disable will most certainly happen from the DMA_DONE irq.

Why do we need to turn on the clock in the IRQ? Why not defer it to a 
workqueue (or whatever is the method of the day to defer work from an 
IRQ)? The advantage of doing the clk_enable in the IRQ should be 
negligible compared to the time it takes to do the DMA.

In my opinion, the only major reason for needing atomic clk APIs was due 
to device_ops->suspend being atomic. Since that's not the case anymore, 
I really don't see a justification for atomic clocks. Sure, I might have 
missed some exceptions, but in that case we should make the atomic APIs 
an exception (add clk_enable_atomic) and not the norm.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/20/2011 06:06 PM, Dima Zavin wrote:
> On Thu, Jan 20, 2011 at 1:30 PM, Nicolas Pitre<nicolas.pitre@linaro.org>  wrote:
>> On Thu, 20 Jan 2011, Russell King - ARM Linux wrote:
>>
>>> On Thu, Jan 20, 2011 at 04:29:15PM +0000, Ben Dooks wrote:
>>>> I really don't like the fact that people are doing these things in
>>>> atomic contexts, and I think we should apply some pressure to move
>>>> the atomic caller cases to use systems where they can sleep such as
>>>> using threaded-irq handlers (they work very nicely)
>>>
>>> How do you ensure that printk is always called from a non-atomic
>>> context?
>>
>> Is this a good example?  I don't think that power sensitive systems such
>> as a cellphone should keep printk() enabled in the final product.  The
>> output from printk() over a serial port is a debugging convenience, and
>> trying to aggressively turn on/off the serial clock around each call to
>> printk() is a bit silly.  Better simply turn the serial clock on
>> whenever its console facility is opened, and turn it off when the
>> console is closed, which should be good enough in that context.

[fixing top post]

 > Here's a better one.
 >
 > Many devices use serial display panels sitting on either MDDI or MIPI
 > links. The interface clocks need to be on, but they stay in low-power
 > mode while the display is on. The display controller however does not
 > need to be on since the serial panels typically have a local
 > framebuffer that does the idle panel refresh on it's own. When a new
 > frame comes in to be displayed, you need to clock on the display
 > controller, DMA the data to the panel, and when it's done turn the
 > controller off. The clk_enable may or may not happen at irq context,
 > depending on whether or not you are starting the DMA from a
 > vsync/tear-effect irq or simply from the screen_update() function. The
 > clk_disable will most certainly happen from the DMA_DONE irq.

Why do we need to turn on the clock in the IRQ? Why not defer it to a 
workqueue (or whatever is the method of the day to defer work from an 
IRQ)? The advantage of doing the clk_enable in the IRQ should be 
negligible compared to the time it takes to do the DMA.

In my opinion, the only major reason for needing atomic clk APIs was due 
to device_ops->suspend being atomic. Since that's not the case anymore, 
I really don't see a justification for atomic clocks. Sure, I might have 
missed some exceptions, but in that case we should make the atomic APIs 
an exception (add clk_enable_atomic) and not the norm.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>>> If you want to make it so that each low-power mode has to work
>>> out what PLLs need to be disabled and then re-enabled makes me
>>> want to be sick. Hiding this stuff behind specific implementations
>>> is a recipe for disaster.
>>
>> Why should systems which don't suffer from such problems be prevented
>> from gaining power saving from turning off their clocks when devices
>> are not being used (eg, the console serial port.)
>>
>> One solution to your root PLL issue would be to have a separate set of
>> enable/disable API calls which get called at setup/release time (or
>> whatever you'd like to call it) which can only be called from non-atomic
>> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> should perform whatever is necessary to ensure that the clock source
>> is available for use atomically when clk_enable() is called.
>>
>> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> clk_unprepare() allows it to be turned off.
>>
>> In the case of a console driver, clk_prepare() can be called when we
>> know the port will be used as a console.  clk_enable() is then called
>> before writing out the string, and clk_disable() after we've completely
>> sent the last character.
>>
>> This allows the best of both worlds.  We now have a clk_enable() which
>> can be used to turn the clocks off through the clock tree up to the first
>> non-atomic clock, and we also have a way to deal with those which need
>> to sleep.  So not only do "sleeping clock" implementations become possible
>> but these "sleeping clock" implementations also get the opportunity to
>> shutdown some of their clock tree with minimal latency for doing so.
>
> This is exactly what I suggested in my last post, except the console example.
> Only to be a part of common clock api because it's not very safe to assume
> future SoCs will have the same simple clock topologies that they have today.
>
> Not to mean to teach, but I hope you realize with more and more
> device controller being crammed into ever shrinking SoCs,
> clock would eventually have to be flexible in functionality
> and complicated in hierarchy. Ben already gave examples
> of Audio, MFC and Video controllers of latest Samsung SoCs.

plus

a) If only Samsung bsp implements the api, it would be impossible to
share drivers, those that can be, with other platforms without nasty ifdef's.
b) If the task of unification starts with only a particular platform made to
implement a new api, the attempt kills its own purpose.

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>>> If you want to make it so that each low-power mode has to work
>>> out what PLLs need to be disabled and then re-enabled makes me
>>> want to be sick. Hiding this stuff behind specific implementations
>>> is a recipe for disaster.
>>
>> Why should systems which don't suffer from such problems be prevented
>> from gaining power saving from turning off their clocks when devices
>> are not being used (eg, the console serial port.)
>>
>> One solution to your root PLL issue would be to have a separate set of
>> enable/disable API calls which get called at setup/release time (or
>> whatever you'd like to call it) which can only be called from non-atomic
>> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> should perform whatever is necessary to ensure that the clock source
>> is available for use atomically when clk_enable() is called.
>>
>> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> clk_unprepare() allows it to be turned off.
>>
>> In the case of a console driver, clk_prepare() can be called when we
>> know the port will be used as a console.  clk_enable() is then called
>> before writing out the string, and clk_disable() after we've completely
>> sent the last character.
>>
>> This allows the best of both worlds.  We now have a clk_enable() which
>> can be used to turn the clocks off through the clock tree up to the first
>> non-atomic clock, and we also have a way to deal with those which need
>> to sleep.  So not only do "sleeping clock" implementations become possible
>> but these "sleeping clock" implementations also get the opportunity to
>> shutdown some of their clock tree with minimal latency for doing so.
>
> This is exactly what I suggested in my last post, except the console example.
> Only to be a part of common clock api because it's not very safe to assume
> future SoCs will have the same simple clock topologies that they have today.
>
> Not to mean to teach, but I hope you realize with more and more
> device controller being crammed into ever shrinking SoCs,
> clock would eventually have to be flexible in functionality
> and complicated in hierarchy. Ben already gave examples
> of Audio, MFC and Video controllers of latest Samsung SoCs.

plus

a) If only Samsung bsp implements the api, it would be impossible to
share drivers, those that can be, with other platforms without nasty ifdef's.
b) If the task of unification starts with only a particular platform made to
implement a new api, the attempt kills its own purpose.

Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>>> If you want to make it so that each low-power mode has to work
>>> out what PLLs need to be disabled and then re-enabled makes me
>>> want to be sick. Hiding this stuff behind specific implementations
>>> is a recipe for disaster.
>>
>> Why should systems which don't suffer from such problems be prevented
>> from gaining power saving from turning off their clocks when devices
>> are not being used (eg, the console serial port.)
>>
>> One solution to your root PLL issue would be to have a separate set of
>> enable/disable API calls which get called at setup/release time (or
>> whatever you'd like to call it) which can only be called from non-atomic
>> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
>> should perform whatever is necessary to ensure that the clock source
>> is available for use atomically when clk_enable() is called.
>>
>> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> clk_unprepare() allows it to be turned off.
>>
>> In the case of a console driver, clk_prepare() can be called when we
>> know the port will be used as a console. ?clk_enable() is then called
>> before writing out the string, and clk_disable() after we've completely
>> sent the last character.
>>
>> This allows the best of both worlds. ?We now have a clk_enable() which
>> can be used to turn the clocks off through the clock tree up to the first
>> non-atomic clock, and we also have a way to deal with those which need
>> to sleep. ?So not only do "sleeping clock" implementations become possible
>> but these "sleeping clock" implementations also get the opportunity to
>> shutdown some of their clock tree with minimal latency for doing so.
>
> This is exactly what I suggested in my last post, except the console example.
> Only to be a part of common clock api because it's not very safe to assume
> future SoCs will have the same simple clock topologies that they have today.
>
> Not to mean to teach, but I hope you realize with more and more
> device controller being crammed into ever shrinking SoCs,
> clock would eventually have to be flexible in functionality
> and complicated in hierarchy. Ben already gave examples
> of Audio, MFC and Video controllers of latest Samsung SoCs.

plus

a) If only Samsung bsp implements the api, it would be impossible to
share drivers, those that can be, with other platforms without nasty ifdef's.
b) If the task of unification starts with only a particular platform made to
implement a new api, the attempt kills its own purpose.

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console.  clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds.  We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep.  So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This suggestion looked promising till I realized that clk_set_rate() 
will still be atomic. clk_set_rate() will need to enable/disable the 
PLLs depending on which PLLs the rates are derived from. So, the locking 
in clk_prepare/unprepare() still has to be atomic since the "slow stuff" 
is shared with clk_set_rate().

IMO, the most workable/flexible suggestion I have seen so far is:
- Having a way to explicitly ask for an atomic clock from clk_get(). 
That way the driver can decide to fail early during probe or decide to 
enable/disable in open/close or if it gets atomic clocks to 
enable/disable in atomic context.
- Atomic and sleep-able variants of clk_enable/disable/set_rate. I 
personally prefer the existing APIs to be sleep-able and introduce new 
atomic variants, but it's not worth the time arguing over that.

Taking one step at a time, do we all at least agree having two variants 
of enable/disable/set_rate?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/20/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console.  clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds.  We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep.  So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This suggestion looked promising till I realized that clk_set_rate() 
will still be atomic. clk_set_rate() will need to enable/disable the 
PLLs depending on which PLLs the rates are derived from. So, the locking 
in clk_prepare/unprepare() still has to be atomic since the "slow stuff" 
is shared with clk_set_rate().

IMO, the most workable/flexible suggestion I have seen so far is:
- Having a way to explicitly ask for an atomic clock from clk_get(). 
That way the driver can decide to fail early during probe or decide to 
enable/disable in open/close or if it gets atomic clocks to 
enable/disable in atomic context.
- Atomic and sleep-able variants of clk_enable/disable/set_rate. I 
personally prefer the existing APIs to be sleep-able and introduce new 
atomic variants, but it's not worth the time arguing over that.

Taking one step at a time, do we all at least agree having two variants 
of enable/disable/set_rate?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/20/2011 11:08 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> If you want to make it so that each low-power mode has to work
>> out what PLLs need to be disabled and then re-enabled makes me
>> want to be sick. Hiding this stuff behind specific implementations
>> is a recipe for disaster.
>
> Why should systems which don't suffer from such problems be prevented
> from gaining power saving from turning off their clocks when devices
> are not being used (eg, the console serial port.)
>
> One solution to your root PLL issue would be to have a separate set of
> enable/disable API calls which get called at setup/release time (or
> whatever you'd like to call it) which can only be called from non-atomic
> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> should perform whatever is necessary to ensure that the clock source
> is available for use atomically when clk_enable() is called.
>
> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> clk_unprepare() allows it to be turned off.
>
> In the case of a console driver, clk_prepare() can be called when we
> know the port will be used as a console.  clk_enable() is then called
> before writing out the string, and clk_disable() after we've completely
> sent the last character.
>
> This allows the best of both worlds.  We now have a clk_enable() which
> can be used to turn the clocks off through the clock tree up to the first
> non-atomic clock, and we also have a way to deal with those which need
> to sleep.  So not only do "sleeping clock" implementations become possible
> but these "sleeping clock" implementations also get the opportunity to
> shutdown some of their clock tree with minimal latency for doing so.

This suggestion looked promising till I realized that clk_set_rate() 
will still be atomic. clk_set_rate() will need to enable/disable the 
PLLs depending on which PLLs the rates are derived from. So, the locking 
in clk_prepare/unprepare() still has to be atomic since the "slow stuff" 
is shared with clk_set_rate().

IMO, the most workable/flexible suggestion I have seen so far is:
- Having a way to explicitly ask for an atomic clock from clk_get(). 
That way the driver can decide to fail early during probe or decide to 
enable/disable in open/close or if it gets atomic clocks to 
enable/disable in atomic context.
- Atomic and sleep-able variants of clk_enable/disable/set_rate. I 
personally prefer the existing APIs to be sleep-able and introduce new 
atomic variants, but it's not worth the time arguing over that.

Taking one step at a time, do we all at least agree having two variants 
of enable/disable/set_rate?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 07:43:23PM -0800, Saravana Kannan wrote:
> On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
>> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>>> I would vote for all clk lookup and reference counting code be made
>>> sleep-able and define it as such.
>>
>> Always has been and probably always will be.
>>
>
> clk_enable/disable APIs have refcounting and they certainly aren't  
> sleep-able. I'm not sure if that's what Ben meant though.

Ben's talking about clk_get/clk_put.  See "clk lookup" in his sentence.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 07:43:23PM -0800, Saravana Kannan wrote:
> On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
>> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>>> I would vote for all clk lookup and reference counting code be made
>>> sleep-able and define it as such.
>>
>> Always has been and probably always will be.
>>
>
> clk_enable/disable APIs have refcounting and they certainly aren't  
> sleep-able. I'm not sure if that's what Ben meant though.

Ben's talking about clk_get/clk_put.  See "clk lookup" in his sentence.

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 07:43:23PM -0800, Saravana Kannan wrote:
> On 01/20/2011 10:57 AM, Russell King - ARM Linux wrote:
>> On Thu, Jan 20, 2011 at 04:32:44PM +0000, Ben Dooks wrote:
>>> I would vote for all clk lookup and reference counting code be made
>>> sleep-able and define it as such.
>>
>> Always has been and probably always will be.
>>
>
> clk_enable/disable APIs have refcounting and they certainly aren't  
> sleep-able. I'm not sure if that's what Ben meant though.

Ben's talking about clk_get/clk_put.  See "clk lookup" in his sentence.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
> In my opinion, the only major reason for needing atomic clk APIs was due  
> to device_ops->suspend being atomic. Since that's not the case anymore,  
> I really don't see a justification for atomic clocks. Sure, I might have  
> missed some exceptions, but in that case we should make the atomic APIs  
> an exception (add clk_enable_atomic) and not the norm.

The suspend method has never been atomic.  It has always been able to
sleep.  You're mistaken.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
> In my opinion, the only major reason for needing atomic clk APIs was due  
> to device_ops->suspend being atomic. Since that's not the case anymore,  
> I really don't see a justification for atomic clocks. Sure, I might have  
> missed some exceptions, but in that case we should make the atomic APIs  
> an exception (add clk_enable_atomic) and not the norm.

The suspend method has never been atomic.  It has always been able to
sleep.  You're mistaken.

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
> In my opinion, the only major reason for needing atomic clk APIs was due  
> to device_ops->suspend being atomic. Since that's not the case anymore,  
> I really don't see a justification for atomic clocks. Sure, I might have  
> missed some exceptions, but in that case we should make the atomic APIs  
> an exception (add clk_enable_atomic) and not the norm.

The suspend method has never been atomic.  It has always been able to
sleep.  You're mistaken.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console.  clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds.  We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep.  So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.

I guess we give up with the idea of unifying the API then, because it is
proving to be impossible to come to any kind of concensus.  Even ideas
to solve the points of contention are argued against.

I see no one else coming up with any practical ideas how to resolve this,
but what I do see is that attempts to provide a solution to allow progress
towards a unified API are shot down with great vigour.

So from what I can see it's a complete waste of time discussing this any
further.

Unified clock API?  It'll *never* happen.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console.  clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds.  We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep.  So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.

I guess we give up with the idea of unifying the API then, because it is
proving to be impossible to come to any kind of concensus.  Even ideas
to solve the points of contention are argued against.

I see no one else coming up with any practical ideas how to resolve this,
but what I do see is that attempts to provide a solution to allow progress
towards a unified API are shot down with great vigour.

So from what I can see it's a complete waste of time discussing this any
further.

Unified clock API?  It'll *never* happen.

Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console. ?clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds. ?We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep. ?So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.

I guess we give up with the idea of unifying the API then, because it is
proving to be impossible to come to any kind of concensus.  Even ideas
to solve the points of contention are argued against.

I see no one else coming up with any practical ideas how to resolve this,
but what I do see is that attempts to provide a solution to allow progress
towards a unified API are shot down with great vigour.

So from what I can see it's a complete waste of time discussing this any
further.

Unified clock API?  It'll *never* happen.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
> This suggestion looked promising till I realized that clk_set_rate()  
> will still be atomic. clk_set_rate() will need to enable/disable the  
> PLLs depending on which PLLs the rates are derived from. So, the locking  
> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"  
> is shared with clk_set_rate().

Who calls clk_set_rate() from an atomic context?  Do we know whether
anyone does?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
> This suggestion looked promising till I realized that clk_set_rate()  
> will still be atomic. clk_set_rate() will need to enable/disable the  
> PLLs depending on which PLLs the rates are derived from. So, the locking  
> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"  
> is shared with clk_set_rate().

Who calls clk_set_rate() from an atomic context?  Do we know whether
anyone does?

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
> This suggestion looked promising till I realized that clk_set_rate()  
> will still be atomic. clk_set_rate() will need to enable/disable the  
> PLLs depending on which PLLs the rates are derived from. So, the locking  
> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"  
> is shared with clk_set_rate().

Who calls clk_set_rate() from an atomic context?  Do we know whether
anyone does?

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 6:39 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console.  clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds.  We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep.  So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
>
> I guess we give up with the idea of unifying the API then, because it is
> proving to be impossible to come to any kind of concensus.  Even ideas
> to solve the points of contention are argued against.
>
> I see no one else coming up with any practical ideas how to resolve this,
> but what I do see is that attempts to provide a solution to allow progress
> towards a unified API are shot down with great vigour.
>
> So from what I can see it's a complete waste of time discussing this any
> further.
>
> Unified clock API?  It'll *never* happen.

Why can't we have that new function, clk_setup or whatever, a part of new API?
For now, it'll just be a place holder whit NULL as platform specific hooks.
Eventually platforms like Samsung will have that filled and others
keep that empty.
Only let it be defined for drivers to always call clk_setup at probe
and clk_enable when
needed.
Or am I overlooking something?

Re: Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 6:39 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console.  clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds.  We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep.  So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
>
> I guess we give up with the idea of unifying the API then, because it is
> proving to be impossible to come to any kind of concensus.  Even ideas
> to solve the points of contention are argued against.
>
> I see no one else coming up with any practical ideas how to resolve this,
> but what I do see is that attempts to provide a solution to allow progress
> towards a unified API are shot down with great vigour.
>
> So from what I can see it's a complete waste of time discussing this any
> further.
>
> Unified clock API?  It'll *never* happen.

Why can't we have that new function, clk_setup or whatever, a part of new API?
For now, it'll just be a place holder whit NULL as platform specific hooks.
Eventually platforms like Samsung will have that filled and others
keep that empty.
Only let it be defined for drivers to always call clk_setup at probe
and clk_enable when
needed.
Or am I overlooking something?

Locking in the clk API

[Jassi Brar]

On Fri, Jan 21, 2011 at 6:39 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console. ?clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds. ?We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep. ?So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
>
> I guess we give up with the idea of unifying the API then, because it is
> proving to be impossible to come to any kind of concensus. ?Even ideas
> to solve the points of contention are argued against.
>
> I see no one else coming up with any practical ideas how to resolve this,
> but what I do see is that attempts to provide a solution to allow progress
> towards a unified API are shot down with great vigour.
>
> So from what I can see it's a complete waste of time discussing this any
> further.
>
> Unified clock API? ?It'll *never* happen.

Why can't we have that new function, clk_setup or whatever, a part of new API?
For now, it'll just be a place holder whit NULL as platform specific hooks.
Eventually platforms like Samsung will have that filled and others
keep that empty.
Only let it be defined for drivers to always call clk_setup at probe
and clk_enable when
needed.
Or am I overlooking something?

Re: Locking in the clk API

[Dima Zavin]

On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/20/2011 06:06 PM, Dima Zavin wrote:
>> Here's a better one.
>>
>> Many devices use serial display panels sitting on either MDDI or MIPI
>> links. The interface clocks need to be on, but they stay in low-power
>> mode while the display is on. The display controller however does not
>> need to be on since the serial panels typically have a local
>> framebuffer that does the idle panel refresh on it's own. When a new
>> frame comes in to be displayed, you need to clock on the display
>> controller, DMA the data to the panel, and when it's done turn the
>> controller off. The clk_enable may or may not happen at irq context,
>> depending on whether or not you are starting the DMA from a
>> vsync/tear-effect irq or simply from the screen_update() function. The
>> clk_disable will most certainly happen from the DMA_DONE irq.
>
> Why do we need to turn on the clock in the IRQ? Why not defer it to a
> workqueue (or whatever is the method of the day to defer work from an IRQ)?
> The advantage of doing the clk_enable in the IRQ should be negligible
> compared to the time it takes to do the DMA.

Because in an interactive system running at 60fps, you only have 16ms
budget per frame. During the blanking interval when you receive the
IRQ you need to immediately start the DMA. If you defer to a workqueue
and schedule you are practically guaranteeing to never run at 60fps
(more like 30 if you are consistently late, which you would with that
kind of timing and even a mildly busy system).

--Dima

Re: Locking in the clk API

[Dima Zavin]

On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/20/2011 06:06 PM, Dima Zavin wrote:
>> Here's a better one.
>>
>> Many devices use serial display panels sitting on either MDDI or MIPI
>> links. The interface clocks need to be on, but they stay in low-power
>> mode while the display is on. The display controller however does not
>> need to be on since the serial panels typically have a local
>> framebuffer that does the idle panel refresh on it's own. When a new
>> frame comes in to be displayed, you need to clock on the display
>> controller, DMA the data to the panel, and when it's done turn the
>> controller off. The clk_enable may or may not happen at irq context,
>> depending on whether or not you are starting the DMA from a
>> vsync/tear-effect irq or simply from the screen_update() function. The
>> clk_disable will most certainly happen from the DMA_DONE irq.
>
> Why do we need to turn on the clock in the IRQ? Why not defer it to a
> workqueue (or whatever is the method of the day to defer work from an IRQ)?
> The advantage of doing the clk_enable in the IRQ should be negligible
> compared to the time it takes to do the DMA.

Because in an interactive system running at 60fps, you only have 16ms
budget per frame. During the blanking interval when you receive the
IRQ you need to immediately start the DMA. If you defer to a workqueue
and schedule you are practically guaranteeing to never run at 60fps
(more like 30 if you are consistently late, which you would with that
kind of timing and even a mildly busy system).

--Dima

Locking in the clk API

[Dima Zavin]

On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/20/2011 06:06 PM, Dima Zavin wrote:
>> Here's a better one.
>>
>> Many devices use serial display panels sitting on either MDDI or MIPI
>> links. The interface clocks need to be on, but they stay in low-power
>> mode while the display is on. The display controller however does not
>> need to be on since the serial panels typically have a local
>> framebuffer that does the idle panel refresh on it's own. When a new
>> frame comes in to be displayed, you need to clock on the display
>> controller, DMA the data to the panel, and when it's done turn the
>> controller off. The clk_enable may or may not happen at irq context,
>> depending on whether or not you are starting the DMA from a
>> vsync/tear-effect irq or simply from the screen_update() function. The
>> clk_disable will most certainly happen from the DMA_DONE irq.
>
> Why do we need to turn on the clock in the IRQ? Why not defer it to a
> workqueue (or whatever is the method of the day to defer work from an IRQ)?
> The advantage of doing the clk_enable in the IRQ should be negligible
> compared to the time it takes to do the DMA.

Because in an interactive system running at 60fps, you only have 16ms
budget per frame. During the blanking interval when you receive the
IRQ you need to immediately start the DMA. If you defer to a workqueue
and schedule you are practically guaranteeing to never run at 60fps
(more like 30 if you are consistently late, which you would with that
kind of timing and even a mildly busy system).

--Dima

Re: Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Dima Zavin wrote:

> On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> > On 01/20/2011 06:06 PM, Dima Zavin wrote:
> >> Here's a better one.
> >>
> >> Many devices use serial display panels sitting on either MDDI or MIPI
> >> links. The interface clocks need to be on, but they stay in low-power
> >> mode while the display is on. The display controller however does not
> >> need to be on since the serial panels typically have a local
> >> framebuffer that does the idle panel refresh on it's own. When a new
> >> frame comes in to be displayed, you need to clock on the display
> >> controller, DMA the data to the panel, and when it's done turn the
> >> controller off. The clk_enable may or may not happen at irq context,
> >> depending on whether or not you are starting the DMA from a
> >> vsync/tear-effect irq or simply from the screen_update() function. The
> >> clk_disable will most certainly happen from the DMA_DONE irq.
> >
> > Why do we need to turn on the clock in the IRQ? Why not defer it to a
> > workqueue (or whatever is the method of the day to defer work from an IRQ)?
> > The advantage of doing the clk_enable in the IRQ should be negligible
> > compared to the time it takes to do the DMA.
> 
> Because in an interactive system running at 60fps, you only have 16ms
> budget per frame. During the blanking interval when you receive the
> IRQ you need to immediately start the DMA. If you defer to a workqueue
> and schedule you are practically guaranteeing to never run at 60fps
> (more like 30 if you are consistently late, which you would with that
> kind of timing and even a mildly busy system).

And... is there really some advantage to turn the clock off in between 
frames when you're otherwise busy generating them anyway?

I think the fundamental problem with this clock API is that it tries to 
consolidate completely different usages behind the same set of 
interfaces, and that obviously fails.

Some people have clocks that are derived from slow-stabilizing PLLs and 
in that case you do want to use a sleeping API.  Obviously such clocks 
just can't be turned off and on between video frames while in interrupt 
context, hence for such clocks, the hypothetical clk_disable() call must 
do nothing.

So I think that the API must be augmented with more methods, such as:

clk_slow_enable():
  - may sleep
  - may be a no-op if the clk_fast_enable() is supported

clk_fast_enable():
  - may not sleep, used in atomic context
  - may be a no-op if controlling the clock takes time, in which case 
    clk_slow_enable() must have set the clock up entirely

... and similar for clk_slow_disable() and clk_fast_disable().

Then the driver must call clk_slow_enable() when in sleepable context, 
at worst after a successful probe, or better within the open method, or 
even better right before some processing request if possible.  The 
driver must also call clk_fast_enable() right before the hardware is 
kicked into motion.

Then, as soon as the IRQ from the hardware to indicate that the job is 
done is received, you call clk_fast_disable().  At that point you might 
awake a sleeping thread waiting for the resulting data.  In that thread, 
you then call clk_slow_disable() if possible, or from the driver's 
release() method otherwise.

So if you happen to have a fast-enabling clock, you make 
clk_slow_enable() a no op, and do everything in clk_fast_enable().  If 
your clock control sits on some I2C bus then you must do everything from 
clk_slow_enable() and make clk_fast_enable() a no op.  If you do have 
both a PLL and the ability to gate clock signals, then you just 
configure the PLL from clk_slow_enable() keeping the clock signal gated, 
and ungate it only from clk_fast_enable(), to gate it (and only 
gate it) with clk_fast_disable() so it can be quickly be ungated again 
with clk_fast_enable().

This way, the API has a chance of making drivers look generic, and the 
clock providers have more flexibility to hook into the API and optimize 
to the best they can do.

Of course that means that drivers must call both the slow and the fast 
methods eventually, each in their best place.  If a driver has no use 
for clk_fast_enable() then it should simply call it right after 
clk_slow_enable() returns (and a convenience macro could be provided for 
that case).


Nicolas

Re: Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Dima Zavin wrote:

> On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> > On 01/20/2011 06:06 PM, Dima Zavin wrote:
> >> Here's a better one.
> >>
> >> Many devices use serial display panels sitting on either MDDI or MIPI
> >> links. The interface clocks need to be on, but they stay in low-power
> >> mode while the display is on. The display controller however does not
> >> need to be on since the serial panels typically have a local
> >> framebuffer that does the idle panel refresh on it's own. When a new
> >> frame comes in to be displayed, you need to clock on the display
> >> controller, DMA the data to the panel, and when it's done turn the
> >> controller off. The clk_enable may or may not happen at irq context,
> >> depending on whether or not you are starting the DMA from a
> >> vsync/tear-effect irq or simply from the screen_update() function. The
> >> clk_disable will most certainly happen from the DMA_DONE irq.
> >
> > Why do we need to turn on the clock in the IRQ? Why not defer it to a
> > workqueue (or whatever is the method of the day to defer work from an IRQ)?
> > The advantage of doing the clk_enable in the IRQ should be negligible
> > compared to the time it takes to do the DMA.
> 
> Because in an interactive system running at 60fps, you only have 16ms
> budget per frame. During the blanking interval when you receive the
> IRQ you need to immediately start the DMA. If you defer to a workqueue
> and schedule you are practically guaranteeing to never run at 60fps
> (more like 30 if you are consistently late, which you would with that
> kind of timing and even a mildly busy system).

And... is there really some advantage to turn the clock off in between 
frames when you're otherwise busy generating them anyway?

I think the fundamental problem with this clock API is that it tries to 
consolidate completely different usages behind the same set of 
interfaces, and that obviously fails.

Some people have clocks that are derived from slow-stabilizing PLLs and 
in that case you do want to use a sleeping API.  Obviously such clocks 
just can't be turned off and on between video frames while in interrupt 
context, hence for such clocks, the hypothetical clk_disable() call must 
do nothing.

So I think that the API must be augmented with more methods, such as:

clk_slow_enable():
  - may sleep
  - may be a no-op if the clk_fast_enable() is supported

clk_fast_enable():
  - may not sleep, used in atomic context
  - may be a no-op if controlling the clock takes time, in which case 
    clk_slow_enable() must have set the clock up entirely

... and similar for clk_slow_disable() and clk_fast_disable().

Then the driver must call clk_slow_enable() when in sleepable context, 
at worst after a successful probe, or better within the open method, or 
even better right before some processing request if possible.  The 
driver must also call clk_fast_enable() right before the hardware is 
kicked into motion.

Then, as soon as the IRQ from the hardware to indicate that the job is 
done is received, you call clk_fast_disable().  At that point you might 
awake a sleeping thread waiting for the resulting data.  In that thread, 
you then call clk_slow_disable() if possible, or from the driver's 
release() method otherwise.

So if you happen to have a fast-enabling clock, you make 
clk_slow_enable() a no op, and do everything in clk_fast_enable().  If 
your clock control sits on some I2C bus then you must do everything from 
clk_slow_enable() and make clk_fast_enable() a no op.  If you do have 
both a PLL and the ability to gate clock signals, then you just 
configure the PLL from clk_slow_enable() keeping the clock signal gated, 
and ungate it only from clk_fast_enable(), to gate it (and only 
gate it) with clk_fast_disable() so it can be quickly be ungated again 
with clk_fast_enable().

This way, the API has a chance of making drivers look generic, and the 
clock providers have more flexibility to hook into the API and optimize 
to the best they can do.

Of course that means that drivers must call both the slow and the fast 
methods eventually, each in their best place.  If a driver has no use 
for clk_fast_enable() then it should simply call it right after 
clk_slow_enable() returns (and a convenience macro could be provided for 
that case).


Nicolas

Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Dima Zavin wrote:

> On Thu, Jan 20, 2011 at 8:12 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> > On 01/20/2011 06:06 PM, Dima Zavin wrote:
> >> Here's a better one.
> >>
> >> Many devices use serial display panels sitting on either MDDI or MIPI
> >> links. The interface clocks need to be on, but they stay in low-power
> >> mode while the display is on. The display controller however does not
> >> need to be on since the serial panels typically have a local
> >> framebuffer that does the idle panel refresh on it's own. When a new
> >> frame comes in to be displayed, you need to clock on the display
> >> controller, DMA the data to the panel, and when it's done turn the
> >> controller off. The clk_enable may or may not happen at irq context,
> >> depending on whether or not you are starting the DMA from a
> >> vsync/tear-effect irq or simply from the screen_update() function. The
> >> clk_disable will most certainly happen from the DMA_DONE irq.
> >
> > Why do we need to turn on the clock in the IRQ? Why not defer it to a
> > workqueue (or whatever is the method of the day to defer work from an IRQ)?
> > The advantage of doing the clk_enable in the IRQ should be negligible
> > compared to the time it takes to do the DMA.
> 
> Because in an interactive system running at 60fps, you only have 16ms
> budget per frame. During the blanking interval when you receive the
> IRQ you need to immediately start the DMA. If you defer to a workqueue
> and schedule you are practically guaranteeing to never run at 60fps
> (more like 30 if you are consistently late, which you would with that
> kind of timing and even a mildly busy system).

And... is there really some advantage to turn the clock off in between 
frames when you're otherwise busy generating them anyway?

I think the fundamental problem with this clock API is that it tries to 
consolidate completely different usages behind the same set of 
interfaces, and that obviously fails.

Some people have clocks that are derived from slow-stabilizing PLLs and 
in that case you do want to use a sleeping API.  Obviously such clocks 
just can't be turned off and on between video frames while in interrupt 
context, hence for such clocks, the hypothetical clk_disable() call must 
do nothing.

So I think that the API must be augmented with more methods, such as:

clk_slow_enable():
  - may sleep
  - may be a no-op if the clk_fast_enable() is supported

clk_fast_enable():
  - may not sleep, used in atomic context
  - may be a no-op if controlling the clock takes time, in which case 
    clk_slow_enable() must have set the clock up entirely

... and similar for clk_slow_disable() and clk_fast_disable().

Then the driver must call clk_slow_enable() when in sleepable context, 
at worst after a successful probe, or better within the open method, or 
even better right before some processing request if possible.  The 
driver must also call clk_fast_enable() right before the hardware is 
kicked into motion.

Then, as soon as the IRQ from the hardware to indicate that the job is 
done is received, you call clk_fast_disable().  At that point you might 
awake a sleeping thread waiting for the resulting data.  In that thread, 
you then call clk_slow_disable() if possible, or from the driver's 
release() method otherwise.

So if you happen to have a fast-enabling clock, you make 
clk_slow_enable() a no op, and do everything in clk_fast_enable().  If 
your clock control sits on some I2C bus then you must do everything from 
clk_slow_enable() and make clk_fast_enable() a no op.  If you do have 
both a PLL and the ability to gate clock signals, then you just 
configure the PLL from clk_slow_enable() keeping the clock signal gated, 
and ungate it only from clk_fast_enable(), to gate it (and only 
gate it) with clk_fast_disable() so it can be quickly be ungated again 
with clk_fast_enable().

This way, the API has a chance of making drivers look generic, and the 
clock providers have more flexibility to hook into the API and optimize 
to the best they can do.

Of course that means that drivers must call both the slow and the fast 
methods eventually, each in their best place.  If a driver has no use 
for clk_fast_enable() then it should simply call it right after 
clk_slow_enable() returns (and a convenience macro could be provided for 
that case).


Nicolas

Re: Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> So I think that the API must be augmented with more methods, such as:
> 
> clk_slow_enable():
>   - may sleep
>   - may be a no-op if the clk_fast_enable() is supported
> 
> clk_fast_enable():
>   - may not sleep, used in atomic context
>   - may be a no-op if controlling the clock takes time, in which case 
>     clk_slow_enable() must have set the clock up entirely
> 
> ... and similar for clk_slow_disable() and clk_fast_disable().

Isn't this along the same lines as my clk_prepare() vs clk_enable()
suggestion?

I suggested that clk_prepare() be callable only from non-atomic contexts,
and do whatever's required to ensure that the clock is available.  That
may end up enabling the clock as a result.

clk_enable() callable from atomic contexts, and turns the clock on if
the hardware supports such an operation.

So, if you have something like:

Xtal--->PLL--->Routing/Masking--->Device

clk = clk_get() returns the clock for the device.

clk_prepare(clk) would walk up the clock tree, selecting the routing and
preparing each clock.  Clocks prior to _and_ including the PLL would need
to be enabled.

clk_enable(clk) would walk up the tree if the clock isn't already enabled,
calling clk_enable() on the parent clock.  As we require prepared clocks
to already be enabled, this automatically stops at the PLL.

To encourage correct usage, we just need to make sure that clk_prepare()
has a might_sleep() thing, and clk_enable() throws a fit if it's used
on a clk without prepare being used first.  The second point is not easy
to do in a foolproof manner though, but doing _something_ is better than
nothing.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> So I think that the API must be augmented with more methods, such as:
> 
> clk_slow_enable():
>   - may sleep
>   - may be a no-op if the clk_fast_enable() is supported
> 
> clk_fast_enable():
>   - may not sleep, used in atomic context
>   - may be a no-op if controlling the clock takes time, in which case 
>     clk_slow_enable() must have set the clock up entirely
> 
> ... and similar for clk_slow_disable() and clk_fast_disable().

Isn't this along the same lines as my clk_prepare() vs clk_enable()
suggestion?

I suggested that clk_prepare() be callable only from non-atomic contexts,
and do whatever's required to ensure that the clock is available.  That
may end up enabling the clock as a result.

clk_enable() callable from atomic contexts, and turns the clock on if
the hardware supports such an operation.

So, if you have something like:

Xtal--->PLL--->Routing/Masking--->Device

clk = clk_get() returns the clock for the device.

clk_prepare(clk) would walk up the clock tree, selecting the routing and
preparing each clock.  Clocks prior to _and_ including the PLL would need
to be enabled.

clk_enable(clk) would walk up the tree if the clock isn't already enabled,
calling clk_enable() on the parent clock.  As we require prepared clocks
to already be enabled, this automatically stops at the PLL.

To encourage correct usage, we just need to make sure that clk_prepare()
has a might_sleep() thing, and clk_enable() throws a fit if it's used
on a clk without prepare being used first.  The second point is not easy
to do in a foolproof manner though, but doing _something_ is better than
nothing.

Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> So I think that the API must be augmented with more methods, such as:
> 
> clk_slow_enable():
>   - may sleep
>   - may be a no-op if the clk_fast_enable() is supported
> 
> clk_fast_enable():
>   - may not sleep, used in atomic context
>   - may be a no-op if controlling the clock takes time, in which case 
>     clk_slow_enable() must have set the clock up entirely
> 
> ... and similar for clk_slow_disable() and clk_fast_disable().

Isn't this along the same lines as my clk_prepare() vs clk_enable()
suggestion?

I suggested that clk_prepare() be callable only from non-atomic contexts,
and do whatever's required to ensure that the clock is available.  That
may end up enabling the clock as a result.

clk_enable() callable from atomic contexts, and turns the clock on if
the hardware supports such an operation.

So, if you have something like:

Xtal--->PLL--->Routing/Masking--->Device

clk = clk_get() returns the clock for the device.

clk_prepare(clk) would walk up the clock tree, selecting the routing and
preparing each clock.  Clocks prior to _and_ including the PLL would need
to be enabled.

clk_enable(clk) would walk up the tree if the clock isn't already enabled,
calling clk_enable() on the parent clock.  As we require prepared clocks
to already be enabled, this automatically stops at the PLL.

To encourage correct usage, we just need to make sure that clk_prepare()
has a might_sleep() thing, and clk_enable() throws a fit if it's used
on a clk without prepare being used first.  The second point is not easy
to do in a foolproof manner though, but doing _something_ is better than
nothing.

Re: Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>> So I think that the API must be augmented with more methods, such as:
>>
>> clk_slow_enable():
>>   - may sleep
>>   - may be a no-op if the clk_fast_enable() is supported
>>
>> clk_fast_enable():
>>   - may not sleep, used in atomic context
>>   - may be a no-op if controlling the clock takes time, in which case
>>     clk_slow_enable() must have set the clock up entirely
>>
>> ... and similar for clk_slow_disable() and clk_fast_disable().
>
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
>
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
>
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
>
> So, if you have something like:
>
> Xtal--->PLL--->Routing/Masking--->Device
>
> clk = clk_get() returns the clock for the device.
>
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
>
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
>
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

I like this proposal, and I prefer the clk_prepare naming over
clk_slow_enable - too many people would call clk_slow_enable instead
of, and not as well as, clk_fast_enable.

On Tegra, I currently use the ugly conditional mutex or spinlock
method to deal with voltage scaling based on clock frequency.  Clocks
that have a voltage dependency, or depend on a clock that has a
voltage dependency, are non-atomic, everything else is atomic.  PLLs
are atomic because they lock very fast (300 uS or 1ms) and are shared
by so many clocks that they realistically don't get turned off very
often, and if I made them non-atomic, all clocks would be non-atomic.

If clk_prepare, clk_unprepare, and clk_set_rate were only callable in
sleepable contexts, I could make PLLs and voltage-dependent clocks
sleepable, but allow atomic clocks to depend on them.  Calling
clk_prepare on a voltage-dependent clock would bump the voltage up if
necessary, but not enable the clock.  Drivers that don't need atomic
clocks can call clk_prepare and clk_enable when they want the clock
on, keeping the same power savings as my current implementation.

Converting all the existing clk API users could be hard, but with a
little trickery backwards compatibility with the previous API could
also be maintained.  clk_enable could call clk_prepare if it hasn't
been called, with a WARN_ON_ONCE to find drivers that need to be
fixed, and the last clk_disable could call clk_unprepare.  For systems
where all clocks are atomic, everything would continue to work.

Re: Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>> So I think that the API must be augmented with more methods, such as:
>>
>> clk_slow_enable():
>>   - may sleep
>>   - may be a no-op if the clk_fast_enable() is supported
>>
>> clk_fast_enable():
>>   - may not sleep, used in atomic context
>>   - may be a no-op if controlling the clock takes time, in which case
>>     clk_slow_enable() must have set the clock up entirely
>>
>> ... and similar for clk_slow_disable() and clk_fast_disable().
>
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
>
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
>
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
>
> So, if you have something like:
>
> Xtal--->PLL--->Routing/Masking--->Device
>
> clk = clk_get() returns the clock for the device.
>
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
>
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
>
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

I like this proposal, and I prefer the clk_prepare naming over
clk_slow_enable - too many people would call clk_slow_enable instead
of, and not as well as, clk_fast_enable.

On Tegra, I currently use the ugly conditional mutex or spinlock
method to deal with voltage scaling based on clock frequency.  Clocks
that have a voltage dependency, or depend on a clock that has a
voltage dependency, are non-atomic, everything else is atomic.  PLLs
are atomic because they lock very fast (300 uS or 1ms) and are shared
by so many clocks that they realistically don't get turned off very
often, and if I made them non-atomic, all clocks would be non-atomic.

If clk_prepare, clk_unprepare, and clk_set_rate were only callable in
sleepable contexts, I could make PLLs and voltage-dependent clocks
sleepable, but allow atomic clocks to depend on them.  Calling
clk_prepare on a voltage-dependent clock would bump the voltage up if
necessary, but not enable the clock.  Drivers that don't need atomic
clocks can call clk_prepare and clk_enable when they want the clock
on, keeping the same power savings as my current implementation.

Converting all the existing clk API users could be hard, but with a
little trickery backwards compatibility with the previous API could
also be maintained.  clk_enable could call clk_prepare if it hasn't
been called, with a WARN_ON_ONCE to find drivers that need to be
fixed, and the last clk_disable could call clk_unprepare.  For systems
where all clocks are atomic, everything would continue to work.

Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>> So I think that the API must be augmented with more methods, such as:
>>
>> clk_slow_enable():
>> ? - may sleep
>> ? - may be a no-op if the clk_fast_enable() is supported
>>
>> clk_fast_enable():
>> ? - may not sleep, used in atomic context
>> ? - may be a no-op if controlling the clock takes time, in which case
>> ? ? clk_slow_enable() must have set the clock up entirely
>>
>> ... and similar for clk_slow_disable() and clk_fast_disable().
>
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
>
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available. ?That
> may end up enabling the clock as a result.
>
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
>
> So, if you have something like:
>
> Xtal--->PLL--->Routing/Masking--->Device
>
> clk = clk_get() returns the clock for the device.
>
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock. ?Clocks prior to _and_ including the PLL would need
> to be enabled.
>
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock. ?As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
>
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first. ?The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

I like this proposal, and I prefer the clk_prepare naming over
clk_slow_enable - too many people would call clk_slow_enable instead
of, and not as well as, clk_fast_enable.

On Tegra, I currently use the ugly conditional mutex or spinlock
method to deal with voltage scaling based on clock frequency.  Clocks
that have a voltage dependency, or depend on a clock that has a
voltage dependency, are non-atomic, everything else is atomic.  PLLs
are atomic because they lock very fast (300 uS or 1ms) and are shared
by so many clocks that they realistically don't get turned off very
often, and if I made them non-atomic, all clocks would be non-atomic.

If clk_prepare, clk_unprepare, and clk_set_rate were only callable in
sleepable contexts, I could make PLLs and voltage-dependent clocks
sleepable, but allow atomic clocks to depend on them.  Calling
clk_prepare on a voltage-dependent clock would bump the voltage up if
necessary, but not enable the clock.  Drivers that don't need atomic
clocks can call clk_prepare and clk_enable when they want the clock
on, keeping the same power savings as my current implementation.

Converting all the existing clk API users could be hard, but with a
little trickery backwards compatibility with the previous API could
also be maintained.  clk_enable could call clk_prepare if it hasn't
been called, with a WARN_ON_ONCE to find drivers that need to be
fixed, and the last clk_disable could call clk_unprepare.  For systems
where all clocks are atomic, everything would continue to work.

Re: Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> > So I think that the API must be augmented with more methods, such as:
> > 
> > clk_slow_enable():
> >   - may sleep
> >   - may be a no-op if the clk_fast_enable() is supported
> > 
> > clk_fast_enable():
> >   - may not sleep, used in atomic context
> >   - may be a no-op if controlling the clock takes time, in which case 
> >     clk_slow_enable() must have set the clock up entirely
> > 
> > ... and similar for clk_slow_disable() and clk_fast_disable().
> 
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
> 
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
> 
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
> 
> So, if you have something like:
> 
> Xtal--->PLL--->Routing/Masking--->Device
> 
> clk = clk_get() returns the clock for the device.
> 
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
> 
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
> 
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

Exactly.  That model does cover both situations: i.e. clocks with slow 
setups which need to sleep, and clocks with fast setups that can be 
dealt with and taken advantage of within atomic context.  And in some 
cases there is even a mixture of both involved.


Nicolas

Re: Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> > So I think that the API must be augmented with more methods, such as:
> > 
> > clk_slow_enable():
> >   - may sleep
> >   - may be a no-op if the clk_fast_enable() is supported
> > 
> > clk_fast_enable():
> >   - may not sleep, used in atomic context
> >   - may be a no-op if controlling the clock takes time, in which case 
> >     clk_slow_enable() must have set the clock up entirely
> > 
> > ... and similar for clk_slow_disable() and clk_fast_disable().
> 
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
> 
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
> 
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
> 
> So, if you have something like:
> 
> Xtal--->PLL--->Routing/Masking--->Device
> 
> clk = clk_get() returns the clock for the device.
> 
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
> 
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
> 
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

Exactly.  That model does cover both situations: i.e. clocks with slow 
setups which need to sleep, and clocks with fast setups that can be 
dealt with and taken advantage of within atomic context.  And in some 
cases there is even a mixture of both involved.


Nicolas

Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Russell King - ARM Linux wrote:

> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> > So I think that the API must be augmented with more methods, such as:
> > 
> > clk_slow_enable():
> >   - may sleep
> >   - may be a no-op if the clk_fast_enable() is supported
> > 
> > clk_fast_enable():
> >   - may not sleep, used in atomic context
> >   - may be a no-op if controlling the clock takes time, in which case 
> >     clk_slow_enable() must have set the clock up entirely
> > 
> > ... and similar for clk_slow_disable() and clk_fast_disable().
> 
> Isn't this along the same lines as my clk_prepare() vs clk_enable()
> suggestion?
> 
> I suggested that clk_prepare() be callable only from non-atomic contexts,
> and do whatever's required to ensure that the clock is available.  That
> may end up enabling the clock as a result.
> 
> clk_enable() callable from atomic contexts, and turns the clock on if
> the hardware supports such an operation.
> 
> So, if you have something like:
> 
> Xtal--->PLL--->Routing/Masking--->Device
> 
> clk = clk_get() returns the clock for the device.
> 
> clk_prepare(clk) would walk up the clock tree, selecting the routing and
> preparing each clock.  Clocks prior to _and_ including the PLL would need
> to be enabled.
> 
> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> calling clk_enable() on the parent clock.  As we require prepared clocks
> to already be enabled, this automatically stops at the PLL.
> 
> To encourage correct usage, we just need to make sure that clk_prepare()
> has a might_sleep() thing, and clk_enable() throws a fit if it's used
> on a clk without prepare being used first.  The second point is not easy
> to do in a foolproof manner though, but doing _something_ is better than
> nothing.

Exactly.  That model does cover both situations: i.e. clocks with slow 
setups which need to sleep, and clocks with fast setups that can be 
dealt with and taken advantage of within atomic context.  And in some 
cases there is even a mixture of both involved.


Nicolas

Re: Locking in the clk API

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 14:28 -0800, Colin Cross wrote:
> Clocks that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) 

Some could argue that this is still way too slow for atomic context :-)

Cheers,
Ben.

Re: Locking in the clk API

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 14:28 -0800, Colin Cross wrote:
> Clocks that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) 

Some could argue that this is still way too slow for atomic context :-)

Cheers,
Ben.

Locking in the clk API

[Benjamin Herrenschmidt]

On Fri, 2011-01-21 at 14:28 -0800, Colin Cross wrote:
> Clocks that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) 

Some could argue that this is still way too slow for atomic context :-)

Cheers,
Ben.

Re: Locking in the clk API

[Bryan Huntsman]

On 01/21/2011 01:53 PM, Nicolas Pitre wrote:
...
> And... is there really some advantage to turn the clock off in between 
> frames when you're otherwise busy generating them anyway?

For aggressive power management where supported by HW, yes.

- Bryan

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Bryan Huntsman]

On 01/21/2011 01:53 PM, Nicolas Pitre wrote:
...
> And... is there really some advantage to turn the clock off in between 
> frames when you're otherwise busy generating them anyway?

For aggressive power management where supported by HW, yes.

- Bryan

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Bryan Huntsman]

On 01/21/2011 01:53 PM, Nicolas Pitre wrote:
...
> And... is there really some advantage to turn the clock off in between 
> frames when you're otherwise busy generating them anyway?

For aggressive power management where supported by HW, yes.

- Bryan

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3348 bytes --]

On Fri, 21 Jan 2011, Colin Cross wrote:

> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> >> So I think that the API must be augmented with more methods, such as:
> >>
> >> clk_slow_enable():
> >>   - may sleep
> >>   - may be a no-op if the clk_fast_enable() is supported
> >>
> >> clk_fast_enable():
> >>   - may not sleep, used in atomic context
> >>   - may be a no-op if controlling the clock takes time, in which case
> >>     clk_slow_enable() must have set the clock up entirely
> >>
> >> ... and similar for clk_slow_disable() and clk_fast_disable().
> >
> > Isn't this along the same lines as my clk_prepare() vs clk_enable()
> > suggestion?
> >
> > I suggested that clk_prepare() be callable only from non-atomic contexts,
> > and do whatever's required to ensure that the clock is available.  That
> > may end up enabling the clock as a result.
> >
> > clk_enable() callable from atomic contexts, and turns the clock on if
> > the hardware supports such an operation.
> >
> > So, if you have something like:
> >
> > Xtal--->PLL--->Routing/Masking--->Device
> >
> > clk = clk_get() returns the clock for the device.
> >
> > clk_prepare(clk) would walk up the clock tree, selecting the routing and
> > preparing each clock.  Clocks prior to _and_ including the PLL would need
> > to be enabled.
> >
> > clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> > calling clk_enable() on the parent clock.  As we require prepared clocks
> > to already be enabled, this automatically stops at the PLL.
> >
> > To encourage correct usage, we just need to make sure that clk_prepare()
> > has a might_sleep() thing, and clk_enable() throws a fit if it's used
> > on a clk without prepare being used first.  The second point is not easy
> > to do in a foolproof manner though, but doing _something_ is better than
> > nothing.
> 
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.

I do prefer those names too.  My clk_slow/fast_enable() was just an 
example for illustration purpose.

> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.  Clocks
> that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) and are shared
> by so many clocks that they realistically don't get turned off very
> often, and if I made them non-atomic, all clocks would be non-atomic.

That's of course implementation details.  The API should define purpose, 
and then you get to decide how your hardware will behave.  If you 
consider that 300us is short enough to busy wait for, and that the 
likelyhood for that PLL to be disabled is low, then you can make it into 
the clk_enable() and make clk_prepare() empty.  But if you are going to 
use a driver with aggressive power saving through frequent usage of 
clk_enable()/clk_disable() then it is probably best to lock the PLLs in 
clk_prepare() instead.


Nicolas

Re: Locking in the clk API

[Nicolas Pitre]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3274 bytes --]

On Fri, 21 Jan 2011, Colin Cross wrote:

> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> >> So I think that the API must be augmented with more methods, such as:
> >>
> >> clk_slow_enable():
> >>   - may sleep
> >>   - may be a no-op if the clk_fast_enable() is supported
> >>
> >> clk_fast_enable():
> >>   - may not sleep, used in atomic context
> >>   - may be a no-op if controlling the clock takes time, in which case
> >>     clk_slow_enable() must have set the clock up entirely
> >>
> >> ... and similar for clk_slow_disable() and clk_fast_disable().
> >
> > Isn't this along the same lines as my clk_prepare() vs clk_enable()
> > suggestion?
> >
> > I suggested that clk_prepare() be callable only from non-atomic contexts,
> > and do whatever's required to ensure that the clock is available.  That
> > may end up enabling the clock as a result.
> >
> > clk_enable() callable from atomic contexts, and turns the clock on if
> > the hardware supports such an operation.
> >
> > So, if you have something like:
> >
> > Xtal--->PLL--->Routing/Masking--->Device
> >
> > clk = clk_get() returns the clock for the device.
> >
> > clk_prepare(clk) would walk up the clock tree, selecting the routing and
> > preparing each clock.  Clocks prior to _and_ including the PLL would need
> > to be enabled.
> >
> > clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> > calling clk_enable() on the parent clock.  As we require prepared clocks
> > to already be enabled, this automatically stops at the PLL.
> >
> > To encourage correct usage, we just need to make sure that clk_prepare()
> > has a might_sleep() thing, and clk_enable() throws a fit if it's used
> > on a clk without prepare being used first.  The second point is not easy
> > to do in a foolproof manner though, but doing _something_ is better than
> > nothing.
> 
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.

I do prefer those names too.  My clk_slow/fast_enable() was just an 
example for illustration purpose.

> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.  Clocks
> that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) and are shared
> by so many clocks that they realistically don't get turned off very
> often, and if I made them non-atomic, all clocks would be non-atomic.

That's of course implementation details.  The API should define purpose, 
and then you get to decide how your hardware will behave.  If you 
consider that 300us is short enough to busy wait for, and that the 
likelyhood for that PLL to be disabled is low, then you can make it into 
the clk_enable() and make clk_prepare() empty.  But if you are going to 
use a driver with aggressive power saving through frequent usage of 
clk_enable()/clk_disable() then it is probably best to lock the PLLs in 
clk_prepare() instead.


Nicolas

Locking in the clk API

[Nicolas Pitre]

On Fri, 21 Jan 2011, Colin Cross wrote:

> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
> >> So I think that the API must be augmented with more methods, such as:
> >>
> >> clk_slow_enable():
> >> ? - may sleep
> >> ? - may be a no-op if the clk_fast_enable() is supported
> >>
> >> clk_fast_enable():
> >> ? - may not sleep, used in atomic context
> >> ? - may be a no-op if controlling the clock takes time, in which case
> >> ? ? clk_slow_enable() must have set the clock up entirely
> >>
> >> ... and similar for clk_slow_disable() and clk_fast_disable().
> >
> > Isn't this along the same lines as my clk_prepare() vs clk_enable()
> > suggestion?
> >
> > I suggested that clk_prepare() be callable only from non-atomic contexts,
> > and do whatever's required to ensure that the clock is available. ?That
> > may end up enabling the clock as a result.
> >
> > clk_enable() callable from atomic contexts, and turns the clock on if
> > the hardware supports such an operation.
> >
> > So, if you have something like:
> >
> > Xtal--->PLL--->Routing/Masking--->Device
> >
> > clk = clk_get() returns the clock for the device.
> >
> > clk_prepare(clk) would walk up the clock tree, selecting the routing and
> > preparing each clock. ?Clocks prior to _and_ including the PLL would need
> > to be enabled.
> >
> > clk_enable(clk) would walk up the tree if the clock isn't already enabled,
> > calling clk_enable() on the parent clock. ?As we require prepared clocks
> > to already be enabled, this automatically stops at the PLL.
> >
> > To encourage correct usage, we just need to make sure that clk_prepare()
> > has a might_sleep() thing, and clk_enable() throws a fit if it's used
> > on a clk without prepare being used first. ?The second point is not easy
> > to do in a foolproof manner though, but doing _something_ is better than
> > nothing.
> 
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.

I do prefer those names too.  My clk_slow/fast_enable() was just an 
example for illustration purpose.

> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.  Clocks
> that have a voltage dependency, or depend on a clock that has a
> voltage dependency, are non-atomic, everything else is atomic.  PLLs
> are atomic because they lock very fast (300 uS or 1ms) and are shared
> by so many clocks that they realistically don't get turned off very
> often, and if I made them non-atomic, all clocks would be non-atomic.

That's of course implementation details.  The API should define purpose, 
and then you get to decide how your hardware will behave.  If you 
consider that 300us is short enough to busy wait for, and that the 
likelyhood for that PLL to be disabled is low, then you can make it into 
the clk_enable() and make clk_prepare() empty.  But if you are going to 
use a driver with aggressive power saving through frequent usage of 
clk_enable()/clk_disable() then it is probably best to lock the PLLs in 
clk_prepare() instead.


Nicolas

Re: Locking in the clk API

[Saravana Kannan]

On 01/21/2011 02:28 PM, Colin Cross wrote:
> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk>  wrote:
>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>> So I think that the API must be augmented with more methods, such as:
>>>
>>> clk_slow_enable():
>>>    - may sleep
>>>    - may be a no-op if the clk_fast_enable() is supported
>>>
>>> clk_fast_enable():
>>>    - may not sleep, used in atomic context
>>>    - may be a no-op if controlling the clock takes time, in which case
>>>      clk_slow_enable() must have set the clock up entirely
>>>
>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>
>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>> suggestion?
>>
>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>> and do whatever's required to ensure that the clock is available.  That
>> may end up enabling the clock as a result.
>>
>> clk_enable() callable from atomic contexts, and turns the clock on if
>> the hardware supports such an operation.
>>
>> So, if you have something like:
>>
>> Xtal--->PLL--->Routing/Masking--->Device
>>
>> clk = clk_get() returns the clock for the device.
>>
>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>> preparing each clock.  Clocks prior to _and_ including the PLL would need
>> to be enabled.
>>
>> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
>> calling clk_enable() on the parent clock.  As we require prepared clocks
>> to already be enabled, this automatically stops at the PLL.
>>
>> To encourage correct usage, we just need to make sure that clk_prepare()
>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>> on a clk without prepare being used first.  The second point is not easy
>> to do in a foolproof manner though, but doing _something_ is better than
>> nothing.
>
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.
>
> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.

Colin,

MSM is in a similar situation, so thought I should bring this up to you 
attention -- do you have no use case for changing the rate in atomic 
context? If you do, the clk_prepare/unprepare() approach won't work.

Do you have no such requirement?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/21/2011 02:28 PM, Colin Cross wrote:
> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk>  wrote:
>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>> So I think that the API must be augmented with more methods, such as:
>>>
>>> clk_slow_enable():
>>>    - may sleep
>>>    - may be a no-op if the clk_fast_enable() is supported
>>>
>>> clk_fast_enable():
>>>    - may not sleep, used in atomic context
>>>    - may be a no-op if controlling the clock takes time, in which case
>>>      clk_slow_enable() must have set the clock up entirely
>>>
>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>
>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>> suggestion?
>>
>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>> and do whatever's required to ensure that the clock is available.  That
>> may end up enabling the clock as a result.
>>
>> clk_enable() callable from atomic contexts, and turns the clock on if
>> the hardware supports such an operation.
>>
>> So, if you have something like:
>>
>> Xtal--->PLL--->Routing/Masking--->Device
>>
>> clk = clk_get() returns the clock for the device.
>>
>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>> preparing each clock.  Clocks prior to _and_ including the PLL would need
>> to be enabled.
>>
>> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
>> calling clk_enable() on the parent clock.  As we require prepared clocks
>> to already be enabled, this automatically stops at the PLL.
>>
>> To encourage correct usage, we just need to make sure that clk_prepare()
>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>> on a clk without prepare being used first.  The second point is not easy
>> to do in a foolproof manner though, but doing _something_ is better than
>> nothing.
>
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.
>
> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.

Colin,

MSM is in a similar situation, so thought I should bring this up to you 
attention -- do you have no use case for changing the rate in atomic 
context? If you do, the clk_prepare/unprepare() approach won't work.

Do you have no such requirement?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/21/2011 02:28 PM, Colin Cross wrote:
> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk>  wrote:
>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>> So I think that the API must be augmented with more methods, such as:
>>>
>>> clk_slow_enable():
>>>    - may sleep
>>>    - may be a no-op if the clk_fast_enable() is supported
>>>
>>> clk_fast_enable():
>>>    - may not sleep, used in atomic context
>>>    - may be a no-op if controlling the clock takes time, in which case
>>>      clk_slow_enable() must have set the clock up entirely
>>>
>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>
>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>> suggestion?
>>
>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>> and do whatever's required to ensure that the clock is available.  That
>> may end up enabling the clock as a result.
>>
>> clk_enable() callable from atomic contexts, and turns the clock on if
>> the hardware supports such an operation.
>>
>> So, if you have something like:
>>
>> Xtal--->PLL--->Routing/Masking--->Device
>>
>> clk = clk_get() returns the clock for the device.
>>
>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>> preparing each clock.  Clocks prior to _and_ including the PLL would need
>> to be enabled.
>>
>> clk_enable(clk) would walk up the tree if the clock isn't already enabled,
>> calling clk_enable() on the parent clock.  As we require prepared clocks
>> to already be enabled, this automatically stops at the PLL.
>>
>> To encourage correct usage, we just need to make sure that clk_prepare()
>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>> on a clk without prepare being used first.  The second point is not easy
>> to do in a foolproof manner though, but doing _something_ is better than
>> nothing.
>
> I like this proposal, and I prefer the clk_prepare naming over
> clk_slow_enable - too many people would call clk_slow_enable instead
> of, and not as well as, clk_fast_enable.
>
> On Tegra, I currently use the ugly conditional mutex or spinlock
> method to deal with voltage scaling based on clock frequency.

Colin,

MSM is in a similar situation, so thought I should bring this up to you 
attention -- do you have no use case for changing the rate in atomic 
context? If you do, the clk_prepare/unprepare() approach won't work.

Do you have no such requirement?

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/21/2011 01:40 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
>> This suggestion looked promising till I realized that clk_set_rate()
>> will still be atomic. clk_set_rate() will need to enable/disable the
>> PLLs depending on which PLLs the rates are derived from. So, the locking
>> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"
>> is shared with clk_set_rate().
>
> Who calls clk_set_rate() from an atomic context?  Do we know whether
> anyone does?

I have had internal teams asking about it. I will try to check if they 
mainlined any of it yet or continue to want to do that in atomic context 
and get back.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
>> In my opinion, the only major reason for needing atomic clk APIs was due
>> to device_ops->suspend being atomic. Since that's not the case anymore,
>> I really don't see a justification for atomic clocks. Sure, I might have
>> missed some exceptions, but in that case we should make the atomic APIs
>> an exception (add clk_enable_atomic) and not the norm.
>
> The suspend method has never been atomic.  It has always been able to
> sleep.  You're mistaken.

I distinctly remember trying to do sleeping stuff inside a .suspend 
function and have it complain that it's atomic. So, I think you might be 
mistaken. But I will have to back up my claims. Let me trying to find 
that info. In the end, one of us will learn something new -- which is 
good and all that matters.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 5:35 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/21/2011 02:28 PM, Colin Cross wrote:
>>
>> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk>  wrote:
>>>
>>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>>>
>>>> So I think that the API must be augmented with more methods, such as:
>>>>
>>>> clk_slow_enable():
>>>>   - may sleep
>>>>   - may be a no-op if the clk_fast_enable() is supported
>>>>
>>>> clk_fast_enable():
>>>>   - may not sleep, used in atomic context
>>>>   - may be a no-op if controlling the clock takes time, in which case
>>>>     clk_slow_enable() must have set the clock up entirely
>>>>
>>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>>
>>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>>> suggestion?
>>>
>>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>>> and do whatever's required to ensure that the clock is available.  That
>>> may end up enabling the clock as a result.
>>>
>>> clk_enable() callable from atomic contexts, and turns the clock on if
>>> the hardware supports such an operation.
>>>
>>> So, if you have something like:
>>>
>>> Xtal--->PLL--->Routing/Masking--->Device
>>>
>>> clk = clk_get() returns the clock for the device.
>>>
>>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>>> preparing each clock.  Clocks prior to _and_ including the PLL would need
>>> to be enabled.
>>>
>>> clk_enable(clk) would walk up the tree if the clock isn't already
>>> enabled,
>>> calling clk_enable() on the parent clock.  As we require prepared clocks
>>> to already be enabled, this automatically stops at the PLL.
>>>
>>> To encourage correct usage, we just need to make sure that clk_prepare()
>>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>>> on a clk without prepare being used first.  The second point is not easy
>>> to do in a foolproof manner though, but doing _something_ is better than
>>> nothing.
>>
>> I like this proposal, and I prefer the clk_prepare naming over
>> clk_slow_enable - too many people would call clk_slow_enable instead
>> of, and not as well as, clk_fast_enable.
>>
>> On Tegra, I currently use the ugly conditional mutex or spinlock
>> method to deal with voltage scaling based on clock frequency.
>
> Colin,
>
> MSM is in a similar situation, so thought I should bring this up to you
> attention -- do you have no use case for changing the rate in atomic
> context? If you do, the clk_prepare/unprepare() approach won't work.
>
> Do you have no such requirement?

I can't think of any case that requires clk_set_rate in atomic
context.  We usually only scale frequencies to save power, so we can
always scale up early in sleepable context for a minor power penalty.

Re: Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 5:35 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/21/2011 02:28 PM, Colin Cross wrote:
>>
>> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk>  wrote:
>>>
>>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>>>
>>>> So I think that the API must be augmented with more methods, such as:
>>>>
>>>> clk_slow_enable():
>>>>   - may sleep
>>>>   - may be a no-op if the clk_fast_enable() is supported
>>>>
>>>> clk_fast_enable():
>>>>   - may not sleep, used in atomic context
>>>>   - may be a no-op if controlling the clock takes time, in which case
>>>>     clk_slow_enable() must have set the clock up entirely
>>>>
>>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>>
>>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>>> suggestion?
>>>
>>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>>> and do whatever's required to ensure that the clock is available.  That
>>> may end up enabling the clock as a result.
>>>
>>> clk_enable() callable from atomic contexts, and turns the clock on if
>>> the hardware supports such an operation.
>>>
>>> So, if you have something like:
>>>
>>> Xtal--->PLL--->Routing/Masking--->Device
>>>
>>> clk = clk_get() returns the clock for the device.
>>>
>>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>>> preparing each clock.  Clocks prior to _and_ including the PLL would need
>>> to be enabled.
>>>
>>> clk_enable(clk) would walk up the tree if the clock isn't already
>>> enabled,
>>> calling clk_enable() on the parent clock.  As we require prepared clocks
>>> to already be enabled, this automatically stops at the PLL.
>>>
>>> To encourage correct usage, we just need to make sure that clk_prepare()
>>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>>> on a clk without prepare being used first.  The second point is not easy
>>> to do in a foolproof manner though, but doing _something_ is better than
>>> nothing.
>>
>> I like this proposal, and I prefer the clk_prepare naming over
>> clk_slow_enable - too many people would call clk_slow_enable instead
>> of, and not as well as, clk_fast_enable.
>>
>> On Tegra, I currently use the ugly conditional mutex or spinlock
>> method to deal with voltage scaling based on clock frequency.
>
> Colin,
>
> MSM is in a similar situation, so thought I should bring this up to you
> attention -- do you have no use case for changing the rate in atomic
> context? If you do, the clk_prepare/unprepare() approach won't work.
>
> Do you have no such requirement?

I can't think of any case that requires clk_set_rate in atomic
context.  We usually only scale frequencies to save power, so we can
always scale up early in sleepable context for a minor power penalty.

Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 5:35 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/21/2011 02:28 PM, Colin Cross wrote:
>>
>> On Fri, Jan 21, 2011 at 2:02 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> ?wrote:
>>>
>>> On Fri, Jan 21, 2011 at 04:53:44PM -0500, Nicolas Pitre wrote:
>>>>
>>>> So I think that the API must be augmented with more methods, such as:
>>>>
>>>> clk_slow_enable():
>>>> ? - may sleep
>>>> ? - may be a no-op if the clk_fast_enable() is supported
>>>>
>>>> clk_fast_enable():
>>>> ? - may not sleep, used in atomic context
>>>> ? - may be a no-op if controlling the clock takes time, in which case
>>>> ? ? clk_slow_enable() must have set the clock up entirely
>>>>
>>>> ... and similar for clk_slow_disable() and clk_fast_disable().
>>>
>>> Isn't this along the same lines as my clk_prepare() vs clk_enable()
>>> suggestion?
>>>
>>> I suggested that clk_prepare() be callable only from non-atomic contexts,
>>> and do whatever's required to ensure that the clock is available. ?That
>>> may end up enabling the clock as a result.
>>>
>>> clk_enable() callable from atomic contexts, and turns the clock on if
>>> the hardware supports such an operation.
>>>
>>> So, if you have something like:
>>>
>>> Xtal--->PLL--->Routing/Masking--->Device
>>>
>>> clk = clk_get() returns the clock for the device.
>>>
>>> clk_prepare(clk) would walk up the clock tree, selecting the routing and
>>> preparing each clock. ?Clocks prior to _and_ including the PLL would need
>>> to be enabled.
>>>
>>> clk_enable(clk) would walk up the tree if the clock isn't already
>>> enabled,
>>> calling clk_enable() on the parent clock. ?As we require prepared clocks
>>> to already be enabled, this automatically stops at the PLL.
>>>
>>> To encourage correct usage, we just need to make sure that clk_prepare()
>>> has a might_sleep() thing, and clk_enable() throws a fit if it's used
>>> on a clk without prepare being used first. ?The second point is not easy
>>> to do in a foolproof manner though, but doing _something_ is better than
>>> nothing.
>>
>> I like this proposal, and I prefer the clk_prepare naming over
>> clk_slow_enable - too many people would call clk_slow_enable instead
>> of, and not as well as, clk_fast_enable.
>>
>> On Tegra, I currently use the ugly conditional mutex or spinlock
>> method to deal with voltage scaling based on clock frequency.
>
> Colin,
>
> MSM is in a similar situation, so thought I should bring this up to you
> attention -- do you have no use case for changing the rate in atomic
> context? If you do, the clk_prepare/unprepare() approach won't work.
>
> Do you have no such requirement?

I can't think of any case that requires clk_set_rate in atomic
context.  We usually only scale frequencies to save power, so we can
always scale up early in sleepable context for a minor power penalty.

Locking in the clk API

[Colin Cross]

On Fri, Jan 21, 2011 at 5:53 PM, Saravana Kannan <skannan@codeaurora.org> wrote:
> On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:
>>
>> On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
>>>
>>> In my opinion, the only major reason for needing atomic clk APIs was due
>>> to device_ops->suspend being atomic. Since that's not the case anymore,
>>> I really don't see a justification for atomic clocks. Sure, I might have
>>> missed some exceptions, but in that case we should make the atomic APIs
>>> an exception (add clk_enable_atomic) and not the norm.
>>
>> The suspend method has never been atomic. ?It has always been able to
>> sleep. ?You're mistaken.
>
> I distinctly remember trying to do sleeping stuff inside a .suspend function
> and have it complain that it's atomic. So, I think you might be mistaken.
> But I will have to back up my claims. Let me trying to find that info. In
> the end, one of us will learn something new -- which is good and all that
> matters.

platform_driver->suspend and dev_pm_ops->suspend can sleep, but
dev_pm_ops->suspend_noirq is called after irqs are disabled and can't
sleep.  Maybe that's what you were using?

Locking in the clk API

[Saravana Kannan]

On 01/21/2011 06:24 PM, Colin Cross wrote:
> On Fri, Jan 21, 2011 at 5:53 PM, Saravana Kannan<skannan@codeaurora.org>  wrote:
>> On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:
>>>
>>> On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
>>>>
>>>> In my opinion, the only major reason for needing atomic clk APIs was due
>>>> to device_ops->suspend being atomic. Since that's not the case anymore,
>>>> I really don't see a justification for atomic clocks. Sure, I might have
>>>> missed some exceptions, but in that case we should make the atomic APIs
>>>> an exception (add clk_enable_atomic) and not the norm.
>>>
>>> The suspend method has never been atomic.  It has always been able to
>>> sleep.  You're mistaken.
>>
>> I distinctly remember trying to do sleeping stuff inside a .suspend function
>> and have it complain that it's atomic. So, I think you might be mistaken.
>> But I will have to back up my claims. Let me trying to find that info. In
>> the end, one of us will learn something new -- which is good and all that
>> matters.
>
> platform_driver->suspend and dev_pm_ops->suspend can sleep, but
> dev_pm_ops->suspend_noirq is called after irqs are disabled and can't
> sleep.  Maybe that's what you were using?
>

The stuff I did was before suspend_noirq was added. Well, at least the 
struct that I was filling up had no suspend_noirq.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Richard Zhao]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console.  clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds.  We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep.  So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.
I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
If its clock tree has many plls and device clock is not far away from plls and
may sleep, we may use prepare/unprepare to do actually clock enable/disable.

Thanks
Richard

Re: Locking in the clk API

[Richard Zhao]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console.  clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds.  We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep.  So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.
I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
If its clock tree has many plls and device clock is not far away from plls and
may sleep, we may use prepare/unprepare to do actually clock enable/disable.

Thanks
Richard

Locking in the clk API

[Richard Zhao]

On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
> >>> If you want to make it so that each low-power mode has to work
> >>> out what PLLs need to be disabled and then re-enabled makes me
> >>> want to be sick. Hiding this stuff behind specific implementations
> >>> is a recipe for disaster.
> >>
> >> Why should systems which don't suffer from such problems be prevented
> >> from gaining power saving from turning off their clocks when devices
> >> are not being used (eg, the console serial port.)
> >>
> >> One solution to your root PLL issue would be to have a separate set of
> >> enable/disable API calls which get called at setup/release time (or
> >> whatever you'd like to call it) which can only be called from non-atomic
> >> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
> >> should perform whatever is necessary to ensure that the clock source
> >> is available for use atomically when clk_enable() is called.
> >>
> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
> >> clk_unprepare() allows it to be turned off.
> >>
> >> In the case of a console driver, clk_prepare() can be called when we
> >> know the port will be used as a console. ?clk_enable() is then called
> >> before writing out the string, and clk_disable() after we've completely
> >> sent the last character.
> >>
> >> This allows the best of both worlds. ?We now have a clk_enable() which
> >> can be used to turn the clocks off through the clock tree up to the first
> >> non-atomic clock, and we also have a way to deal with those which need
> >> to sleep. ?So not only do "sleeping clock" implementations become possible
> >> but these "sleeping clock" implementations also get the opportunity to
> >> shutdown some of their clock tree with minimal latency for doing so.
> >
> > This is exactly what I suggested in my last post, except the console example.
> > Only to be a part of common clock api because it's not very safe to assume
> > future SoCs will have the same simple clock topologies that they have today.
> >
> > Not to mean to teach, but I hope you realize with more and more
> > device controller being crammed into ever shrinking SoCs,
> > clock would eventually have to be flexible in functionality
> > and complicated in hierarchy. Ben already gave examples
> > of Audio, MFC and Video controllers of latest Samsung SoCs.
> 
> plus
> 
> a) If only Samsung bsp implements the api, it would be impossible to
> share drivers, those that can be, with other platforms without nasty ifdef's.
> b) If the task of unification starts with only a particular platform made to
> implement a new api, the attempt kills its own purpose.
I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
If its clock tree has many plls and device clock is not far away from plls and
may sleep, we may use prepare/unprepare to do actually clock enable/disable.

Thanks
Richard

Re: Locking in the clk API

[Jassi Brar]

On Sat, Jan 22, 2011 at 1:08 PM, Richard Zhao <linuxzsc@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console.  clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds.  We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep.  So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
> I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
> If its clock tree has many plls and device clock is not far away from plls and
> may sleep, we may use prepare/unprepare to do actually clock enable/disable.

I am not against clk_prepare/unprepare.
I rather suggest make it part of common clock API.
Please read my last two posts again.

Re: Locking in the clk API

[Jassi Brar]

On Sat, Jan 22, 2011 at 1:08 PM, Richard Zhao <linuxzsc@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context.  Maybe clk_prepare() and clk_unprepare().  These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console.  clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds.  We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep.  So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
> I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
> If its clock tree has many plls and device clock is not far away from plls and
> may sleep, we may use prepare/unprepare to do actually clock enable/disable.

I am not against clk_prepare/unprepare.
I rather suggest make it part of common clock API.
Please read my last two posts again.

Locking in the clk API

[Jassi Brar]

On Sat, Jan 22, 2011 at 1:08 PM, Richard Zhao <linuxzsc@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 01:47:29PM +0900, Jassi Brar wrote:
>> On Fri, Jan 21, 2011 at 9:09 AM, Jassi Brar <jassisinghbrar@gmail.com> wrote:
>> > On Fri, Jan 21, 2011 at 4:08 AM, Russell King - ARM Linux
>> > <linux@arm.linux.org.uk> wrote:
>> >> On Thu, Jan 20, 2011 at 05:02:55PM +0000, Ben Dooks wrote:
>> >>> If you want to make it so that each low-power mode has to work
>> >>> out what PLLs need to be disabled and then re-enabled makes me
>> >>> want to be sick. Hiding this stuff behind specific implementations
>> >>> is a recipe for disaster.
>> >>
>> >> Why should systems which don't suffer from such problems be prevented
>> >> from gaining power saving from turning off their clocks when devices
>> >> are not being used (eg, the console serial port.)
>> >>
>> >> One solution to your root PLL issue would be to have a separate set of
>> >> enable/disable API calls which get called at setup/release time (or
>> >> whatever you'd like to call it) which can only be called from non-atomic
>> >> context. ?Maybe clk_prepare() and clk_unprepare(). ?These functions
>> >> should perform whatever is necessary to ensure that the clock source
>> >> is available for use atomically when clk_enable() is called.
>> >>
>> >> So, in your case, clk_prepare() ensures that the root PLL is enabled,
>> >> clk_unprepare() allows it to be turned off.
>> >>
>> >> In the case of a console driver, clk_prepare() can be called when we
>> >> know the port will be used as a console. ?clk_enable() is then called
>> >> before writing out the string, and clk_disable() after we've completely
>> >> sent the last character.
>> >>
>> >> This allows the best of both worlds. ?We now have a clk_enable() which
>> >> can be used to turn the clocks off through the clock tree up to the first
>> >> non-atomic clock, and we also have a way to deal with those which need
>> >> to sleep. ?So not only do "sleeping clock" implementations become possible
>> >> but these "sleeping clock" implementations also get the opportunity to
>> >> shutdown some of their clock tree with minimal latency for doing so.
>> >
>> > This is exactly what I suggested in my last post, except the console example.
>> > Only to be a part of common clock api because it's not very safe to assume
>> > future SoCs will have the same simple clock topologies that they have today.
>> >
>> > Not to mean to teach, but I hope you realize with more and more
>> > device controller being crammed into ever shrinking SoCs,
>> > clock would eventually have to be flexible in functionality
>> > and complicated in hierarchy. Ben already gave examples
>> > of Audio, MFC and Video controllers of latest Samsung SoCs.
>>
>> plus
>>
>> a) If only Samsung bsp implements the api, it would be impossible to
>> share drivers, those that can be, with other platforms without nasty ifdef's.
>> b) If the task of unification starts with only a particular platform made to
>> implement a new api, the attempt kills its own purpose.
> I'm not clear. Why does Samsung SoC go against clk_prepare/unprepare?
> If its clock tree has many plls and device clock is not far away from plls and
> may sleep, we may use prepare/unprepare to do actually clock enable/disable.

I am not against clk_prepare/unprepare.
I rather suggest make it part of common clock API.
Please read my last two posts again.

Locking in the clk API

[Russell King - ARM Linux]

On Fri, Jan 21, 2011 at 05:53:43PM -0800, Saravana Kannan wrote:
> On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:
>> On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
>>> In my opinion, the only major reason for needing atomic clk APIs was due
>>> to device_ops->suspend being atomic. Since that's not the case anymore,
>>> I really don't see a justification for atomic clocks. Sure, I might have
>>> missed some exceptions, but in that case we should make the atomic APIs
>>> an exception (add clk_enable_atomic) and not the norm.
>>
>> The suspend method has never been atomic.  It has always been able to
>> sleep.  You're mistaken.
>
> I distinctly remember trying to do sleeping stuff inside a .suspend  
> function and have it complain that it's atomic. So, I think you might be  
> mistaken.

No I'm not.  I've always had stuff which takes mutexes/semaphores in
the suspend method.

You'll get the warning if you take a spinlock and then try sleeping -
but that's your error for creating an atomic context (you can't sleep
while holding a spinlock), not the fault of the callback.

Locking in the clk API

[Saravana Kannan]

On 01/22/2011 01:15 AM, Russell King - ARM Linux wrote:
> On Fri, Jan 21, 2011 at 05:53:43PM -0800, Saravana Kannan wrote:
>> On 01/21/2011 01:32 AM, Russell King - ARM Linux wrote:
>>> On Thu, Jan 20, 2011 at 08:12:45PM -0800, Saravana Kannan wrote:
>>>> In my opinion, the only major reason for needing atomic clk APIs was due
>>>> to device_ops->suspend being atomic. Since that's not the case anymore,
>>>> I really don't see a justification for atomic clocks. Sure, I might have
>>>> missed some exceptions, but in that case we should make the atomic APIs
>>>> an exception (add clk_enable_atomic) and not the norm.
>>>
>>> The suspend method has never been atomic.  It has always been able to
>>> sleep.  You're mistaken.
>>
>> I distinctly remember trying to do sleeping stuff inside a .suspend
>> function and have it complain that it's atomic. So, I think you might be
>> mistaken.
>
> No I'm not.  I've always had stuff which takes mutexes/semaphores in
> the suspend method.
>
> You'll get the warning if you take a spinlock and then try sleeping -
> but that's your error for creating an atomic context (you can't sleep
> while holding a spinlock), not the fault of the callback.

I'm well aware of the fact that you can't grab a mutex inside a 
spinlock. Like I said, I will dig into this sometime and get back.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/21/2011 01:40 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
>> This suggestion looked promising till I realized that clk_set_rate()
>> will still be atomic. clk_set_rate() will need to enable/disable the
>> PLLs depending on which PLLs the rates are derived from. So, the locking
>> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"
>> is shared with clk_set_rate().
>
> Who calls clk_set_rate() from an atomic context?  Do we know whether
> anyone does?

As promised I looked into this in the upstream kernel and with the 
internal teams.

In the upstream (torvalds/master) kernel, I found at least one example 
of calling clk_set_rate() from atomic context (spinlock in this case):
cpm_uart/cpm_uart_core.c

I'm not too familiar with serial/tty, does anyone know if the 
.set_termios needs to be atmoic? If not, we could just change 
cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

In our internal tree (which we upstream), we have UART HS driver that 
needs to do the same stuff as cpm_uart_core.c. The problem is 
essentially the UART baud rate range being too high to be controllable 
by just the dividers in the UART core. So, the clock rate has to be 
changed in the .set_termios function.

Another concern (not present in MSM) for upstream kernel is that some 
arch/mach might use the clock driver to control the CPU frequency and 
might want to drop it to a low freq in the final stages of an idle 
suspend. In that case, the call would be from atomic context. Similar 
issue during normal suspend.

Except UART, looks like internal teams don't care much for atomic 
clk_set_rate(). So, if .set_termios can use mutex, MSM is good to go for 
prepare/unprepare.

Russell,

If UART does not need clk_set_rate() to be atomic, would you be 
comfortable marking clk_set_rate() as sleepable in the clk.h comments?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/21/2011 01:40 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
>> This suggestion looked promising till I realized that clk_set_rate()
>> will still be atomic. clk_set_rate() will need to enable/disable the
>> PLLs depending on which PLLs the rates are derived from. So, the locking
>> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"
>> is shared with clk_set_rate().
>
> Who calls clk_set_rate() from an atomic context?  Do we know whether
> anyone does?

As promised I looked into this in the upstream kernel and with the 
internal teams.

In the upstream (torvalds/master) kernel, I found at least one example 
of calling clk_set_rate() from atomic context (spinlock in this case):
cpm_uart/cpm_uart_core.c

I'm not too familiar with serial/tty, does anyone know if the 
.set_termios needs to be atmoic? If not, we could just change 
cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

In our internal tree (which we upstream), we have UART HS driver that 
needs to do the same stuff as cpm_uart_core.c. The problem is 
essentially the UART baud rate range being too high to be controllable 
by just the dividers in the UART core. So, the clock rate has to be 
changed in the .set_termios function.

Another concern (not present in MSM) for upstream kernel is that some 
arch/mach might use the clock driver to control the CPU frequency and 
might want to drop it to a low freq in the final stages of an idle 
suspend. In that case, the call would be from atomic context. Similar 
issue during normal suspend.

Except UART, looks like internal teams don't care much for atomic 
clk_set_rate(). So, if .set_termios can use mutex, MSM is good to go for 
prepare/unprepare.

Russell,

If UART does not need clk_set_rate() to be atomic, would you be 
comfortable marking clk_set_rate() as sleepable in the clk.h comments?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/21/2011 01:40 AM, Russell King - ARM Linux wrote:
> On Thu, Jan 20, 2011 at 11:16:04PM -0800, Saravana Kannan wrote:
>> This suggestion looked promising till I realized that clk_set_rate()
>> will still be atomic. clk_set_rate() will need to enable/disable the
>> PLLs depending on which PLLs the rates are derived from. So, the locking
>> in clk_prepare/unprepare() still has to be atomic since the "slow stuff"
>> is shared with clk_set_rate().
>
> Who calls clk_set_rate() from an atomic context?  Do we know whether
> anyone does?

As promised I looked into this in the upstream kernel and with the 
internal teams.

In the upstream (torvalds/master) kernel, I found at least one example 
of calling clk_set_rate() from atomic context (spinlock in this case):
cpm_uart/cpm_uart_core.c

I'm not too familiar with serial/tty, does anyone know if the 
.set_termios needs to be atmoic? If not, we could just change 
cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

In our internal tree (which we upstream), we have UART HS driver that 
needs to do the same stuff as cpm_uart_core.c. The problem is 
essentially the UART baud rate range being too high to be controllable 
by just the dividers in the UART core. So, the clock rate has to be 
changed in the .set_termios function.

Another concern (not present in MSM) for upstream kernel is that some 
arch/mach might use the clock driver to control the CPU frequency and 
might want to drop it to a low freq in the final stages of an idle 
suspend. In that case, the call would be from atomic context. Similar 
issue during normal suspend.

Except UART, looks like internal teams don't care much for atomic 
clk_set_rate(). So, if .set_termios can use mutex, MSM is good to go for 
prepare/unprepare.

Russell,

If UART does not need clk_set_rate() to be atomic, would you be 
comfortable marking clk_set_rate() as sleepable in the clk.h comments?

Thanks,
Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
> I'm not too familiar with serial/tty, does anyone know if the  
> .set_termios needs to be atmoic? If not, we could just change  
> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

The locking is there to protect against the interrupt handler accessing
the port->* stuff (which seems to have been forgotten by the cpm driver).

I don't see any reason why clk_set_rate() needs to be under the spinlock
there - we need the reprogramming of the baud rate within the spinlock
on 8250 because of DLAB bit hiding the data registers.  It's also a good
idea that it _is_ within the spinlock along with uart_update_timeout()
to ensure timeouts and the baud rate are updated together.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
> I'm not too familiar with serial/tty, does anyone know if the  
> .set_termios needs to be atmoic? If not, we could just change  
> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

The locking is there to protect against the interrupt handler accessing
the port->* stuff (which seems to have been forgotten by the cpm driver).

I don't see any reason why clk_set_rate() needs to be under the spinlock
there - we need the reprogramming of the baud rate within the spinlock
on 8250 because of DLAB bit hiding the data registers.  It's also a good
idea that it _is_ within the spinlock along with uart_update_timeout()
to ensure timeouts and the baud rate are updated together.

Locking in the clk API

[Russell King - ARM Linux]

On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
> I'm not too familiar with serial/tty, does anyone know if the  
> .set_termios needs to be atmoic? If not, we could just change  
> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.

The locking is there to protect against the interrupt handler accessing
the port->* stuff (which seems to have been forgotten by the cpm driver).

I don't see any reason why clk_set_rate() needs to be under the spinlock
there - we need the reprogramming of the baud rate within the spinlock
on 8250 because of DLAB bit hiding the data registers.  It's also a good
idea that it _is_ within the spinlock along with uart_update_timeout()
to ensure timeouts and the baud rate are updated together.

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>> I'm not too familiar with serial/tty, does anyone know if the
>> .set_termios needs to be atmoic? If not, we could just change
>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>
> The locking is there to protect against the interrupt handler accessing
> the port->* stuff (which seems to have been forgotten by the cpm driver).
>
> I don't see any reason why clk_set_rate() needs to be under the spinlock
> there - we need the reprogramming of the baud rate within the spinlock
> on 8250 because of DLAB bit hiding the data registers.  It's also a good
> idea that it _is_ within the spinlock along with uart_update_timeout()
> to ensure timeouts and the baud rate are updated together.

For internal tree purposes, does .set_termios need to be atomic? Can it 
grab mutexes instead of spinlock?

Going back to the topic, how about CPU freq drivers possibly using 
clk_set_rate() to change freq? Do you think that's not the case or a 
concern?

All,

Do any one of your mach's control CPU freq using clk_set_rate() and does 
it need to be atomic? CPUfreq doesn't need it to be atomic. So, you will 
need clk_set_rate() to be atomic only if you try to use it to lower CPU 
freq very late during idle/suspend.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>> I'm not too familiar with serial/tty, does anyone know if the
>> .set_termios needs to be atmoic? If not, we could just change
>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>
> The locking is there to protect against the interrupt handler accessing
> the port->* stuff (which seems to have been forgotten by the cpm driver).
>
> I don't see any reason why clk_set_rate() needs to be under the spinlock
> there - we need the reprogramming of the baud rate within the spinlock
> on 8250 because of DLAB bit hiding the data registers.  It's also a good
> idea that it _is_ within the spinlock along with uart_update_timeout()
> to ensure timeouts and the baud rate are updated together.

For internal tree purposes, does .set_termios need to be atomic? Can it 
grab mutexes instead of spinlock?

Going back to the topic, how about CPU freq drivers possibly using 
clk_set_rate() to change freq? Do you think that's not the case or a 
concern?

All,

Do any one of your mach's control CPU freq using clk_set_rate() and does 
it need to be atomic? CPUfreq doesn't need it to be atomic. So, you will 
need clk_set_rate() to be atomic only if you try to use it to lower CPU 
freq very late during idle/suspend.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>> I'm not too familiar with serial/tty, does anyone know if the
>> .set_termios needs to be atmoic? If not, we could just change
>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>
> The locking is there to protect against the interrupt handler accessing
> the port->* stuff (which seems to have been forgotten by the cpm driver).
>
> I don't see any reason why clk_set_rate() needs to be under the spinlock
> there - we need the reprogramming of the baud rate within the spinlock
> on 8250 because of DLAB bit hiding the data registers.  It's also a good
> idea that it _is_ within the spinlock along with uart_update_timeout()
> to ensure timeouts and the baud rate are updated together.

For internal tree purposes, does .set_termios need to be atomic? Can it 
grab mutexes instead of spinlock?

Going back to the topic, how about CPU freq drivers possibly using 
clk_set_rate() to change freq? Do you think that's not the case or a 
concern?

All,

Do any one of your mach's control CPU freq using clk_set_rate() and does 
it need to be atomic? CPUfreq doesn't need it to be atomic. So, you will 
need clk_set_rate() to be atomic only if you try to use it to lower CPU 
freq very late during idle/suspend.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>> I'm not too familiar with serial/tty, does anyone know if the
>>> .set_termios needs to be atmoic? If not, we could just change
>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>
>> The locking is there to protect against the interrupt handler accessing
>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>
>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>> there - we need the reprogramming of the baud rate within the spinlock
>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>> idea that it _is_ within the spinlock along with uart_update_timeout()
>> to ensure timeouts and the baud rate are updated together.
>
> For internal tree purposes, does .set_termios need to be atomic? Can it  
> grab mutexes instead of spinlock?

I think I already answered that question above where I said "protect
against the interrupt handler accessing the port->* stuff".

> Going back to the topic, how about CPU freq drivers possibly using  
> clk_set_rate() to change freq? Do you think that's not the case or a  
> concern?

CPUfreq drivers probably should busy-wait until the CPU PLL has locked
if the CPU is allowed to continue running while the PLL relocks.  Some
implementations will halt the CPU while the PLL is transitioning and
that's really not unreasonable to do.

I think some even require the code to be running out of SRAM and SDRAM
remain untouched while the PLL is transitioning (omap maybe?)

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>> I'm not too familiar with serial/tty, does anyone know if the
>>> .set_termios needs to be atmoic? If not, we could just change
>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>
>> The locking is there to protect against the interrupt handler accessing
>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>
>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>> there - we need the reprogramming of the baud rate within the spinlock
>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>> idea that it _is_ within the spinlock along with uart_update_timeout()
>> to ensure timeouts and the baud rate are updated together.
>
> For internal tree purposes, does .set_termios need to be atomic? Can it  
> grab mutexes instead of spinlock?

I think I already answered that question above where I said "protect
against the interrupt handler accessing the port->* stuff".

> Going back to the topic, how about CPU freq drivers possibly using  
> clk_set_rate() to change freq? Do you think that's not the case or a  
> concern?

CPUfreq drivers probably should busy-wait until the CPU PLL has locked
if the CPU is allowed to continue running while the PLL relocks.  Some
implementations will halt the CPU while the PLL is transitioning and
that's really not unreasonable to do.

I think some even require the code to be running out of SRAM and SDRAM
remain untouched while the PLL is transitioning (omap maybe?)

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>> I'm not too familiar with serial/tty, does anyone know if the
>>> .set_termios needs to be atmoic? If not, we could just change
>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>
>> The locking is there to protect against the interrupt handler accessing
>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>
>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>> there - we need the reprogramming of the baud rate within the spinlock
>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>> idea that it _is_ within the spinlock along with uart_update_timeout()
>> to ensure timeouts and the baud rate are updated together.
>
> For internal tree purposes, does .set_termios need to be atomic? Can it  
> grab mutexes instead of spinlock?

I think I already answered that question above where I said "protect
against the interrupt handler accessing the port->* stuff".

> Going back to the topic, how about CPU freq drivers possibly using  
> clk_set_rate() to change freq? Do you think that's not the case or a  
> concern?

CPUfreq drivers probably should busy-wait until the CPU PLL has locked
if the CPU is allowed to continue running while the PLL relocks.  Some
implementations will halt the CPU while the PLL is transitioning and
that's really not unreasonable to do.

I think some even require the code to be running out of SRAM and SDRAM
remain untouched while the PLL is transitioning (omap maybe?)

Re: Locking in the clk API

[Alan Cox]

> > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > grab mutexes instead of spinlock?
> 
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".

I'm not sure you answered it correctly however as the locking nowdays is
a bit different.

Architecturally the termios handling doesn't need a spin lock nor is it
called under one. In fact it's vital this is the case because of USB.

I see nothing in the 2.6.37 cpm_uart code that isn't trivially fixable.
There is already a mutex protecting termios serialization so all you seem
to need to do is call clk_set_rate after rather than before dropping the
lock surely ?

Oh if you are looking at the cpm_uart code and care about it the following
in the code isn't safe as tty could possibly go NULL and be freed under
you.

     struct tty_struct *tty = port->state->port.tty;

and you ought to be doing

	tty = tty_port_tty_get(&port->state->port);

	if (tty)
		blah;
	tty_kref_put(tty);	/* put NULL is a no-op anyway */


probably in the main irq handler and pass tty to the helpers that need it.


Alan

Re: Locking in the clk API

[Alan Cox]

> > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > grab mutexes instead of spinlock?
> 
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".

I'm not sure you answered it correctly however as the locking nowdays is
a bit different.

Architecturally the termios handling doesn't need a spin lock nor is it
called under one. In fact it's vital this is the case because of USB.

I see nothing in the 2.6.37 cpm_uart code that isn't trivially fixable.
There is already a mutex protecting termios serialization so all you seem
to need to do is call clk_set_rate after rather than before dropping the
lock surely ?

Oh if you are looking at the cpm_uart code and care about it the following
in the code isn't safe as tty could possibly go NULL and be freed under
you.

     struct tty_struct *tty = port->state->port.tty;

and you ought to be doing

	tty = tty_port_tty_get(&port->state->port);

	if (tty)
		blah;
	tty_kref_put(tty);	/* put NULL is a no-op anyway */


probably in the main irq handler and pass tty to the helpers that need it.


Alan

Locking in the clk API

[Alan Cox]

> > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > grab mutexes instead of spinlock?
> 
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".

I'm not sure you answered it correctly however as the locking nowdays is
a bit different.

Architecturally the termios handling doesn't need a spin lock nor is it
called under one. In fact it's vital this is the case because of USB.

I see nothing in the 2.6.37 cpm_uart code that isn't trivially fixable.
There is already a mutex protecting termios serialization so all you seem
to need to do is call clk_set_rate after rather than before dropping the
lock surely ?

Oh if you are looking at the cpm_uart code and care about it the following
in the code isn't safe as tty could possibly go NULL and be freed under
you.

     struct tty_struct *tty = port->state->port.tty;

and you ought to be doing

	tty = tty_port_tty_get(&port->state->port);

	if (tty)
		blah;
	tty_kref_put(tty);	/* put NULL is a no-op anyway */


probably in the main irq handler and pass tty to the helpers that need it.


Alan

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
> 
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

It needs to protect against the read_status_mask and ignore_status_mask
being read half-way through an update by the interrupt handler, otherwise
you can end up with god-knows-what coming through from each termios
change.

Eg, you could see an effective CREAD flip when the state of CREAD wasn't
actually changed.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
> 
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

It needs to protect against the read_status_mask and ignore_status_mask
being read half-way through an update by the interrupt handler, otherwise
you can end up with god-knows-what coming through from each termios
change.

Eg, you could see an effective CREAD flip when the state of CREAD wasn't
actually changed.

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
> 
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

It needs to protect against the read_status_mask and ignore_status_mask
being read half-way through an update by the interrupt handler, otherwise
you can end up with god-knows-what coming through from each termios
change.

Eg, you could see an effective CREAD flip when the state of CREAD wasn't
actually changed.

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.

Oh, and the other bit to this is protecting the hardware against two
concurrent accesses if that's what's required.

Eg, 8250 having characters written to the 'transmit' register while
DLAB is set, thereby corrupting the divisor being programmed into it.
There's other UARTs which shouldn't have FIFOs loaded while the UART
is disabled across an update.

Can you guarantee without locks that writes to the UART registers by
the interrupt handler won't happen while the .set_termios is
reprogramming the UART?

Re: Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.

Oh, and the other bit to this is protecting the hardware against two
concurrent accesses if that's what's required.

Eg, 8250 having characters written to the 'transmit' register while
DLAB is set, thereby corrupting the divisor being programmed into it.
There's other UARTs which shouldn't have FIFOs loaded while the UART
is disabled across an update.

Can you guarantee without locks that writes to the UART registers by
the interrupt handler won't happen while the .set_termios is
reprogramming the UART?

Locking in the clk API

[Russell King - ARM Linux]

On Thu, Jan 27, 2011 at 09:07:29PM +0000, Alan Cox wrote:
> > > For internal tree purposes, does .set_termios need to be atomic? Can it  
> > > grab mutexes instead of spinlock?
> > 
> > I think I already answered that question above where I said "protect
> > against the interrupt handler accessing the port->* stuff".
> 
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.

Oh, and the other bit to this is protecting the hardware against two
concurrent accesses if that's what's required.

Eg, 8250 having characters written to the 'transmit' register while
DLAB is set, thereby corrupting the divisor being programmed into it.
There's other UARTs which shouldn't have FIFOs loaded while the UART
is disabled across an update.

Can you guarantee without locks that writes to the UART registers by
the interrupt handler won't happen while the .set_termios is
reprogramming the UART?

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:43 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
>> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>>> I'm not too familiar with serial/tty, does anyone know if the
>>>> .set_termios needs to be atmoic? If not, we could just change
>>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>>
>>> The locking is there to protect against the interrupt handler accessing
>>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>>
>>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>>> there - we need the reprogramming of the baud rate within the spinlock
>>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>>> idea that it _is_ within the spinlock along with uart_update_timeout()
>>> to ensure timeouts and the baud rate are updated together.
>>
>> For internal tree purposes, does .set_termios need to be atomic? Can it
>> grab mutexes instead of spinlock?
>
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".
>
>> Going back to the topic, how about CPU freq drivers possibly using
>> clk_set_rate() to change freq? Do you think that's not the case or a
>> concern?
>
> CPUfreq drivers probably should busy-wait until the CPU PLL has locked
> if the CPU is allowed to continue running while the PLL relocks.  Some
> implementations will halt the CPU while the PLL is transitioning and
> that's really not unreasonable to do.
>
> I think some even require the code to be running out of SRAM and SDRAM
> remain untouched while the PLL is transitioning (omap maybe?)

Looks like you are confident to consider clk_set_rate() as sleepable. 
Can we add a comment to clk.h that says so?

Otherwise, there is no point in the suggesting the 
clk_prepare/unprepare() APIs.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:43 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
>> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>>> I'm not too familiar with serial/tty, does anyone know if the
>>>> .set_termios needs to be atmoic? If not, we could just change
>>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>>
>>> The locking is there to protect against the interrupt handler accessing
>>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>>
>>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>>> there - we need the reprogramming of the baud rate within the spinlock
>>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>>> idea that it _is_ within the spinlock along with uart_update_timeout()
>>> to ensure timeouts and the baud rate are updated together.
>>
>> For internal tree purposes, does .set_termios need to be atomic? Can it
>> grab mutexes instead of spinlock?
>
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".
>
>> Going back to the topic, how about CPU freq drivers possibly using
>> clk_set_rate() to change freq? Do you think that's not the case or a
>> concern?
>
> CPUfreq drivers probably should busy-wait until the CPU PLL has locked
> if the CPU is allowed to continue running while the PLL relocks.  Some
> implementations will halt the CPU while the PLL is transitioning and
> that's really not unreasonable to do.
>
> I think some even require the code to be running out of SRAM and SDRAM
> remain untouched while the PLL is transitioning (omap maybe?)

Looks like you are confident to consider clk_set_rate() as sleepable. 
Can we add a comment to clk.h that says so?

Otherwise, there is no point in the suggesting the 
clk_prepare/unprepare() APIs.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/27/2011 12:43 PM, Russell King - ARM Linux wrote:
> On Thu, Jan 27, 2011 at 12:30:36PM -0800, Saravana Kannan wrote:
>> On 01/27/2011 12:54 AM, Russell King - ARM Linux wrote:
>>> On Wed, Jan 26, 2011 at 08:34:20PM -0800, Saravana Kannan wrote:
>>>> I'm not too familiar with serial/tty, does anyone know if the
>>>> .set_termios needs to be atmoic? If not, we could just change
>>>> cpm_uart/cpm_uart_core.c to use mutex instead of spinlock.
>>>
>>> The locking is there to protect against the interrupt handler accessing
>>> the port->* stuff (which seems to have been forgotten by the cpm driver).
>>>
>>> I don't see any reason why clk_set_rate() needs to be under the spinlock
>>> there - we need the reprogramming of the baud rate within the spinlock
>>> on 8250 because of DLAB bit hiding the data registers.  It's also a good
>>> idea that it _is_ within the spinlock along with uart_update_timeout()
>>> to ensure timeouts and the baud rate are updated together.
>>
>> For internal tree purposes, does .set_termios need to be atomic? Can it
>> grab mutexes instead of spinlock?
>
> I think I already answered that question above where I said "protect
> against the interrupt handler accessing the port->* stuff".
>
>> Going back to the topic, how about CPU freq drivers possibly using
>> clk_set_rate() to change freq? Do you think that's not the case or a
>> concern?
>
> CPUfreq drivers probably should busy-wait until the CPU PLL has locked
> if the CPU is allowed to continue running while the PLL relocks.  Some
> implementations will halt the CPU while the PLL is transitioning and
> that's really not unreasonable to do.
>
> I think some even require the code to be running out of SRAM and SDRAM
> remain untouched while the PLL is transitioning (omap maybe?)

Looks like you are confident to consider clk_set_rate() as sleepable. 
Can we add a comment to clk.h that says so?

Otherwise, there is no point in the suggesting the 
clk_prepare/unprepare() APIs.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 01:07 PM, Alan Cox wrote:
>>> For internal tree purposes, does .set_termios need to be atomic? Can it
>>> grab mutexes instead of spinlock?
>>
>> I think I already answered that question above where I said "protect
>> against the interrupt handler accessing the port->* stuff".
>
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
>
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

Thanks for the clarification Alan. This is what I was looking for.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Locking in the clk API

[Saravana Kannan]

On 01/27/2011 01:07 PM, Alan Cox wrote:
>>> For internal tree purposes, does .set_termios need to be atomic? Can it
>>> grab mutexes instead of spinlock?
>>
>> I think I already answered that question above where I said "protect
>> against the interrupt handler accessing the port->* stuff".
>
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
>
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

Thanks for the clarification Alan. This is what I was looking for.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Locking in the clk API

[Saravana Kannan]

On 01/27/2011 01:07 PM, Alan Cox wrote:
>>> For internal tree purposes, does .set_termios need to be atomic? Can it
>>> grab mutexes instead of spinlock?
>>
>> I think I already answered that question above where I said "protect
>> against the interrupt handler accessing the port->* stuff".
>
> I'm not sure you answered it correctly however as the locking nowdays is
> a bit different.
>
> Architecturally the termios handling doesn't need a spin lock nor is it
> called under one. In fact it's vital this is the case because of USB.

Thanks for the clarification Alan. This is what I was looking for.

-Saravana

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.