Hi Noralf Am 07.04.20 um 13:02 schrieb Noralf Trønnes: > > > Den 06.04.2020 15.43, skrev Thomas Zimmermann: >> Generic fbdev emulation is a DRM client. If possible, it should behave >> like userspace clients. Therefore it should not run before the driver >> registered the new DRM device. If the setup function fails, the driver >> should not report an error. >> >> This is a follow-up patchset to the discussion at [1]. I went >> through all calls to drm_fbdev_generic_setup(), moved them to the >> final operation of their driver's probe function, and removed the >> return value. >> >> Built-tested on x86-64, aarch64 and arm. >> >> [1] https://lore.kernel.org/dri-devel/20200403135828.2542770-1-daniel.vetter@xxxxxxxx/T/#m216b5b37aeeb7b28d55ad73b7a702b3d1d7bf867 >> > > Thanks for doing this, series is: > > Reviewed-by: Noralf Trønnes <noralf@xxxxxxxxxxx> > > With so many drivers using generic fbdev I wondered if we could make it > the default and let DRM core handle it (would pull drm_fb_helper into > drm.ko). > > Something like this at the end of drm_dev_register(): > > if (!dev->fb_helper) > drm_fbdev_generic_setup(dev, 0); > > AFAICS all drivers that don't use generic fbdev, do fbdev setup before > calling drm_dev_register() except msm so that would need some > adjustment, calling drm_fb_helper_init() before drm_dev_register() would do. > > One missing piece is for drivers (like vc4) that uses 16 bpp on fbdev to > save on memory, not sure how that should be handled, an optional > drm_mode_config->fbdev_bpp maybe. > > Having DRM core take care of fbdev emulation was an idea Laurent had > which was the spark that set me off making the generic fbdev emulation. > > Maybe it's still too early to make this move, I don't know. I think we should wait a bit. As you mentioned, there are drivers that have an fbdev bpp that differs from the preferred one. There might also be a chicken-and-egg problem with core and fb-helper modules. Additionally, we should think about possible other in-kernel clients (e.g., the bootsplash) and how they would interact with such defaults. At some later point, we could introduce an interface that sets up all available in-kernel clients. Best regards Thomas > > Noralf. > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
