On Mon, Sep 29, 2014 at 02:12:43PM +0100, Grant Likely wrote: > On Mon, Sep 29, 2014 at 1:57 PM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > Though there are two cases: one is to use simplefb as a means to have > > early boot messages on a graphical display (and optionally hand off to a > > real driver). The other is to use simplefb as the only framebuffer > > driver until a proper driver has been implemented. The latter would have > > the disadvantage of not allowing unused resources from being garbage > > collected at all. Then again, I don't think power consumption is going > > to be a very big issue on hardware where no proper display driver is > > available. > > When simplefb is the only framebuffer to get a platform working, it is > reasonable to have a placeholder driver that grabs the resources and > nothing else. When a real driver is implemented, and merged, the > placeholder driver should drop compatibility with the device node at > the same time. You mean the device node for the real device should be compatible with "simplefb"? One problem I see with that is that there may be multiple dummy drivers for different pieces of hardware, all of them binding to the simplefb compatible and conflicting. Also this assumes that a device tree node exists for the device. One of the reasons for using simplefb is so that you don't have to write that device tree node and its binding yet. Presumably, though, if the firmware already knows what resources are needed and generate them at runtime it should be possible to come up with a static device tree node, too. Thierry
Attachment:
pgpnOGa36zdvJ.pgp
Description: PGP signature
