On Mon, Sep 29, 2014 at 09:00:01PM +1000, Julian Calaby wrote:

Hi Thierry,

If you address people directly please make sure they are in the To:
line. Or at least Cc.

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.

Firmware is going to be doing some dark magic to set up the hardware
to be a dumb frame buffer and some other stuff to add the simplefb
device node - so by this point, adding the clocks (or whatever)
required by the hardware should be fairly uncomplicated - the firmware
already knows the hardware intimately. As for the actual device tree
manipulations, U-boot (or whatever) will probably just grow some
helper functions to make this simple.

Have you looked at the code needed to do this? It's not at all trivial.
And the point is really that all this information is there already, so
we're completely duplicating this into a dynamically created device tree
node and for what reason? Only to have one driver request all these
resources and have them forcefully released a few seconds later.

Alternatively, it could simply add the relevant data to an existing
device node and munge it's compatible property so simplefb picks it
up.

Yes, I think that'd be a much better solution. Of course it's going to
be very difficult to make that work with a generic driver because now
that generic driver needs to parse the DT binding for any number of
"compatible" devices.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140929/a6e9e08a/attachment.sig>