On 29 September 2014 17:19, Thierry Reding [off-list ref] wrote:

On Tue, Sep 30, 2014 at 12:46:11AM +1000, Julian Calaby wrote:

quoted

quoted

quoted

On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding
[off-list ref] wrote:

quoted

On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote:

quoted

On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote:

[...]

quoted

quoted

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.

Which makes the whole even simpler, since the firmware already knows
all about which clocks it had to enable.

It makes things very complicated in the firmware because it now needs to
be able to generate DTB content that we would otherwise be able to do
much easier with a text editor.

As far as the kernel is concerned, this is a solved problem.

It's not completely solved. There's still the issue of no generic way to
specify regulators like you can do for clocks, resets or power domains.
But the kernel isn't the real issue here. The issue is the firmware that
now has to go out of its way not only to initialize display hardware but
also create device tree content just to make Linux not turn everything
off.

My point is that the firmware is going to be doing complicated stuff
already, adding and using some helpers to configure a device tree node
is relatively simple in comparison to dealing with the actual
hardware. It wouldn't surprise me if u-boot, for example, ended up
with a set of functions to handle this exact case as more graphics
hardware gets brought up.

Not all firmware is based on U-Boot. Essentially whatever binding
changes we make will need to be implemented in all firmware. And the
complexity isn't so much about writing the actual DT data, but more
about figuring out which data to write. Every firmware image needs to
know exactly which clocks and other resources to transcribe for a given
board. It'll essentially need to contain some sort of "driver" for each
device that parses a DTB, correlates the data to what it knows of the
device internals and write a subset of that data back into the DTB in a
slightly different format. That's just whacky.

DT was meant to simplify things.

The firmware only needs to implement DT parsing and writing if it
wants to communicate the configuration it set up to the kernel. If you
do not have control over the firmware or do not want to write support
for the firmware to generate the DT you can produce a fixed
configuration DT and have the firmware load that with the kernel. It
is fully backwards compatible with dumb firmware that does not support
DT modification during boot. You will just need a different DT for
slightly different devices (eg. tablets with different display) or
different configurations of same device (eg. different displays
connected to the HDMI port of your devboard).

quoted

I'm sure that as hardware diversifies, the other subsystems will grow
in similar directions and eventually be dealt with using similarly
generic code.

For regulators this already works very differently. As opposed to the
clocks/clock-names type of binding it uses one where the consumer name
of the regulator comes from the prefix of a -supply property. That is
you'd get something like this:

        foo-supply = <&reg1>;
        bar-supply = <&reg2>;

And since you don't have enough information in the kernel simplefb
driver to attach any meaning to these, the best you can do would be
iterating over a range and have:

        0-supply = <&reg0>;
        1-supply = <&reg1>;
        ...
        n-supply = <&reg2>;

This is made more difficult by the fact that these regulators may be
required by components not immediately related to the display engine.
They could be for an attached panel, a video bridge or the +5V pin on
the HDMI connector.

So you are saying that listing the properties of the simplefb node and
filtering foo-supply and bar-supply out of that is too difficult?

I hope kernel development did not get this dumb.

Thanks

Michal