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:

quoted

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/c154322c/attachment.sig>