Hans de Goede <hdegoede@xxxxxxxxxx> writes: > Hi Eric, > > On 04/19/2016 09:19 PM, Eric Anholt wrote: >> With simplefb and vc4 both enabled, simplefb would probe first and be >> fb0, displaying for a moment before vc4 probed fb1 and reconfigured >> the graphics hardware so that only its fbdev worked. > > The way this is supposed to work (theoretically you're the first > one to hit this on ARM) is that you call remove_conflicting_framebuffers() > from the probe of your driver. > > simplefb can only be built-in and uses fs_initcall() to register itself, > so that it becomes available early on, so it should always be probed > before the vc4 driver. > > When we discussed how all of this should fit together (again theoretically) > at ELCE 2014, we decided to follow what the x86 kms driver do here, the > idea was that u-boot would set up a console (so that the user can interact > with u-boot / see error messages without hooking up a serial console) and > then simplefb would pick up the u-boot console asap, so that the kernel > can show error msg. This is esp. important for the Debian / Fedora ARM > images where things like the vc4 driver will be a module and we want > the user to see errors from the initrd if things go wrong before loading > e.g. the vc4 module. > > So the boot sequence would be: > > 1) u-boot configures a framebuffer, shows msgs there > 2) kernel brings on builtin simplefb early, shows msgs that way > 3) vc4 driver loads calls remove_conflicting_framebuffers which should > disable/remove the simplefb framebuffer > 4) vc4 driver register its own framebuffer, kernel msgs get displayed there > > I hope this makes sense, let me know if you've any questions. I hadn't seen this in the other ARM drivers, so I hadn't found that solution. Looks like it works fine, the only funny part being that I have to use 0 to ~0 for my aperture because it's a UMA system.
Attachment:
signature.asc
Description: PGP signature
