From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC 10/21] drm/qxl: Remove FB_KMS_HELPER and FB related config options Date: Mon, 13 Jul 2015 09:38:28 +0200 Message-ID: <20150713073828.GN3736@phenom.ffwll.local> References: <1436769848-4990-1-git-send-email-architt@codeaurora.org> <1436769848-4990-11-git-send-email-architt@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-wi0-f182.google.com ([209.85.212.182]:35368 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751507AbbGMHfo (ORCPT ); Mon, 13 Jul 2015 03:35:44 -0400 Received: by wiga1 with SMTP id a1so60788994wig.0 for ; Mon, 13 Jul 2015 00:35:43 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1436769848-4990-11-git-send-email-architt@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Archit Taneja Cc: dri-devel@lists.freedesktop.org, daniel@ffwll.ch, linux-arm-msm@vger.kernel.org, airlied@linux.ie, Frediano Ziglio , Maarten Lankhorst On Mon, Jul 13, 2015 at 12:13:57PM +0530, Archit Taneja wrote: > Remove FB_* config options since the driver doesn't call any fbdev > functions directly. > > Remove FB_KMS_HELPER as this would now be selected by the top level > FBDEV_EMULATION config option. If the fbdev emulation isn't selected, > the drm_fb_helper functions will be stubbed out. > > The code relying on DEFERRED_IO can't be stubbed out using drm_fb_helper > functions. This is because the deferred io members in fbdev core structs > are defined based on whether FB_DEFERRED_IO is defined or not. > > For now, wrap around deferred io code with an #ifdef check for > CONFIG_DEFERRED_IO. We could consider creating stub fb helper functions > here, but this would require some changes in the core fbdev structs. Yeah if more drivers grow a ->dirty callback that does something we'd probably want to pull all that code out of qxl/udl into core fbdev. i915 now also has a dirty callback, but for fbcon we're going with a slightly different options: Since all our frontbuffer dirtying are for optional features we just disable them right now. Anyway just an idea for future patches when someone works in this area. For now I think we simply have to select the relevant options if FBDEV emulation is enabled. > > Cc: David Airlie > Cc: Frediano Ziglio > Cc: Maarten Lankhorst > > Signed-off-by: Archit Taneja > --- > drivers/gpu/drm/qxl/Kconfig | 5 ----- > drivers/gpu/drm/qxl/qxl_fb.c | 4 ++++ > 2 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig > index 38c2bb7..da45b11 100644 > --- a/drivers/gpu/drm/qxl/Kconfig > +++ b/drivers/gpu/drm/qxl/Kconfig > @@ -1,12 +1,7 @@ > config DRM_QXL > tristate "QXL virtual GPU" > depends on DRM && PCI > - select FB_SYS_FILLRECT > - select FB_SYS_COPYAREA > - select FB_SYS_IMAGEBLIT > - select FB_DEFERRED_IO I.e. select FB_DEFERRED_IO if DRM_FBDEV_EMULATION > select DRM_KMS_HELPER > - select DRM_KMS_FB_HELPER > select DRM_TTM > select CRC32 > help > diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c > index 41c422f..9391dfe 100644 > --- a/drivers/gpu/drm/qxl/qxl_fb.c > +++ b/drivers/gpu/drm/qxl/qxl_fb.c > @@ -163,6 +163,7 @@ static void qxl_dirty_update(struct qxl_fbdev *qfbdev, > schedule_work(&qdev->fb_work); > } > > +#ifdef CONFIG_FB_DEFERRED_IO and using CONFIG_DMR_FBDEV_EMULATION here instead. Same for udl changes. -Daniel > static void qxl_deferred_io(struct fb_info *info, > struct list_head *pagelist) > { > @@ -191,6 +192,7 @@ static struct fb_deferred_io qxl_defio = { > .delay = QXL_DIRTY_DELAY, > .deferred_io = qxl_deferred_io, > }; > +#endif > > static void qxl_fb_fillrect(struct fb_info *info, > const struct fb_fillrect *rect) > @@ -420,8 +422,10 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev, > goto out_destroy_fbi; > } > > +#ifdef CONFIG_FB_DEFERRED_IO > info->fbdefio = &qxl_defio; > fb_deferred_io_init(info); > +#endif > > qdev->fbdev_info = info; > qdev->fbdev_qfb = &qfbdev->qfb; > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch