On Tue, Mar 3, 2015 at 12:46 AM, Simon Glass <sjg@xxxxxxxxxxxx> wrote: > Hi, > > On 2 March 2015 at 01:41, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: >> >> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso >> <tomeu.vizoso@xxxxxxxxxxxxx> wrote: >> > As there isn't a way for the firmware on the Nyan chromebooks to hand >> > over the display to the kernel. >> >> Could this have a side-effect on models for which the firmware *does* >> hand over the display to the kernel? E.g. temporary glitch or black >> screen? >> >> This is probably ok though, as such a handing over would need to be >> documented in the firmware/kernel command line, and could thus be >> caught to disable that code block if needed. > > Is there a general way in which this hand-over is done, e.g. with a > device tree binding? simple-framebuffer has bindings that describe a framebuffer handed over by the firmware, and they look like the right way to describe this. simplefb however is a framebuffer driver - a DRM driver would need to seamlessly take over the display at some point and disable simplefb. I don't know if this is possible at the moment. Or maybe the DRM framework could look for a simple-framebuffer compatible node, extract the framebuffer information, and pass it to DRM drivers at probe time. That supposes a kernel in which simple-framebuffer is not compiled in to prevent it from taking over the display. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
