From: Daniel Vetter <daniel@ffwll.ch>
To: Archit Taneja <architt@codeaurora.org>
Cc: dri-devel@lists.freedesktop.org, daniel@ffwll.ch,
linux-arm-msm@vger.kernel.org, airlied@linux.ie,
Frediano Ziglio <fziglio@redhat.com>,
Maarten Lankhorst <maarten.lankhorst@canonical.com>
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 [thread overview]
Message-ID: <20150713073828.GN3736@phenom.ffwll.local> (raw)
In-Reply-To: <1436769848-4990-11-git-send-email-architt@codeaurora.org>
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 <airlied@linux.ie>
> Cc: Frediano Ziglio <fziglio@redhat.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
>
> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> ---
> 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
next prev parent reply other threads:[~2015-07-13 7:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 6:43 [RFC 00/21] drm: fb emulation: Step 3: Remove FB_KMS_HELPER config from drivers Archit Taneja
2015-07-13 6:43 ` [RFC 01/21] drm/cirrus: Remove FB_KMS_HELPER and FB related config options Archit Taneja
2015-07-13 6:43 ` [RFC 02/21] drm/rockchip: " Archit Taneja
2015-07-13 6:43 ` [RFC 03/21] drm/armada: " Archit Taneja
2015-07-13 6:43 ` [RFC 04/21] drm/ast: " Archit Taneja
2015-07-13 6:43 ` [RFC 05/21] drm/omap: " Archit Taneja
2015-08-01 10:02 ` Laurent Pinchart
2015-08-05 7:04 ` Archit Taneja
2015-07-13 6:43 ` [RFC 06/21] drm/exynos: " Archit Taneja
2015-07-13 6:43 ` [RFC 07/21] drm/gma500: " Archit Taneja
2015-07-13 6:43 ` [RFC 08/21] drm/mgag200: " Archit Taneja
2015-07-13 6:43 ` [RFC 09/21] drm/radeon: " Archit Taneja
2015-07-13 6:43 ` [RFC 10/21] drm/qxl: " Archit Taneja
2015-07-13 7:38 ` Daniel Vetter [this message]
2015-07-13 6:43 ` [RFC 11/21] drm/nouveau: " Archit Taneja
2015-07-13 6:43 ` [RFC 12/21] drm/udl: " Archit Taneja
2015-07-13 6:44 ` [RFC 13/21] drm/bochs: " Archit Taneja
2015-07-13 6:44 ` [RFC 14/21] drm/amdgpu: " Archit Taneja
2015-07-13 6:44 ` [RFC 15/21] drm/virtio: " Archit Taneja
2015-07-13 6:44 ` [RFC 16/21] drm/fb_cma_helper: " Archit Taneja
2015-07-13 6:44 ` [RFC 17/21] drm/atmel-hlcdc: Remove FB_KMS_HELPER config option Archit Taneja
2015-07-13 6:44 ` [RFC 18/21] drm/imx: " Archit Taneja
2015-07-13 6:44 ` [RFC 19/21] drm/rcar-du: " Archit Taneja
2015-08-01 10:02 ` Laurent Pinchart
2015-07-13 6:44 ` [RFC 20/21] drm/shmobile: " Archit Taneja
2015-08-01 10:02 ` Laurent Pinchart
2015-07-13 6:44 ` [RFC 21/21] drm/tilcdc: " Archit Taneja
2015-07-13 15:30 ` [RFC 00/21] drm: fb emulation: Step 3: Remove FB_KMS_HELPER config from drivers Alex Deucher
2015-07-13 15:37 ` Daniel Vetter
2015-07-14 6:31 ` Archit Taneja
2015-07-14 7:32 ` Daniel Vetter
2015-07-14 8:02 ` Thierry Reding
2015-07-14 8:23 ` Archit Taneja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150713073828.GN3736@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=fziglio@redhat.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=maarten.lankhorst@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox