Hi Thierry, On Mon, Sep 29, 2014 at 11:21 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > 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. Sorry about that, the mailing list I received this through (Google Groups based) generally strips to: and CC: lines, so my mail client (Gmail) doesn't do it automatically. I'm still getting used to it. >> On Mon, Sep 29, 2014 at 8:18 PM, Thierry Reding >> <thierry.reding@xxxxxxxxx> wrote: >> > On Mon, Sep 29, 2014 at 11:23:01AM +0200, Maxime Ripard wrote: >> >> On Mon, Sep 29, 2014 at 10:06:39AM +0200, Thierry Reding wrote: >> > [...] >> >> > 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. >> 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. Not necessarily. The patch that started this discussion can work with any number of clocks specified in a "clocks" property. Therefore all that needs to happen is that the final hardware binding specifies it's clocks that way. This is how, for example, the ahci_platform driver's clock code works. I'm sure that as hardware diversifies, the other subsystems will grow in similar directions and eventually be dealt with using similarly generic code. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
