Locking in the clk API, part 2: clk_prepare/clk_unprepare

[Uwe Kleine-König]

Hello,

On Tue, Feb 01, 2011 at 12:21:45PM -0800, Saravana Kannan wrote:
> If the driver is calling clk_prepare() right next to clk_enable()
> knowing it's been already prepared and will hence be "atomic" (this
> is actually not true), then by your description, it's pointless to
> call clk_prepare().
Well not completely, as it increases the reference count.  The advantage
would be that clk_enable counts addionally as prepare, so it would be
impossible to unprepare an enabled clock.  And the other way round an
unprepared clock would never be enabled.
 
> If you want the driver to call clk_prepare() in atomic context
> because it will be atomic in most cases -- well, that's wrong. It's
> either atomic or is NOT atomic. There is no in between. If a call is
> NOT atomic, it can't be called in atomic context. Long story short,
> if you expect clk_prepare() to be atomic under any circumstance, it
> beats the point of introducing clk_prepare().
Well, with my suggestion it's atomic when certain precondions are given.
IMHO that's better than "atomic in most cases" because the caller can
assert that everything goes smooth.
These preconditions are asserted when the driver writer is careful
enough to stick to the API.

Either my idea is bad or I'm unable to sell it appropriately.  Be it as
it is, I will stop to make a case for it.

Best regards and thanks for your try,
Uwe

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