Re: [PATCH RFC RFT 0/3] clk: detect per-user enable imbalances and implement hand-off

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

On Wed, Sep 30, 2015 at 05:36:49AM -0700, Michael Turquette wrote:
> Quoting Maxime Ripard (2015-08-28 20:55:57)
> > Hi Mike,
> > 
> > On Tue, Aug 25, 2015 at 02:50:51PM -0700, Michael Turquette wrote:
> > > Quoting Maxime Ripard (2015-08-20 08:15:10)
> > > > On Tue, Aug 18, 2015 at 09:43:56AM -0700, Michael Turquette wrote:
> > > > > Quoting Maxime Ripard (2015-08-18 08:45:52)
> > > > > > Hi Mike,
> > > > > > 
> > > > > > On Fri, Aug 07, 2015 at 12:09:27PM -0700, Michael Turquette wrote:
> > > > > > > All of the other kitchen sink stuff (DT binding, passing the flag back
> > > > > > > to the framework when the clock consumer driver calls clk_put) was left
> > > > > > > out because I do not see a real use case for it. If one can demonstrate
> > > > > > > a real use case (and not a hypothetical one) then this patch series can
> > > > > > > be expanded further.
> > > > > > 
> > > > > > I think there is a very trivial use case for passing back the
> > > > > > reference to the framework, if during the probed, we have something
> > > > > > like:
> > > > > > 
> > > > > > clk = clk_get()
> > > > > > clk_prepare_enable(clk)
> > > > > > foo_framework_register()
> > > > > > 
> > > > > > if foo_framework_register fails, the sensible thing to do would be to
> > > > > > call clk_disable_unprepare. If the clock was a critical clock, you
> > > > > > just gated it.
> > > > > 
> > > > > Hmm, a good point. Creating the "pass the reference back" call is not
> > > > > hard technically. But how to keep from abusing it? E.g. I do not want
> > > > > that call to become an alternative to correct use of clk_enable.
> > > > > 
> > > > > Maybe I'll need a Coccinelle script or just some regular sed to
> > > > > occasionally search for new users of this api and audit them?
> > > > > 
> > > > > I was hoping to not add any new consumer api at all :-/
> > > > 
> > > > I don't think there's any abuse that can be done with the current API,
> > > > nor do I think you need to have new functions either.
> > > > 
> > > > If the clock is critical, when the customer calls
> > > > clk_unprepare_disable on it, simply take back the reference you gave
> > > > in the framework, and you're done. Or am I missing something?
> > > 
> > > Maybe I am the one missing something? My goal was to allow the consumer
> > > driver to gate the critical clock. So we need clk_disable_unused to
> > > actually disable the clock for that to work.
> > 
> > Yeah, but I guess the consumer driver clock gating is not the default
> > mode of operations.
> > 
> > Under normal circumstances, it should just always leave the clock
> > enabled, all the time.
> > 
> > > I think you are suggesting that clk_disable_unused should *not* disable
> > > the clock if it is critical. Can you confirm that?
> > 
> > By default, yes.
> > 
> > Now, we also have the knowledgeable driver case wanting to force the
> > clock gating. I think it's an orthogonal issue, we might have the same
> > use case for non-critical clocks, and since it's hard to get that done
> > with the current API, and that we don't really know what a
> > knowledgeable driver will look like at this point, maybe we can just
> > delay this entirely until we actually have one in front of us?
> 
> Yes. I discussed this face to face with Lee last week at Linaro Connect.
> I proposed the following:
> 
> 1) support an always-on clk, which is enabled by the framework at
> registration-time and can never be claimed and gated
> 
> 2) support a hand-off clk, which is enabled by the framework at
> registration-time and whose reference counts are handed off to the first
> driver to get, prepare and enable this clk
> 
> 3) forget about knowledgeable drivers because nobody needs this (yet)
> 
> Lee was happy with this. Does it sound OK to you?

Yep, it sounds good!

See you in Dublin,

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]