On Wed, Aug 26, 2015 at 01:34:58PM +0200, Daniel Vetter wrote: > On Wed, Aug 26, 2015 at 02:14:37PM +0530, Archit Taneja wrote: > > > > > > On 08/26/2015 10:42 AM, Archit Taneja wrote: > > > > > > > > >On 08/25/2015 07:15 PM, Daniel Vetter wrote: > > >>Faster than recompiling. > > >> > > >>Note that restore_fbdev_mode_unlocked is a bit special and the only > > >>one which returns an error code when fbdev isn't there - i915 needs > > >>that one to not fall over with some additional fbcon related restore > > >>code. Everyone else just ignores the return value or only prints a > > >>DRM_DEBUG level message. > > > > > >Reviewed-by:Archit Taneja <architt@xxxxxxxxxxxxxx> > > > > > > With the module param, and the drivers should see the following state( > > based on the truth table below): > > > > module param | config option > > true | true -> real helper funcs called, driver > > allocated drm_fb_helper is correctly > > populated. > > > > false | true -> real helper funcs called, but bailed > > out early, driver allocated > > drm_fb_helper is non-NULL, but we won't > > end up using it. > > Hm I tried to give drivers the same semantics here as with the stub > functions. Where did I screw up? The goal really was to match the end > result for drivers ... Note that at least for i915 we can't make it perfectly equal since i915 compiles out a few more things with FBDEV_EMULATION=n than just the stubs. Long-term we might want to push some of that into helpers too perhaps. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
