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.