From: "Michał Winiarski" <michal.winiarski@intel.com>
To: <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
<intel-gfx@lists.freedesktop.org>
Cc: "Pekka Paalanen" <pekka.paalanen@collabora.com>,
"David Airlie" <airlied@linux.ie>,
"Oded Gabbay" <ogabbay@kernel.org>,
"Maxime Ripard" <mripard@kernel.org>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Matthew Wilcox" <willy@infradead.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Michał Winiarski" <michal.winiarski@intel.com>,
"James Zhu" <James.Zhu@amd.com>,
"Christian König" <christian.koenig@amd.com>
Subject: [PATCH v6 4/4] drm: Introduce force_extended_minors modparam
Date: Mon, 24 Jul 2023 23:14:28 +0200 [thread overview]
Message-ID: <20230724211428.3831636-5-michal.winiarski@intel.com> (raw)
In-Reply-To: <20230724211428.3831636-1-michal.winiarski@intel.com>
While there is support for >64 DRM devices on kernel side, existing
userspace may still have some hardcoded assumptions and it's possible
that it will require changes to be able to use more than 64 devices.
Add a modparam to simplify testing and development of >64 devices
support on userspace side by allocating minors from the >=192 range
(without the need of having >64 physical devices connected).
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
drivers/gpu/drm/drm_drv.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c2c6e80e6b31..ef6d7b498784 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,6 +57,11 @@ MODULE_LICENSE("GPL and additional rights");
DEFINE_XARRAY_ALLOC(drm_minors_xa);
+static bool force_extended_minors;
+module_param_unsafe(force_extended_minors, bool, 0400);
+MODULE_PARM_DESC(force_extended_minors,
+ "Don't allocate minors in 0-192 range. This can be used for testing userspace support for >64 drm devices (default: false)");
+
/*
* If the drm core fails to init for whatever reason,
* we should prevent any drivers from registering with it.
@@ -138,7 +143,7 @@ static void drm_minor_alloc_release(struct drm_device *dev, void *data)
static int drm_minor_alloc(struct drm_device *dev, enum drm_minor_type type)
{
struct drm_minor *minor;
- int r;
+ int r = -EBUSY;
minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
if (!minor)
@@ -147,8 +152,9 @@ static int drm_minor_alloc(struct drm_device *dev, enum drm_minor_type type)
minor->type = type;
minor->dev = dev;
- r = xa_alloc(drm_minor_get_xa(type), &minor->index,
- NULL, DRM_MINOR_LIMIT(type), GFP_KERNEL);
+ if (type == DRM_MINOR_ACCEL || !force_extended_minors)
+ r = xa_alloc(drm_minor_get_xa(type), &minor->index,
+ NULL, DRM_MINOR_LIMIT(type), GFP_KERNEL);
if (r == -EBUSY && (type == DRM_MINOR_PRIMARY || type == DRM_MINOR_RENDER))
r = xa_alloc(&drm_minors_xa, &minor->index,
NULL, DRM_EXTENDED_MINOR_LIMIT, GFP_KERNEL);
--
2.41.0
next prev parent reply other threads:[~2023-07-24 21:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-24 21:14 [PATCH v6 0/4] drm: Use full allocated minor range for DRM Michał Winiarski
2023-07-24 21:14 ` [PATCH v6 1/4] drm: Use XArray instead of IDR for minors Michał Winiarski
2023-08-25 16:59 ` James Zhu
2023-08-28 21:08 ` Michał Winiarski
2023-08-29 17:34 ` James Zhu
2023-08-29 18:33 ` Matthew Wilcox
2023-08-29 18:35 ` James Zhu
2023-08-29 18:37 ` Matthew Wilcox
2023-07-24 21:14 ` [PATCH v6 2/4] accel: " Michał Winiarski
2023-07-24 21:14 ` [PATCH v6 3/4] drm: Expand max DRM device number to full MINORBITS Michał Winiarski
2023-07-24 22:29 ` James Zhu
2023-07-26 18:15 ` Simon Ser
2023-07-27 12:01 ` Christian König
2023-07-28 14:22 ` Simon Ser
2023-08-08 13:55 ` Christian König
2023-08-08 15:04 ` James Zhu
2023-08-23 10:53 ` Simon Ser
2023-08-23 10:58 ` Simon Ser
2023-08-23 14:06 ` James Zhu
2023-07-24 21:14 ` Michał Winiarski [this message]
2023-08-30 16:31 ` [PATCH v6 0/4] drm: Use full allocated minor range for DRM James Zhu
2024-05-03 1:22 ` Eric Pilmore
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=20230724211428.3831636-5-michal.winiarski@intel.com \
--to=michal.winiarski@intel.com \
--cc=James.Zhu@amd.com \
--cc=airlied@linux.ie \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=ogabbay@kernel.org \
--cc=pekka.paalanen@collabora.com \
--cc=tzimmermann@suse.de \
--cc=willy@infradead.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 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 read-only IMAP folder(s) and NNTP newsgroup(s).