On Mon, Jul 13, 2015 at 03:59:25PM +0530, Archit Taneja wrote: > > > On 07/13/2015 01:37 PM, Daniel Vetter wrote: > >On Mon, Jul 13, 2015 at 12:07:56PM +0530, Archit Taneja wrote: > >>DRM drivers using drm_fb_helpers still call some fbdev core functions. > >>This makes the driver depend on CONFIG_FB, resulting in complicated > >>Kconfig options, and preventing us from creating a top level drm config > >>option to enable/disable FBDEV emulation. > >> > >>Create new drm_fb_helper functions that replace these fbdev functions. > >> > >>In most cases, the new helper funcs simply wrap around the original fbdev > >>functions. For a few (like framebufer_alloc), we actually do some work > >>that is currently redundant across multiple drivers. > >> > >>With these patches, the drivers don't call any fbdev functions directly. > >>They are now called through functions in drm_fb_helper.c. We will later > >>create a fbdev emulation config option to stub out the fb helpers. > >> > >>The only exception is vmwgfx driver. This doesn't use drm_fb_helper. It > >>creates a fb device how a driver in drivers/video/fbdev would. Maybe this > >>needs to be converted to use drm_fb_helpers. > >> > >>For more info, have a look at the threads: > >>http://lists.freedesktop.org/archives/dri-devel/2015-March/078729.html > >>http://lists.freedesktop.org/archives/dri-devel/2015-March/078975.html > > > >I think overall this looks really nice. I quickly fired this up on an i915 > >machine and it worked, so I pulled it all into topic/drm-misc (which is in > >linux-next) to give this the testing it needs. I'll probably do a separate > >topic branch for the pull request to Dave with the final patches. My plan > >would be to make one overall pull for step 1 plus the first patch of step > >2. Then everything else could go in through driver maintainers like usual > >I think. > > Okay. That sounds good to me too. I'll fix up the comments and the warnings > thrown by the kbuild bot. > > There was an initial Kconfig clean up patch set 'drm/misc: Kconfig cleanup' > that will make the remainder steps easier to pull. Could we try to get that > in too? I think we only need that once we pull in the driver-specific parts for step2&3, right? Personally I don't really care about the Kconfig organization all that much, so I'd like to see some Acks from other maintainers before I pull that in. If that happens I can pull in the patches for old/legacy drivers into topic/drm-misc sure. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
