On Wed, Aug 13, 2014 at 09:00:07PM +0100, Grant Likely wrote: > > Both of which make sense and should be supported, so I agree we need > to find a solution. > > The problem I think comes down to the handoff mechanism. There are a > lot of different video controllers which could all be configured for a > simple framebuffer. > > I don't think the "run this only once" test is the right approach. > Sometimes the simple framebuffer will never be torn down. It is > conceivable that a simple framebuffer will get /added/ at runtime with > an overlay, or even rebound to the driver. The simple framebuffer > driver really needs to be explicitly told from outside itself that it > is being taken over since it doesn't actually have the information to > know when a framebuffer becomes invalid. Only the real video driver > can provide that information. There really are two separate issues here: 1) making sure that nothing tries to use the freshly died simplefb again. 2) doing a clean handover to another, usually hw specific, driver. 1 is what i hoped to superficially solve with this patch. 2 can be very smart about things as the replacement driver actually should know the hw. I kind of like the idea of an "only-once" (there must be a better name for this) property. This allows the driver/device infrastructure to handle things much more cleanly, and allows me to state this from u-boot for sunxi, while Stephen wouldn't need to for rpi. I currently don't know how or where this could be handled, i just know that this smells like a decent solution which could solve my concern while at least avoiding the probe issue you mentioned earlier. > How does the sunxi driver currently take over from the simplefb? Not at all. A big blob of KMS code exists for our sunxi-3.4 kernel, where i can load the original display driver quickly and easily. This tree predates most of DT. I was rather hoping that the simplefb stop-gap didn't require me to have fully engineered everything yesterday already. Luc Verhaegen. -- 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
