[PATCH] simplefb: Disable at runtime when a native driver (vc4) is present.
eric at anholt.net
Tue Apr 19 13:23:53 PDT 2016
Hans de Goede <hdegoede at redhat.com> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 818 bytes
Desc: not available
More information about the linux-rpi-kernel