From: Daniel Vetter <daniel@ffwll.ch>
To: Archit Taneja <architt@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
daniel@ffwll.ch
Subject: Re: [PATCH] drm: msm: Fix build when legacy fbdev support isn't set
Date: Mon, 9 Mar 2015 08:44:38 +0100 [thread overview]
Message-ID: <20150309074438.GK18775@phenom.ffwll.local> (raw)
In-Reply-To: <54FD3632.8080904@codeaurora.org>
On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
> On 03/05/2015 09:14 PM, Daniel Vetter wrote:
> >On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
> >>On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja <architt@codeaurora.org> wrote:
> >>>
> >>>On 02/23/2015 09:09 PM, Daniel Vetter wrote:
> >>>>
> >>>>On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
> >>>Rather than creating fb helper stub functions, maybe we could help each drm
> >>>driver create two variants of functions needed by drm core(like
> >>>output_poll_changed and dev_lastclose), one variant supporting legacy fbdev,
> >>>and the other not?
> >>
> >>So one quick thought.. building without fbdev would ideally/eventually
> >>be a distro level decision, not a driver level decision.. so I think
> >>it is *eventually* not a problem for it being a global drm level
> >>decision. The only problem is right now some drivers support no-fbdev
> >>config, and some do not. Maybe it is worth fixing that?
> >
> >Yeah, if we get fbdev emulation Kconfig option then I think i915 and msm
> >should remove their own options and just use that. There's really no need
> >to have this per-driver, this is a question of what userspace expects and
> >so per-distro, independant of the driver.
> >-Daniel
> >
>
> Okay. If I understand right. We need to do something like this:
>
> - Create a new Kconfig option that lets us emulate fbdev
>
> - For drivers that already have a config for fbdev emulation, replace it
> with our new emulation config.
>
> - For drivers that assume fbdev emulation by default, select our new
> emulation config in their respective Kconfigs.
>
> Does this sound okay?
>
> I suppose this could be the first step. Later we'd need to work on each
> driver to work with and without the fbdev emulation Kconfig option.
See Rob's idea quoted above: Imo you should just do the conditional code
in the fbdev emulation helper in drm_fb_helper.c, not in drivers. There's
some additional code in i915 (and maybe also msm) to compile out (mostly
around taking/dropping console_lock) and we want to keep that. But that
should also just be using the same new config option. So:
- Add new config option DRM_FBDEV_EMULATION (default y for backwards
compat). Use that to stub out helpers in drm_fb_helper.c.
- Replace the msm/i915 specific options with the new, i.e. remove it from
Kconfig and use DRM_FBDEV_EMULATION in the code instead of the msm/i915
specific one.
fbdev-less support for all other drivers will just magically happen
without the need for driver-specific code (except for the special locking
in i915 and similar things maybe).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2015-03-09 7:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 10:29 [PATCH] drm: msm: Fix build when legacy fbdev support isn't set Archit Taneja
2015-02-23 13:33 ` Rob Clark
2015-02-23 14:09 ` Daniel Vetter
2015-02-23 15:03 ` Rob Clark
2015-02-23 15:39 ` Daniel Vetter
2015-03-05 10:06 ` Archit Taneja
2015-03-05 12:10 ` Rob Clark
2015-03-05 15:44 ` Daniel Vetter
2015-03-09 5:57 ` Archit Taneja
2015-03-09 7:44 ` Daniel Vetter [this message]
2015-03-09 8:54 ` Archit Taneja
2015-03-09 12:17 ` Rob Clark
2015-03-09 15:03 ` Daniel Vetter
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=20150309074438.GK18775@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.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