On Wed, Oct 26, 2016 at 09:15:15PM +0200, Daniel Vetter wrote:
> On Wed, Oct 26, 2016 at 8:47 PM, Stefan Lengfeld
> <contact@xxxxxxxxxxxxxxx> wrote:
> >
> > On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote:
> >> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote:
> >> > Cc: Dave Airlie <airlied@xxxxxxxxxx>
> >> > Signed-off-by: Stefan Christ <contact@xxxxxxxxxxxxxxx>
> >> > ---
> >> > drivers/gpu/drm/ast/ast_fb.c | 6 +-----
> >> > 1 file changed, 1 insertion(+), 5 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> >> > index c017a93..b604fdd 100644
> >> > --- a/drivers/gpu/drm/ast/ast_fb.c
> >> > +++ b/drivers/gpu/drm/ast/ast_fb.c
> >> > @@ -150,14 +150,10 @@ static void ast_imageblit(struct fb_info *info,
> >> >
> >> > static struct fb_ops astfb_ops = {
> >> > .owner = THIS_MODULE,
> >> > - .fb_check_var = drm_fb_helper_check_var,
> >> > - .fb_set_par = drm_fb_helper_set_par,
> >> > + DRM_FB_HELPER_DEFAULT_OPS,
> >> > .fb_fillrect = ast_fillrect,
> >> > .fb_copyarea = ast_copyarea,
> >> > .fb_imageblit = ast_imageblit,
> >>
> >> Ah, here's the likely reason for not sharing these, ast/cirrus have their
> >> special dirtying stuff for fbdev emulation. And because the fbdev mmap
> >> must have a stable pointer it can't use the ttm bo mmap magic of
> >> automatically picking the right place for the mmap.
> >>
> >> I'd say just leave these 2 drivers out as special cases.
> >> -Daniel
> >
> > Hmm. There are even more drivers using special implementations like the
> > mgag200 using function mga_fillrect(), which is a wrapper around
> > drm_fb_helper_sys_fillrect().
>
> Hm, mga_fillrect is like ast/cirrus.
>
> > Even if the drivers ast/cirrus/.. are left out, there are still two
> > different fb_fillrect, fb_copyarea and fb_imageblit implementations:
> > 1/ drm_fb_helper_sys_*() and
> > 2/ drm_fb_helper_cfb_*()
> > used by different drivers. I don't know which one should be preferred.
>
> Hm, every day I learn something new about fbdev. Totally missed that
> there's 2 different kinds of helpers, and I think we do indeed need
> both.
>
> > Including fb_debug_enter and fb_debug_leave in DRM_FB_HELPER_DEFAULT_OPS
> > is not a problem since there is only a single implementation yet.
> >
> > Should I resend this series (without the first patch), but with
> > additional memebers fb_debug_enter and fb_debug_leave?
>
> Yeah I think that'd be reasonable. For the sys/cfb stuff, what about
> adding new #defines for those 2, e.g. DRM_FB_HELPER_SYS_OPS and
> DRM_FB_HELPER_CFB_OPS? Maybe as a follow-up series of course, if you
> have time. When resending please pick up the acks/reviews from this
> series (but annoted with a v1 or so.
Are you still working on a v2, or should I just pick up v1 for now?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
