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. Noralf. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
