From: Thierry Reding <thierry.reding@gmail.com>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, dri-devel@lists.freedesktop.org
Subject: Re: [RFC 05/12] drm: Create primary minor only if mode-setting is supported
Date: Tue, 25 Feb 2014 16:36:32 +0100 [thread overview]
Message-ID: <20140225153630.GC723@ulmo.nvidia.com> (raw)
In-Reply-To: <CANq1E4TV93MPH8+ZBCKuyzPb+9OpTykRkzvO270K6JaB6KAFLQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4905 bytes --]
On Mon, Feb 24, 2014 at 11:39:33AM +0100, David Herrmann wrote:
> Hi
>
> On Fri, Feb 21, 2014 at 8:55 AM, Thierry Reding
> <thierry.reding@gmail.com> wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Non-legacy devices may not always support mode-setting functionality, so
> > create the primary minor conditionally.
> >
> > One setup where this happens is the Tegra K1, where the Tegra DRM driver
> > exposes the display engine via standard KMS IOCTLs, and nouveau drives
> > the Kepler-type GPU that has no display capabilities.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > drivers/gpu/drm/drm_stub.c | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> > index fd2f1758366d..839460b774c5 100644
> > --- a/drivers/gpu/drm/drm_stub.c
> > +++ b/drivers/gpu/drm/drm_stub.c
> > @@ -564,9 +564,11 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> > goto err_minors;
> > }
> >
> > - ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> > - if (ret)
> > - goto err_minors;
> > + if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > + ret = drm_minor_alloc(dev, DRM_MINOR_PRIMARY);
> > + if (ret)
> > + goto err_minors;
> > + }
>
> There's a lot of code accessing dev->primary for debug messages (to
> print stuff like "error on card0: bla"). I just want to make sure you
> checked for all that. I tried renaming "->primary" to "->primary2"
> locally just to find these and I doubt this is safe for most drivers.
> I haven't looked for nouveau in particular, though.
> Anyhow, the patch is the right thing to do.
I've looked into this a little more to find out where the drm_device's
.primary field is used, with the following results:
1) DRM core:
- drm_bufs.c: Used in drm_find_matching_map() and drm_addmap_core().
This code is exclusively used by drivers that advertise the LEGACY
feature as far as I can tell. So these would be candidates where
not allocating the primary minor will cause problems. But I don't
understanding of the legacy code paths well enough to propose a
solution that could be applied here.
- drm_fb_helper.c: This is only used by drivers advertising the
MODESET feature, so shouldn't be an issue.
- drm_stub.c: All accesses to the primary minor are protected by a
check for the MODESET feature.
- drm_sysfs.c: Used primarily for hotplug events, which from what I
can tell are MODESET only.
One oddity here is the __drm_class_suspend() function, which checks
for:
46 if (drm_minor->type == DRM_MINOR_PRIMARY &&
47 drm_core_check_feature(drm_dev, DRIVER_LEGACY) &&
48 drm_dev->driver->suspend)
Which is somewhat confusing to me. drm_class_resume() performs the
same check.
2) DRM drivers:
- armada, ast, bochs, cirrus, exynos, i810, imx-drm, mga, mgag200, msm,
nouveau, omapdrm, r128, rcar-du, savage, shmobile, sis, tdfx, tildc,
udl, via and vmwgfx don't use the primary directly at all.
- i915:
- i915_dma.c and i915_irq.c protect all accesses to the primary
minor with LEGACY feature checks
- intel_display.c: uses it for SAREA code, but I think that's
scheduled to be removed (I do remember some discussion about this
on IRC not so long ago). Adding Daniel on Cc, maybe he knows more
about this.
- intel_ringbuffer.c: This seems to be SAREA related as well.
- i915_sysfs.c: sysfs code is used by both legacy and non-legacy
drivers, so this could be problematic.
- qxl: Uses the primary minor for debugfs support, but the driver is
unconditonally MODESET so it shouldn't be an issue.
- radeon: Uses the primary minor for debugfs support but all paths
that initialize debugfs support are conditionally MODESET.
- tegra: Uses the primary minor for debugfs support, but the driver
is unconditionally MODESET so it shouldn't be an issue.
One pretty common pattern, even though it shouldn't be problematic, is
how drivers use the primary minor for debugfs support. That means that
if the primary minor weren't registered, there'd be no place for these
drivers to put their debugfs files. In all the above cases, the driver
uses debugfs only for things that are modesetting related, so I guess
there isn't an immediate problem.
Interestingly nouveau seems to side-step this issue entirely by simply
setting up debugfs for every minor. For other drivers it seems like the
solution wouldn't be as easy, since there are many more files in debugfs
and they can come from subdevices as well.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-02-25 15:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-21 7:55 [RFC 00/12] Support render-node only drivers Thierry Reding
2014-02-21 7:55 ` [RFC 01/12] drm: Rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY Thierry Reding
2014-02-21 7:55 ` [RFC 02/12] drm: Introduce DRIVER_LEGACY feature Thierry Reding
2014-02-21 7:55 ` [RFC 03/12] drm/i915: Mark as legacy if KMS is disabled Thierry Reding
2014-02-21 8:17 ` Ilia Mirkin
2014-02-21 8:28 ` Thierry Reding
2014-02-21 7:55 ` [RFC 04/12] drm: Separate DRIVER_MODESET and DRIVER_LEGACY Thierry Reding
2014-02-21 7:55 ` [RFC 05/12] drm: Create primary minor only if mode-setting is supported Thierry Reding
2014-02-24 10:39 ` David Herrmann
2014-02-25 15:36 ` Thierry Reding [this message]
2014-02-21 7:55 ` [RFC 06/12] drm: Remove gratuituous blank line Thierry Reding
2014-02-21 7:55 ` [RFC 07/12] drm: Use drm_core_check_feature() where possible Thierry Reding
2014-02-21 7:55 ` [RFC 08/12] drm/exynos: Remove dead code Thierry Reding
2014-02-21 7:55 ` [RFC 09/12] drm/gma500: " Thierry Reding
2014-03-11 17:07 ` Patrik Jakobsson
2014-02-21 7:55 ` [RFC 10/12] drm/i810: " Thierry Reding
2014-02-21 7:55 ` [RFC 11/12] drm/i915: " Thierry Reding
2014-03-04 8:58 ` Daniel Vetter
2014-02-21 7:55 ` [RFC 12/12] drm/qxl: " Thierry Reding
2014-02-24 10:43 ` [RFC 00/12] Support render-node only drivers David Herrmann
2014-03-04 8:58 ` 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=20140225153630.GC723@ulmo.nvidia.com \
--to=thierry.reding@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.