* Locking in the clk API @ 2011-01-11 2:16 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 2:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 2:16 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 2:16 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 2:16 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 2:16 UTC (permalink / raw) To: linux-sh, linux-arm-kernel, linux-kernel Cc: Ben Herrenschmidt, Vincent Guittot, Uwe Kleine-König, Sascha Hauer, Lorenzo Pieralisi 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 2:16 ` Jeremy Kerr (?) @ 2011-01-11 3:15 ` Paul Mundt -1 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 3:15 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 3:15 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 3:15 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 3:15 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 3:15 UTC (permalink / raw) To: Jeremy Kerr Cc: linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Vincent Guittot, Uwe Kleine-K??nig, Sascha Hauer, Lorenzo Pieralisi 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 3:15 ` Paul Mundt (?) @ 2011-01-11 4:11 ` Jeremy Kerr -1 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 4:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 4:11 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 4:11 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 4:11 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 4:11 UTC (permalink / raw) To: Paul Mundt Cc: linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Vincent Guittot, Uwe Kleine-K??nig, Sascha Hauer, Lorenzo Pieralisi 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 4:11 ` Jeremy Kerr (?) @ 2011-01-11 4:54 ` Paul Mundt -1 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 4:54 UTC (permalink / raw) To: linux-arm-kernel 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/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 4:54 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 4:54 UTC (permalink / raw) To: linux-arm-kernel 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/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 4:54 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 4:54 UTC (permalink / raw) To: Jeremy Kerr Cc: linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Vincent Guittot, Uwe Kleine-K??nig, Sascha Hauer, Lorenzo Pieralisi 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/ ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 4:54 ` Paul Mundt (?) @ 2011-01-20 16:32 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:32 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 16:32 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:32 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 16:32 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:32 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 16:32 ` Ben Dooks (?) @ 2011-01-20 18:57 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:57 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 18:57 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:57 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 18:57 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:57 UTC (permalink / raw) To: Ben Dooks Cc: Paul Mundt, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 18:57 ` Russell King - ARM Linux (?) @ 2011-01-21 3:43 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 3:43 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 3:43 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 3:43 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 3:43 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 3:43 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 3:43 ` Saravana Kannan (?) @ 2011-01-21 9:31 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:31 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 9:31 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:31 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 9:31 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:31 UTC (permalink / raw) To: Saravana Kannan Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 4:11 ` Jeremy Kerr (?) @ 2011-01-11 9:03 ` Sascha Hauer -1 siblings, 0 replies; 248+ messages in thread From: Sascha Hauer @ 2011-01-11 9:03 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 9:03 ` Sascha Hauer 0 siblings, 0 replies; 248+ messages in thread From: Sascha Hauer @ 2011-01-11 9:03 UTC (permalink / raw) To: linux-arm-kernel 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 | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 9:03 ` Sascha Hauer 0 siblings, 0 replies; 248+ messages in thread From: Sascha Hauer @ 2011-01-11 9:03 UTC (permalink / raw) To: Jeremy Kerr Cc: Paul Mundt, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Vincent Guittot, Uwe Kleine-K??nig, Lorenzo Pieralisi 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 | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:03 ` Sascha Hauer (?) @ 2011-01-11 9:28 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 9:28 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 9:28 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:28 UTC (permalink / raw) To: Sascha Hauer Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, linux-kernel, Paul Mundt, Uwe Kleine-K??nig, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:28 ` Russell King - ARM Linux (?) @ 2011-01-11 14:34 ` Pavel Machek -1 siblings, 0 replies; 248+ messages in thread From: Pavel Machek @ 2011-01-11 14:34 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 14:34 ` Pavel Machek 0 siblings, 0 replies; 248+ messages in thread From: Pavel Machek @ 2011-01-11 14:34 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 14:34 ` Pavel Machek 0 siblings, 0 replies; 248+ messages in thread From: Pavel Machek @ 2011-01-11 14:34 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, linux-kernel, Paul Mundt, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 3:15 ` Paul Mundt (?) @ 2011-01-20 16:29 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:29 UTC (permalink / raw) To: linux-arm-kernel 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) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 16:29 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:29 UTC (permalink / raw) To: linux-arm-kernel 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) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 16:29 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:29 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, linux-arm-kernel 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) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 16:29 ` Ben Dooks (?) @ 2011-01-20 18:56 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:56 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 18:56 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:56 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 18:56 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 18:56 UTC (permalink / raw) To: Ben Dooks Cc: Paul Mundt, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 18:56 ` Russell King - ARM Linux (?) @ 2011-01-20 21:30 ` Nicolas Pitre -1 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-20 21:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 21:30 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-20 21:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 21:30 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-20 21:30 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Paul Mundt, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 21:30 ` Nicolas Pitre (?) @ 2011-01-21 2:06 ` Dima Zavin -1 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 2:06 UTC (permalink / raw) To: linux-arm-kernel 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/ > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 2:06 ` Dima Zavin 0 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 2:06 UTC (permalink / raw) To: linux-arm-kernel 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/ > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 2:06 ` Dima Zavin 0 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 2:06 UTC (permalink / raw) To: Nicolas Pitre Cc: Russell King - ARM Linux, Ben Dooks, Paul Mundt, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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/ > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 2:06 ` Dima Zavin (?) @ 2011-01-21 4:12 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 4:12 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 4:12 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 4:12 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 4:12 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 4:12 UTC (permalink / raw) To: Dima Zavin Cc: Nicolas Pitre, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 4:12 ` Saravana Kannan (?) @ 2011-01-21 9:32 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:32 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 9:32 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:32 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 9:32 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:32 UTC (permalink / raw) To: Saravana Kannan Cc: Dima Zavin, Nicolas Pitre, Lorenzo Pieralisi, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-21 9:32 ` Russell King - ARM Linux (?) (?) @ 2011-01-22 1:53 ` Saravana Kannan 2011-01-22 2:24 ` Colin Cross 2011-01-22 9:15 ` Russell King - ARM Linux -1 siblings, 2 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 1:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-22 1:53 ` Saravana Kannan @ 2011-01-22 2:24 ` Colin Cross 2011-01-22 2:56 ` Saravana Kannan 2011-01-22 9:15 ` Russell King - ARM Linux 1 sibling, 1 reply; 248+ messages in thread From: Colin Cross @ 2011-01-22 2:24 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-22 2:24 ` Colin Cross @ 2011-01-22 2:56 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 2:56 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-22 1:53 ` Saravana Kannan 2011-01-22 2:24 ` Colin Cross @ 2011-01-22 9:15 ` Russell King - ARM Linux 2011-01-24 19:31 ` Saravana Kannan 1 sibling, 1 reply; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-22 9:15 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-22 9:15 ` Russell King - ARM Linux @ 2011-01-24 19:31 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-24 19:31 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 4:12 ` Saravana Kannan (?) @ 2011-01-21 21:03 ` Dima Zavin -1 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 21:03 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 21:03 ` Dima Zavin 0 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 21:03 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 21:03 ` Dima Zavin 0 siblings, 0 replies; 248+ messages in thread From: Dima Zavin @ 2011-01-21 21:03 UTC (permalink / raw) To: Saravana Kannan Cc: Nicolas Pitre, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 21:03 ` Dima Zavin (?) @ 2011-01-21 21:53 ` Nicolas Pitre -1 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 21:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 21:53 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 21:53 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 21:53 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 21:53 UTC (permalink / raw) To: Dima Zavin Cc: Saravana Kannan, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 21:53 ` Nicolas Pitre (?) @ 2011-01-21 22:02 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 22:02 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 22:02 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 22:02 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 22:02 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 22:02 UTC (permalink / raw) To: Nicolas Pitre Cc: Dima Zavin, Saravana Kannan, Lorenzo Pieralisi, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 22:02 ` Russell King - ARM Linux (?) @ 2011-01-21 22:28 ` Colin Cross -1 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-21 22:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 22:28 ` Colin Cross 0 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-21 22:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 22:28 ` Colin Cross 0 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-21 22:28 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Nicolas Pitre, Lorenzo Pieralisi, Saravana Kannan, linux-sh, Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel, Dima Zavin, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 22:28 ` Colin Cross (?) @ 2011-01-21 23:21 ` Benjamin Herrenschmidt -1 siblings, 0 replies; 248+ messages in thread From: Benjamin Herrenschmidt @ 2011-01-21 23:21 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 23:21 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 248+ messages in thread From: Benjamin Herrenschmidt @ 2011-01-21 23:21 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 23:21 ` Benjamin Herrenschmidt 0 siblings, 0 replies; 248+ messages in thread From: Benjamin Herrenschmidt @ 2011-01-21 23:21 UTC (permalink / raw) To: Colin Cross Cc: Russell King - ARM Linux, Nicolas Pitre, Lorenzo Pieralisi, Saravana Kannan, linux-sh, Sascha Hauer, Paul Mundt, linux-kernel, Dima Zavin, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 22:28 ` Colin Cross (?) @ 2011-01-21 23:50 ` Nicolas Pitre -1 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 23:50 UTC (permalink / raw) To: linux-arm-kernel [-- 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 23:50 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 23:50 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 23:50 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 23:50 UTC (permalink / raw) To: Colin Cross Cc: Russell King - ARM Linux, Lorenzo Pieralisi, Saravana Kannan, linux-sh, Ben Herrenschmidt, Sascha Hauer, Paul Mundt, lkml, Dima Zavin, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel [-- 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 22:28 ` Colin Cross (?) @ 2011-01-22 1:35 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 1:35 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-22 1:35 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 1:35 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-22 1:35 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 1:35 UTC (permalink / raw) To: Colin Cross Cc: Russell King - ARM Linux, Nicolas Pitre, Dima Zavin, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel, Ben Dooks, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-22 1:35 ` Saravana Kannan (?) @ 2011-01-22 2:22 ` Colin Cross -1 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-22 2:22 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-22 2:22 ` Colin Cross 0 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-22 2:22 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-22 2:22 ` Colin Cross 0 siblings, 0 replies; 248+ messages in thread From: Colin Cross @ 2011-01-22 2:22 UTC (permalink / raw) To: Saravana Kannan Cc: Russell King - ARM Linux, Nicolas Pitre, Dima Zavin, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel, Ben Dooks, Uwe Kleine-K??nig, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 22:02 ` Russell King - ARM Linux (?) @ 2011-01-21 22:29 ` Nicolas Pitre -1 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 22:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 22:29 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 22:29 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 22:29 ` Nicolas Pitre 0 siblings, 0 replies; 248+ messages in thread From: Nicolas Pitre @ 2011-01-21 22:29 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Dima Zavin, Saravana Kannan, Lorenzo Pieralisi, linux-sh, Ben Herrenschmidt, Sascha Hauer, lkml, Paul Mundt, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 21:53 ` Nicolas Pitre (?) @ 2011-01-21 23:28 ` Bryan Huntsman -1 siblings, 0 replies; 248+ messages in thread From: Bryan Huntsman @ 2011-01-21 23:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 23:28 ` Bryan Huntsman 0 siblings, 0 replies; 248+ messages in thread From: Bryan Huntsman @ 2011-01-21 23:28 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 23:28 ` Bryan Huntsman 0 siblings, 0 replies; 248+ messages in thread From: Bryan Huntsman @ 2011-01-21 23:28 UTC (permalink / raw) To: Nicolas Pitre Cc: Dima Zavin, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, Paul Mundt, linux-kernel, Saravana Kannan, Ben Dooks, Uwe Kleine-K??nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 2:16 ` Jeremy Kerr (?) @ 2011-01-11 9:16 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:16 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 9:16 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:16 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 9:16 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 9:16 UTC (permalink / raw) To: Jeremy Kerr Cc: linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:16 ` Russell King - ARM Linux (?) @ 2011-01-11 9:44 ` Jeremy Kerr -1 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 9:44 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 9:44 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 9:44 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 9:44 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 9:44 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:44 ` Jeremy Kerr (?) @ 2011-01-11 10:13 ` Paul Mundt -1 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 10:13 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 10:13 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 10:13 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 10:13 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 10:13 UTC (permalink / raw) To: Jeremy Kerr Cc: Russell King - ARM Linux, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-K?nig 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:13 ` Paul Mundt (?) @ 2011-01-11 10:30 ` Jeremy Kerr -1 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 10:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 10:30 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 10:30 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 10:30 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 10:30 UTC (permalink / raw) To: Paul Mundt Cc: Russell King - ARM Linux, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-K?nig 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:30 ` Jeremy Kerr (?) @ 2011-01-11 12:18 ` Paul Mundt -1 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 12:18 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 12:18 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 12:18 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 12:18 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-11 12:18 UTC (permalink / raw) To: Jeremy Kerr Cc: Russell King - ARM Linux, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-K?nig 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 12:18 ` Paul Mundt (?) @ 2011-01-11 13:52 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-11 13:52 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 13:52 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 13:52 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 13:52 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 13:52 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Vincent Guittot, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 12:18 ` Paul Mundt (?) @ 2011-01-11 14:35 ` Jeremy Kerr -1 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 14:35 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 14:35 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 14:35 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 14:35 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-11 14:35 UTC (permalink / raw) To: Paul Mundt Cc: Russell King - ARM Linux, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 14:35 ` Jeremy Kerr (?) @ 2011-01-12 3:25 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 3:25 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 3:25 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 3:25 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 3:25 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 3:25 UTC (permalink / raw) To: Jeremy Kerr Cc: Paul Mundt, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Vincent Guittot, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-12 3:25 ` Saravana Kannan (?) @ 2011-01-12 7:40 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-12 7:40 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 7:40 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-12 7:40 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 7:40 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-12 7:40 UTC (permalink / raw) To: Saravana Kannan Cc: Jeremy Kerr, Paul Mundt, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Vincent Guittot, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 12:18 ` Paul Mundt (?) @ 2011-01-12 1:54 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 1:54 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 1:54 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 1:54 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 1:54 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 1:54 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K?nig, Vincent Guittot, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-12 1:54 ` Saravana Kannan (?) @ 2011-01-12 2:25 ` Paul Mundt -1 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-12 2:25 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 2:25 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-12 2:25 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 2:25 ` Paul Mundt 0 siblings, 0 replies; 248+ messages in thread From: Paul Mundt @ 2011-01-12 2:25 UTC (permalink / raw) To: Saravana Kannan Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K?nig, Vincent Guittot, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-12 2:25 ` Paul Mundt (?) @ 2011-01-20 16:57 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:57 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 16:57 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:57 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 16:57 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:57 UTC (permalink / raw) To: Paul Mundt Cc: Saravana Kannan, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K?nig, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 12:18 ` Paul Mundt (?) @ 2011-01-20 16:53 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 16:53 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 16:53 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:53 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K?nig, Vincent Guittot, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:13 ` Paul Mundt (?) @ 2011-01-20 16:40 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:40 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 16:40 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:40 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 16:40 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 16:40 UTC (permalink / raw) To: Paul Mundt Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-K?nig, Vincent Guittot, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:44 ` Jeremy Kerr (?) @ 2011-01-11 10:39 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-11 10:39 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 10:39 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 10:39 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 10:39 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 10:39 UTC (permalink / raw) To: Jeremy Kerr Cc: Russell King - ARM Linux, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:39 ` Uwe Kleine-König (?) @ 2011-01-11 10:47 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 10:47 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 10:47 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 10:47 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 10:47 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-11 10:47 UTC (permalink / raw) To: Uwe Kleine-König Cc: Jeremy Kerr, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:47 ` Russell King - ARM Linux (?) @ 2011-01-11 10:56 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-11 10:56 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 10:56 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 10:56 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 10:56 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-11 10:56 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jeremy Kerr, linux-sh, linux-arm-kernel, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 10:39 ` Uwe Kleine-König (?) @ 2011-01-11 11:15 ` Richard Zhao -1 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-11 11:15 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 11:15 ` Richard Zhao 0 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-11 11:15 UTC (permalink / raw) To: linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 11:15 ` Richard Zhao 0 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-11 11:15 UTC (permalink / raw) To: Uwe Kleine-König Cc: Jeremy Kerr, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Vincent Guittot, linux-arm-kernel 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 > ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 11:15 ` Richard Zhao (?) @ 2011-01-20 17:02 ` Ben Dooks -1 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 17:02 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 17:02 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 17:02 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 17:02 ` Ben Dooks 0 siblings, 0 replies; 248+ messages in thread From: Ben Dooks @ 2011-01-20 17:02 UTC (permalink / raw) To: Richard Zhao Cc: Uwe Kleine-König, Lorenzo Pieralisi, Russell King - ARM Linux, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 17:02 ` Ben Dooks (?) @ 2011-01-20 19:08 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 19:08 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-20 19:08 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 19:08 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-20 19:08 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-20 19:08 UTC (permalink / raw) To: Ben Dooks Cc: Richard Zhao, Lorenzo Pieralisi, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Vincent Guittot, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 19:08 ` Russell King - ARM Linux (?) @ 2011-01-21 0:09 ` Jassi Brar -1 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 0:09 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 0:09 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 0:09 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 0:09 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 0:09 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 0:09 ` Jassi Brar (?) @ 2011-01-21 4:47 ` Jassi Brar -1 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 4:47 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 4:47 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 4:47 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 4:47 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 4:47 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 4:47 ` Jassi Brar (?) @ 2011-01-21 9:39 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:39 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 9:39 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:39 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 9:39 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:39 UTC (permalink / raw) To: Jassi Brar Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, 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 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 9:39 ` Russell King - ARM Linux (?) @ 2011-01-21 10:11 ` Jassi Brar -1 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 10:11 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 10:11 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 10:11 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 10:11 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-21 10:11 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 4:47 ` Jassi Brar (?) @ 2011-01-22 4:08 ` Richard Zhao -1 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-22 4:08 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-22 4:08 ` Richard Zhao 0 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-22 4:08 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-22 4:08 ` Richard Zhao 0 siblings, 0 replies; 248+ messages in thread From: Richard Zhao @ 2011-01-22 4:08 UTC (permalink / raw) To: Jassi Brar Cc: Russell King - ARM Linux, Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-22 4:08 ` Richard Zhao (?) @ 2011-01-22 5:30 ` Jassi Brar -1 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-22 5:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-22 5:30 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-22 5:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-22 5:30 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-22 5:30 UTC (permalink / raw) To: Richard Zhao Cc: Russell King - ARM Linux, Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-20 19:08 ` Russell King - ARM Linux (?) @ 2011-01-21 7:16 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 7:16 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 7:16 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 7:16 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 7:16 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-21 7:16 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 7:16 ` Saravana Kannan (?) @ 2011-01-21 9:40 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:40 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-21 9:40 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:40 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-21 9:40 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-21 9:40 UTC (permalink / raw) To: Saravana Kannan Cc: Ben Dooks, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API 2011-01-21 9:40 ` Russell King - ARM Linux (?) (?) @ 2011-01-22 1:47 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-22 1:47 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-21 9:40 ` Russell King - ARM Linux (?) @ 2011-01-27 4:34 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 4:34 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 4:34 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 4:34 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 4:34 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 4:34 UTC (permalink / raw) To: Russell King - ARM Linux, Colin Cross Cc: Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 4:34 ` Saravana Kannan (?) @ 2011-01-27 8:54 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 8:54 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 8:54 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 8:54 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 8:54 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 8:54 UTC (permalink / raw) To: Saravana Kannan Cc: Colin Cross, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 8:54 ` Russell King - ARM Linux (?) @ 2011-01-27 20:30 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 20:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 20:30 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 20:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 20:30 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-27 20:30 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 20:30 ` Saravana Kannan (?) @ 2011-01-27 20:43 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 20:43 UTC (permalink / raw) To: linux-arm-kernel 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?) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 20:43 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 20:43 UTC (permalink / raw) To: linux-arm-kernel 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?) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 20:43 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 20:43 UTC (permalink / raw) To: Saravana Kannan Cc: Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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?) ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 20:43 ` Russell King - ARM Linux (?) @ 2011-01-27 21:07 ` Alan Cox -1 siblings, 0 replies; 248+ messages in thread From: Alan Cox @ 2011-01-27 21:07 UTC (permalink / raw) To: linux-arm-kernel > > 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 21:07 ` Alan Cox 0 siblings, 0 replies; 248+ messages in thread From: Alan Cox @ 2011-01-27 21:07 UTC (permalink / raw) To: linux-arm-kernel > > 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 21:07 ` Alan Cox 0 siblings, 0 replies; 248+ messages in thread From: Alan Cox @ 2011-01-27 21:07 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Saravana Kannan, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao > > 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 21:07 ` Alan Cox (?) @ 2011-01-27 21:11 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 21:11 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 21:11 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:11 UTC (permalink / raw) To: Alan Cox Cc: Saravana Kannan, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 21:07 ` Alan Cox (?) @ 2011-01-27 21:15 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:15 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-27 21:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:15 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-27 21:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-27 21:15 UTC (permalink / raw) To: Alan Cox Cc: Saravana Kannan, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 21:07 ` Alan Cox (?) @ 2011-01-28 3:29 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:29 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-28 3:29 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:29 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-28 3:29 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:29 UTC (permalink / raw) To: Alan Cox Cc: Russell King - ARM Linux, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-27 20:43 ` Russell King - ARM Linux (?) @ 2011-01-28 3:27 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:27 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-28 3:27 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:27 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-28 3:27 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-28 3:27 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Colin Cross, Ben Dooks, Uwe Kleine-König, Jeremy Kerr, linux-arm-kernel, Richard Zhao 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:16 ` Russell King - ARM Linux (?) @ 2011-01-11 12:11 ` Jassi Brar -1 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-11 12:11 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-11 12:11 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-11 12:23 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-11 12:11 ` Jassi Brar 0 siblings, 0 replies; 248+ messages in thread From: Jassi Brar @ 2011-01-11 12:11 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 9:16 ` Russell King - ARM Linux (?) @ 2011-01-12 2:56 ` Saravana Kannan -1 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 2:56 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 2:56 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 2:56 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 2:56 ` Saravana Kannan 0 siblings, 0 replies; 248+ messages in thread From: Saravana Kannan @ 2011-01-12 2:56 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-12 2:56 ` Saravana Kannan (?) @ 2011-01-12 9:03 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-12 9:03 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-12 9:03 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-12 9:03 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-12 9:03 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-12 9:03 UTC (permalink / raw) To: Saravana Kannan Cc: Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-12 9:03 ` Russell King - ARM Linux (?) @ 2011-01-15 14:02 ` Christer Weinigel -1 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 14:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 14:02 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 14:02 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 14:02 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 14:02 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 14:02 ` Christer Weinigel (?) @ 2011-01-15 14:53 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 14:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 14:53 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 14:53 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 14:53 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 14:53 UTC (permalink / raw) To: Christer Weinigel Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 14:53 ` Russell King - ARM Linux (?) @ 2011-01-15 15:03 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-15 15:03 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 15:03 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 15:03 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 15:03 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 15:03 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 15:03 ` Uwe Kleine-König (?) @ 2011-01-15 15:15 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 15:15 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 15:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 15:15 UTC (permalink / raw) To: linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 15:15 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 15:15 UTC (permalink / raw) To: Uwe Kleine-König Cc: Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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? ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 15:15 ` Russell King - ARM Linux (?) @ 2011-01-15 16:03 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-15 16:03 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 16:03 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 16:03 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 16:03 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 16:03 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 16:03 ` Uwe Kleine-König (?) @ 2011-01-15 16:21 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 16:21 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 16:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 16:21 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 16:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 16:21 UTC (permalink / raw) To: Uwe Kleine-König Cc: Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 16:21 ` Russell King - ARM Linux (?) @ 2011-01-15 16:31 ` Uwe Kleine-König -1 siblings, 0 replies; 248+ messages in thread From: @ 2011-01-15 16:31 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 16:31 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 16:31 UTC (permalink / raw) To: linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 16:31 ` Uwe Kleine-König 0 siblings, 0 replies; 248+ messages in thread From: Uwe Kleine-König @ 2011-01-15 16:31 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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/ | ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 15:15 ` Russell King - ARM Linux (?) @ 2011-01-16 6:59 ` Grant Likely -1 siblings, 0 replies; 248+ messages in thread From: Grant Likely @ 2011-01-16 6:59 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-16 6:59 ` Grant Likely 0 siblings, 0 replies; 248+ messages in thread From: Grant Likely @ 2011-01-16 6:59 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-16 6:59 ` Grant Likely 0 siblings, 0 replies; 248+ messages in thread From: Grant Likely @ 2011-01-16 6:59 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Uwe Kleine-König, Christer Weinigel, Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 14:53 ` Russell King - ARM Linux (?) @ 2011-01-15 17:07 ` Christer Weinigel -1 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 17:07 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:07 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 17:07 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:07 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 17:07 ` Christer Weinigel (?) @ 2011-01-15 17:20 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 17:20 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 17:20 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 17:20 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 17:20 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 17:20 UTC (permalink / raw) To: Christer Weinigel Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 17:20 ` Russell King - ARM Linux (?) @ 2011-01-15 17:44 ` Christer Weinigel -1 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:44 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 17:44 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:44 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 17:44 ` Christer Weinigel 0 siblings, 0 replies; 248+ messages in thread From: Christer Weinigel @ 2011-01-15 17:44 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-15 17:44 ` Christer Weinigel (?) @ 2011-01-15 20:30 ` Russell King - ARM Linux -1 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 20:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-15 20:30 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 20:30 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-15 20:30 ` Russell King - ARM Linux 0 siblings, 0 replies; 248+ messages in thread From: Russell King - ARM Linux @ 2011-01-15 20:30 UTC (permalink / raw) To: Christer Weinigel Cc: Saravana Kannan, Jeremy Kerr, Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt, Sascha Hauer, linux-kernel, Uwe Kleine-König, linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API 2011-01-11 2:16 ` Jeremy Kerr (?) @ 2011-01-17 1:19 ` Jeremy Kerr -1 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-17 1:19 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Locking in the clk API @ 2011-01-17 1:19 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-17 1:19 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-17 1:19 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-17 1:19 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-sh, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-17 1:27 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-17 1:27 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-sh, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
* Re: Locking in the clk API @ 2011-01-17 1:27 ` Jeremy Kerr 0 siblings, 0 replies; 248+ messages in thread From: Jeremy Kerr @ 2011-01-17 1:27 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-sh, linux-kernel, Ben Herrenschmidt, Sascha Hauer, Lorenzo Pieralisi, Vincent Guittot, Uwe Kleine-König 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 ^ permalink raw reply [flat|nested] 248+ messages in thread
end of thread, other threads:[~2011-01-28 3:29 UTC | newest] Thread overview: 248+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-11 2:16 Locking in the clk API Jeremy Kerr 2011-01-11 2:16 ` Jeremy Kerr 2011-01-11 2:16 ` Jeremy Kerr 2011-01-11 3:15 ` Paul Mundt 2011-01-11 3:15 ` Paul Mundt 2011-01-11 3:15 ` Paul Mundt 2011-01-11 4:11 ` Jeremy Kerr 2011-01-11 4:11 ` Jeremy Kerr 2011-01-11 4:11 ` Jeremy Kerr 2011-01-11 4:54 ` Paul Mundt 2011-01-11 4:54 ` Paul Mundt 2011-01-11 4:54 ` Paul Mundt 2011-01-20 16:32 ` Ben Dooks 2011-01-20 16:32 ` Ben Dooks 2011-01-20 16:32 ` Ben Dooks 2011-01-20 18:57 ` Russell King - ARM Linux 2011-01-20 18:57 ` Russell King - ARM Linux 2011-01-20 18:57 ` Russell King - ARM Linux 2011-01-21 3:43 ` Saravana Kannan 2011-01-21 3:43 ` Saravana Kannan 2011-01-21 3:43 ` Saravana Kannan 2011-01-21 9:31 ` Russell King - ARM Linux 2011-01-21 9:31 ` Russell King - ARM Linux 2011-01-21 9:31 ` Russell King - ARM Linux 2011-01-11 9:03 ` Sascha Hauer 2011-01-11 9:03 ` Sascha Hauer 2011-01-11 9:03 ` Sascha Hauer 2011-01-11 9:28 ` Russell King - ARM Linux 2011-01-11 9:28 ` Russell King - ARM Linux 2011-01-11 9:28 ` Russell King - ARM Linux 2011-01-11 14:34 ` Pavel Machek 2011-01-11 14:34 ` Pavel Machek 2011-01-11 14:34 ` Pavel Machek 2011-01-20 16:29 ` Ben Dooks 2011-01-20 16:29 ` Ben Dooks 2011-01-20 16:29 ` Ben Dooks 2011-01-20 18:56 ` Russell King - ARM Linux 2011-01-20 18:56 ` Russell King - ARM Linux 2011-01-20 18:56 ` Russell King - ARM Linux 2011-01-20 21:30 ` Nicolas Pitre 2011-01-20 21:30 ` Nicolas Pitre 2011-01-20 21:30 ` Nicolas Pitre 2011-01-21 2:06 ` Dima Zavin 2011-01-21 2:06 ` Dima Zavin 2011-01-21 2:06 ` Dima Zavin 2011-01-21 4:12 ` Saravana Kannan 2011-01-21 4:12 ` Saravana Kannan 2011-01-21 4:12 ` Saravana Kannan 2011-01-21 9:32 ` Russell King - ARM Linux 2011-01-21 9:32 ` Russell King - ARM Linux 2011-01-21 9:32 ` Russell King - ARM Linux 2011-01-22 1:53 ` Saravana Kannan 2011-01-22 2:24 ` Colin Cross 2011-01-22 2:56 ` Saravana Kannan 2011-01-22 9:15 ` Russell King - ARM Linux 2011-01-24 19:31 ` Saravana Kannan 2011-01-21 21:03 ` Dima Zavin 2011-01-21 21:03 ` Dima Zavin 2011-01-21 21:03 ` Dima Zavin 2011-01-21 21:53 ` Nicolas Pitre 2011-01-21 21:53 ` Nicolas Pitre 2011-01-21 21:53 ` Nicolas Pitre 2011-01-21 22:02 ` Russell King - ARM Linux 2011-01-21 22:02 ` Russell King - ARM Linux 2011-01-21 22:02 ` Russell King - ARM Linux 2011-01-21 22:28 ` Colin Cross 2011-01-21 22:28 ` Colin Cross 2011-01-21 22:28 ` Colin Cross 2011-01-21 23:21 ` Benjamin Herrenschmidt 2011-01-21 23:21 ` Benjamin Herrenschmidt 2011-01-21 23:21 ` Benjamin Herrenschmidt 2011-01-21 23:50 ` Nicolas Pitre 2011-01-21 23:50 ` Nicolas Pitre 2011-01-21 23:50 ` Nicolas Pitre 2011-01-22 1:35 ` Saravana Kannan 2011-01-22 1:35 ` Saravana Kannan 2011-01-22 1:35 ` Saravana Kannan 2011-01-22 2:22 ` Colin Cross 2011-01-22 2:22 ` Colin Cross 2011-01-22 2:22 ` Colin Cross 2011-01-21 22:29 ` Nicolas Pitre 2011-01-21 22:29 ` Nicolas Pitre 2011-01-21 22:29 ` Nicolas Pitre 2011-01-21 23:28 ` Bryan Huntsman 2011-01-21 23:28 ` Bryan Huntsman 2011-01-21 23:28 ` Bryan Huntsman 2011-01-11 9:16 ` Russell King - ARM Linux 2011-01-11 9:16 ` Russell King - ARM Linux 2011-01-11 9:16 ` Russell King - ARM Linux 2011-01-11 9:44 ` Jeremy Kerr 2011-01-11 9:44 ` Jeremy Kerr 2011-01-11 9:44 ` Jeremy Kerr 2011-01-11 10:13 ` Paul Mundt 2011-01-11 10:13 ` Paul Mundt 2011-01-11 10:13 ` Paul Mundt 2011-01-11 10:30 ` Jeremy Kerr 2011-01-11 10:30 ` Jeremy Kerr 2011-01-11 10:30 ` Jeremy Kerr 2011-01-11 12:18 ` Paul Mundt 2011-01-11 12:18 ` Paul Mundt 2011-01-11 12:18 ` Paul Mundt 2011-01-11 13:52 ` 2011-01-11 13:52 ` Uwe Kleine-König 2011-01-11 13:52 ` Uwe Kleine-König 2011-01-11 14:35 ` Jeremy Kerr 2011-01-11 14:35 ` Jeremy Kerr 2011-01-11 14:35 ` Jeremy Kerr 2011-01-12 3:25 ` Saravana Kannan 2011-01-12 3:25 ` Saravana Kannan 2011-01-12 3:25 ` Saravana Kannan 2011-01-12 7:40 ` 2011-01-12 7:40 ` Uwe Kleine-König 2011-01-12 7:40 ` Uwe Kleine-König 2011-01-12 1:54 ` Saravana Kannan 2011-01-12 1:54 ` Saravana Kannan 2011-01-12 1:54 ` Saravana Kannan 2011-01-12 2:25 ` Paul Mundt 2011-01-12 2:25 ` Paul Mundt 2011-01-12 2:25 ` Paul Mundt 2011-01-20 16:57 ` Ben Dooks 2011-01-20 16:57 ` Ben Dooks 2011-01-20 16:57 ` Ben Dooks 2011-01-20 16:53 ` Ben Dooks 2011-01-20 16:53 ` Ben Dooks 2011-01-20 16:53 ` Ben Dooks 2011-01-20 16:40 ` Ben Dooks 2011-01-20 16:40 ` Ben Dooks 2011-01-20 16:40 ` Ben Dooks 2011-01-11 10:39 ` 2011-01-11 10:39 ` Uwe Kleine-König 2011-01-11 10:39 ` Uwe Kleine-König 2011-01-11 10:47 ` Russell King - ARM Linux 2011-01-11 10:47 ` Russell King - ARM Linux 2011-01-11 10:47 ` Russell King - ARM Linux 2011-01-11 10:56 ` 2011-01-11 10:56 ` Uwe Kleine-König 2011-01-11 10:56 ` Uwe Kleine-König 2011-01-11 11:15 ` Richard Zhao 2011-01-11 11:15 ` Richard Zhao 2011-01-11 11:15 ` Richard Zhao 2011-01-20 17:02 ` Ben Dooks 2011-01-20 17:02 ` Ben Dooks 2011-01-20 17:02 ` Ben Dooks 2011-01-20 19:08 ` Russell King - ARM Linux 2011-01-20 19:08 ` Russell King - ARM Linux 2011-01-20 19:08 ` Russell King - ARM Linux 2011-01-21 0:09 ` Jassi Brar 2011-01-21 0:09 ` Jassi Brar 2011-01-21 0:09 ` Jassi Brar 2011-01-21 4:47 ` Jassi Brar 2011-01-21 4:47 ` Jassi Brar 2011-01-21 4:47 ` Jassi Brar 2011-01-21 9:39 ` Russell King - ARM Linux 2011-01-21 9:39 ` Russell King - ARM Linux 2011-01-21 9:39 ` Russell King - ARM Linux 2011-01-21 10:11 ` Jassi Brar 2011-01-21 10:11 ` Jassi Brar 2011-01-21 10:11 ` Jassi Brar 2011-01-22 4:08 ` Richard Zhao 2011-01-22 4:08 ` Richard Zhao 2011-01-22 4:08 ` Richard Zhao 2011-01-22 5:30 ` Jassi Brar 2011-01-22 5:30 ` Jassi Brar 2011-01-22 5:30 ` Jassi Brar 2011-01-21 7:16 ` Saravana Kannan 2011-01-21 7:16 ` Saravana Kannan 2011-01-21 7:16 ` Saravana Kannan 2011-01-21 9:40 ` Russell King - ARM Linux 2011-01-21 9:40 ` Russell King - ARM Linux 2011-01-21 9:40 ` Russell King - ARM Linux 2011-01-22 1:47 ` Saravana Kannan 2011-01-27 4:34 ` Saravana Kannan 2011-01-27 4:34 ` Saravana Kannan 2011-01-27 4:34 ` Saravana Kannan 2011-01-27 8:54 ` Russell King - ARM Linux 2011-01-27 8:54 ` Russell King - ARM Linux 2011-01-27 8:54 ` Russell King - ARM Linux 2011-01-27 20:30 ` Saravana Kannan 2011-01-27 20:30 ` Saravana Kannan 2011-01-27 20:30 ` Saravana Kannan 2011-01-27 20:43 ` Russell King - ARM Linux 2011-01-27 20:43 ` Russell King - ARM Linux 2011-01-27 20:43 ` Russell King - ARM Linux 2011-01-27 21:07 ` Alan Cox 2011-01-27 21:07 ` Alan Cox 2011-01-27 21:07 ` Alan Cox 2011-01-27 21:11 ` Russell King - ARM Linux 2011-01-27 21:11 ` Russell King - ARM Linux 2011-01-27 21:11 ` Russell King - ARM Linux 2011-01-27 21:15 ` Russell King - ARM Linux 2011-01-27 21:15 ` Russell King - ARM Linux 2011-01-27 21:15 ` Russell King - ARM Linux 2011-01-28 3:29 ` Saravana Kannan 2011-01-28 3:29 ` Saravana Kannan 2011-01-28 3:29 ` Saravana Kannan 2011-01-28 3:27 ` Saravana Kannan 2011-01-28 3:27 ` Saravana Kannan 2011-01-28 3:27 ` Saravana Kannan 2011-01-11 12:11 ` Jassi Brar 2011-01-11 12:23 ` Jassi Brar 2011-01-11 12:11 ` Jassi Brar 2011-01-12 2:56 ` Saravana Kannan 2011-01-12 2:56 ` Saravana Kannan 2011-01-12 2:56 ` Saravana Kannan 2011-01-12 9:03 ` Russell King - ARM Linux 2011-01-12 9:03 ` Russell King - ARM Linux 2011-01-12 9:03 ` Russell King - ARM Linux 2011-01-15 14:02 ` Christer Weinigel 2011-01-15 14:02 ` Christer Weinigel 2011-01-15 14:02 ` Christer Weinigel 2011-01-15 14:53 ` Russell King - ARM Linux 2011-01-15 14:53 ` Russell King - ARM Linux 2011-01-15 14:53 ` Russell King - ARM Linux 2011-01-15 15:03 ` 2011-01-15 15:03 ` Uwe Kleine-König 2011-01-15 15:03 ` Uwe Kleine-König 2011-01-15 15:15 ` Russell King - ARM Linux 2011-01-15 15:15 ` Russell King - ARM Linux 2011-01-15 15:15 ` Russell King - ARM Linux 2011-01-15 16:03 ` 2011-01-15 16:03 ` Uwe Kleine-König 2011-01-15 16:03 ` Uwe Kleine-König 2011-01-15 16:21 ` Russell King - ARM Linux 2011-01-15 16:21 ` Russell King - ARM Linux 2011-01-15 16:21 ` Russell King - ARM Linux 2011-01-15 16:31 ` 2011-01-15 16:31 ` Uwe Kleine-König 2011-01-15 16:31 ` Uwe Kleine-König 2011-01-16 6:59 ` Grant Likely 2011-01-16 6:59 ` Grant Likely 2011-01-16 6:59 ` Grant Likely 2011-01-15 17:07 ` Christer Weinigel 2011-01-15 17:07 ` Christer Weinigel 2011-01-15 17:07 ` Christer Weinigel 2011-01-15 17:20 ` Russell King - ARM Linux 2011-01-15 17:20 ` Russell King - ARM Linux 2011-01-15 17:20 ` Russell King - ARM Linux 2011-01-15 17:44 ` Christer Weinigel 2011-01-15 17:44 ` Christer Weinigel 2011-01-15 17:44 ` Christer Weinigel 2011-01-15 20:30 ` Russell King - ARM Linux 2011-01-15 20:30 ` Russell King - ARM Linux 2011-01-15 20:30 ` Russell King - ARM Linux 2011-01-17 1:19 ` Jeremy Kerr 2011-01-17 1:19 ` Jeremy Kerr 2011-01-17 1:19 ` Jeremy Kerr 2011-01-17 1:27 ` Jeremy Kerr 2011-01-17 1:27 ` Jeremy Kerr
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.