Re: [linux-sunxi] Re: [PATCH 4/4] simplefb: add clock handling code

[Mark Brown <broonie@kernel.org>]

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

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:
> On Sat, Sep 27, 2014 at 04:56:01PM -0700, Mike Turquette wrote:

> > With that said I think that Luc's approach is very sensible. I'm not
> > sure what purpose in the universe DT is supposed to serve if not for
> > _this_exact_case_. We have a nice abstracted driver, usable by many
> > people. The hardware details of how it is hooked up at the board level
> > can all be hidden behind stable DT bindings that everyone already uses.

> simplefb doesn't deal at all with hardware details. It simply uses what
> firmware has set up, which is the only reason why it will work for many
> people. What is passed in via its device tree node is the minimum amount
> of information needed to draw something into the framebuffer. Also note
> that the simplefb device tree node is not statically added to a DTS file
> but needs to be dynamically generated by firmware at runtime.

> If we start extending the binding with board-level details we end up
> duplicating the device tree node for the proper video device. Also note
> that it won't stop at clocks. Other setups will require regulators to be
> listed in this device tree node as well so that they don't get disabled
> at late_initcall. And the regulator bindings don't provide a method to
> list an arbitrary number of clocks in a single property in the way that
> the clocks property works.

Not really thought this through fully yet but would having phandles to
the relevant devices do the job?  Kind of lines up with Grant's idea of
having dummy drivers.

> There may be also resets involved. Fortunately the reset framework is
> minimalistic enough not to care about asserting all unused resets at
> late_initcall. And other things like power domains may also need to be
> kept on.

We might want to do that in the future, though it's not always the case
that reset is the lowest power state.

> So how about instead of requiring resources to be explicitly claimed we
> introduce something like the below patch? The intention being to give
> "firmware device" drivers a way of signalling to the clock framework
> that they need rely on clocks set up by firmware and when they no longer
> need them. This implements essentially what Mark (CC'ing again on this
> subthread) suggested earlier in this thread. Basically, it will allow
> drivers to determine the time when unused clocks are really unused. It
> will of course only work when used correctly by drivers. For the case of
> simplefb I'd expect its .probe() implementation to call the new
> clk_ignore_unused() function and once it has handed over control of the
> display hardware to the real driver it can call clk_unignore_unused() to
> signal that all unused clocks that it cares about have now been claimed.
> This is "reference counted" and can therefore be used by more than a
> single driver if necessary. Similar functionality could be added for
> other resource subsystems as needed.

One thing that makes me a bit nervous about this approach in the context
of the regulator API is the frequency with which one finds shared
supplies.  I'm not sure if it's actually a big problem in practice but
it makes me worry a bit.  We could probably just do something like make
refcounting down to zero not actually disable anything for standard
regulators to deal with it which might be an idea anyway in the context
of this sort of dodge.

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