Re: [PATCH 00/25] drm: fb emulation: Step 1: Create new drm_fb_helper wrapper funcs

[Daniel Vetter <daniel@ffwll.ch>]

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