[PATCH 3/4] simplefb: disable dt node upon remove

Luc Verhaegen libv at skynet.be
Wed Aug 13 13:19:16 PDT 2014


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.



More information about the linux-arm-kernel mailing list