Re: [PATCH] simplefb: Disable at runtime when a native driver (vc4) is present.

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

Hans de Goede <hdegoede@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]