[PATCH] drm/arm/hdlcd: Take over EFI framebuffer properly

[Liviu Dudau]

On Wed, Jun 15, 2022 at 10:00:52AM +0200, Javier Martinez Canillas wrote:
> On 6/15/22 09:53, Thomas Zimmermann wrote:
> > 
> > 
> > Am 15.06.22 um 09:50 schrieb Javier Martinez Canillas:
> > [...]
> >>> Historically, most drivers call this function very early. But for error
> >>> recovery it would be better to do it as late as possible.  Ideally,
> >>> drivers would first initialize their DRM software state, then kickout
> >>> the generic driver, and finally take over hardware. But that would
> >>> require a careful review of each driver. :/
> >>>
> >>
> >> We got bug reports on Fedora about regressions caused by the fact that some
> >> programs made the (wrong) assumption that /dev/dri/card0 would be the "main"
> >> display and just hard-coded that path.
> > 
> > Shh! Don't tell anyone.
> >
> 
> :)
> 
> What I tried to say is that deciding where to kick out the firmware-provided
> framebuffer isn't trivial and would just land the patch as is. At some point
> we should probably agree on the best place and audit all the drivers to make
> sure that are doing it properly. 

I agree, we should review v2 with the updated API and land the patch if it is
reasonable. Due to my "cleverness" HDLCD and mali-dp are probably the only drivers
that also use the component framework that adds extra complications in terms of
silently not having all dependencies met (you forgot to compile the I2C driver or you
didn't load it as a module), so taking over the efifb framebuffer late is a good
idea.

Best regards,
Liviu

> 
> -- 
> Best regards,
> 
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯