On Wed, Aug 12, 2015 at 09:46:49AM -0700, Michael Turquette wrote: > Quoting Felipe Balbi (2015-08-12 08:02:53) > > On Wed, Aug 12, 2015 at 11:11:51AM +0100, Russell King - ARM Linux wrote: > > > On Wed, Aug 12, 2015 at 01:05:58PM +0300, Grygorii Strashko wrote: > > > > On 08/12/2015 01:06 AM, Michael Turquette wrote: > > > > > Quoting Russell King - ARM Linux (2015-08-11 12:25:15) > > > > >> > > > > >> clk_enable/clk_disable _should_ be usable from atomic contexts. > > > > > > > > Thanks Russell - above is not true on -RT. > > > > > > What I'm saying is that it _should_ be true. You _should_ be able to > > > call clk_enable()/clk_disable() from atomic contexts. It's been > > > documented since forever: > > > > > > /** > > > * clk_enable - inform the system when the clock source should be running. > > > * @clk: clock source > > > * > > > * If the clock can not be enabled/disabled, this should return success. > > > * > > > * May be called from atomic contexts. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > /** > > > * clk_disable - inform the system when the clock source is no longer required. > > > * @clk: clock source > > > * > > > * Inform the system that a clock source is no longer required by > > > * a driver and may be shut down. > > > * > > > * May be called from atomic contexts. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > > > If that's not true with CCF, that's a CCF bug, not a usage bug. > > > > in that case, CCF's clock need to be converted to raw_spin_locks, that's > > the only way to prevent its locks from being reimplemented as rt > > mutexes. > > I do not keep up much with rt stuff, so I am going to ask a naive > question: is it common to simply do s/spin_lock/raw_spin_lock/g for > driver subsystems when using rt? Sounds like that is all that is > required... depends, if you want to guarantee your code isn't preemptable, then yeah. -- balbi
Attachment:
signature.asc
Description: Digital signature
