LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Archit Taneja <architt@codeaurora.org>
To: robdclark@gmail.com, airlied@linux.ie, treding@nvidia.com,
p.zabel@pengutronix.de, benjamin.gaignard@linaro.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, daniel@ffwll.ch
Subject: Re: [RFC 3/6] drm/i915: Remove local fbdev emulation Kconfig option
Date: Tue, 10 Mar 2015 15:40:56 +0530 [thread overview]
Message-ID: <54FEC330.4050005@codeaurora.org> (raw)
In-Reply-To: <20150310100126.GF3800@phenom.ffwll.local>
On 03/10/2015 03:31 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:11:30PM +0530, Archit Taneja wrote:
>> DRM_I915_FBDEV config is currently used to enable/disable fbdev emulation for
>> the i915 kms driver.
>>
>> Replace this with the top level DRM_FBDEV_EMULATION config option. Using this
>> config lets us also prevent wrapping around drm_fb_helper_* calls with #ifdefs
>> in certain places.
>>
>> The #ifdef in drm_i915_private struct adding/removing members intel_fbdev and
>> fbdev_suspend_work has been removed. This helps us use stub drm helper functions
>> at not much cost.
>>
>> Signed-off-by: Archit Taneja <architt@codeaurora.org>
>> ---
>> drivers/gpu/drm/i915/Kconfig | 15 ---------------
>> drivers/gpu/drm/i915/Makefile | 4 ++--
>> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>> drivers/gpu/drm/i915/i915_drv.h | 2 --
>> drivers/gpu/drm/i915/intel_display.c | 10 ++++------
>> drivers/gpu/drm/i915/intel_dp_mst.c | 14 ++++++++------
>> drivers/gpu/drm/i915/intel_drv.h | 3 +--
>> drivers/gpu/drm/i915/intel_fbdev.c | 7 -------
>> 8 files changed, 16 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 74acca9..bd9ccfc 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -45,21 +45,6 @@ config DRM_I915_KMS
>>
>> If in doubt, say "Y".
>>
>> -config DRM_I915_FBDEV
>> - bool "Enable legacy fbdev support for the modesetting intel driver"
>> - depends on DRM_I915
>> - select DRM_KMS_FB_HELPER
>> - select FB_CFB_FILLRECT
>> - select FB_CFB_COPYAREA
>> - select FB_CFB_IMAGEBLIT
>> - default y
>> - help
>> - Choose this option if you have a need for the legacy fbdev
>> - support. Note that this support also provide the linux console
>> - support on top of the intel modesetting driver.
>> -
>> - If in doubt, say "Y".
>> -
>> config DRM_I915_PRELIMINARY_HW_SUPPORT
>> bool "Enable preliminary support for prerelease Intel hardware by default"
>> depends on DRM_I915
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index f019225..3b3325d 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -56,8 +56,8 @@ i915-y += intel_audio.o \
>> intel_psr.o \
>> intel_sideband.o \
>> intel_sprite.o
>> -i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
>> -i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
>> +i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
>> +i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
>>
>> # modesetting output/encoder code
>> i915-y += dvo_ch7017.o \
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
>> index e8b18e5..0c8bcd7 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -1772,7 +1772,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m, void *data)
>> struct intel_fbdev *ifbdev = NULL;
>> struct intel_framebuffer *fb;
>>
>> -#ifdef CONFIG_DRM_I915_FBDEV
>> +#ifdef CONFIG_DRM_FBDEV_EMULATION
>> struct drm_i915_private *dev_priv = dev->dev_private;
>>
>> ifbdev = dev_priv->fbdev;
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index 8727086..e511fa4 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1819,11 +1819,9 @@ struct drm_i915_private {
>>
>> struct drm_i915_gem_object *vlv_pctx;
>>
>> -#ifdef CONFIG_DRM_I915_FBDEV
>> /* list of fbdev register on this device */
>> struct intel_fbdev *fbdev;
>> struct work_struct fbdev_suspend_work;
>> -#endif
>>
>> struct drm_property *broadcast_rgb_property;
>> struct drm_property *force_audio_property;
>> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
>> index e730789..9cf13e6 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -8562,7 +8562,6 @@ static struct drm_framebuffer *
>> mode_fits_in_fbdev(struct drm_device *dev,
>> struct drm_display_mode *mode)
>> {
>> -#ifdef CONFIG_DRM_I915_FBDEV
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> struct drm_i915_gem_object *obj;
>> struct drm_framebuffer *fb;
>> @@ -8585,9 +8584,6 @@ mode_fits_in_fbdev(struct drm_device *dev,
>> return NULL;
>>
>> return fb;
>> -#else
>> - return NULL;
>> -#endif
>
> Won't this now blow up if there's no fbdev? Tbh I prefer a patch to just
> replace the CONFIG_ #define and then maybe a 2nd one on top to clean
> things up if you feel like. Same for the other changes in this patch.
There are checks for dev_priv->fbdev and dev_priv->fbdev->fb being non
NULL at the start of the function which would prevent that. But you're
right, the first patch for each device can replace the config, the later
ones can take advantage of the stub functions.
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-03-10 10:11 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-10 9:41 [RFC 0/6] drm: Add DRM_FBDEV_EMULATION Kconfig option Archit Taneja
2015-03-10 9:41 ` [RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation Archit Taneja
2015-03-10 9:46 ` Daniel Vetter
2015-03-10 9:54 ` Archit Taneja
2015-03-10 9:47 ` Daniel Vetter
2015-03-10 9:52 ` Archit Taneja
2015-03-10 10:05 ` Daniel Vetter
2015-03-10 10:22 ` Archit Taneja
2015-03-10 12:17 ` Daniel Vetter
2015-03-11 8:21 ` Archit Taneja
2015-03-11 15:17 ` Daniel Vetter
2015-03-13 6:25 ` Archit Taneja
2015-03-13 9:06 ` Daniel Vetter
2015-03-13 9:46 ` Jani Nikula
2015-03-13 11:00 ` Archit Taneja
2015-03-25 8:17 ` Archit Taneja
2015-03-25 9:21 ` Daniel Vetter
2015-06-30 7:10 ` Daniel Vetter
2015-06-30 7:56 ` Archit Taneja
2015-06-30 8:31 ` Benjamin Gaignard
2015-06-30 9:04 ` Daniel Vetter
2015-07-03 12:32 ` Thierry Reding
2015-07-03 13:33 ` Rob Clark
2015-06-30 9:06 ` Archit Taneja
2015-03-10 15:33 ` Jani Nikula
2015-03-11 4:57 ` Archit Taneja
2015-03-10 9:41 ` [RFC 2/6] drm/msm: Remove local fbdev emulation Kconfig option Archit Taneja
2015-03-10 9:41 ` [RFC 3/6] drm/i915: " Archit Taneja
2015-03-10 10:01 ` Daniel Vetter
2015-03-10 10:10 ` Archit Taneja [this message]
2015-03-10 9:41 ` [RFC 4/6] drm/tegra: " Archit Taneja
2015-03-10 9:41 ` [RFC 5/6] drm/imx: " Archit Taneja
2015-03-10 10:54 ` Philipp Zabel
2015-03-11 4:53 ` Archit Taneja
2015-03-10 9:41 ` [RFC 6/6] drm/sti: " 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=54FEC330.4050005@codeaurora.org \
--to=architt@codeaurora.org \
--cc=airlied@linux.ie \
--cc=benjamin.gaignard@linaro.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robdclark@gmail.com \
--cc=treding@nvidia.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;
as well as URLs for NNTP newsgroup(s).