All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Winiarski" <michal.winiarski@intel.com>
To: <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<intel-gfx@lists.freedesktop.org>
Cc: "Michał Winiarski" <michal.winiarski@intel.com>,
	"David Airlie" <airlied@linux.ie>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS
Date: Tue, 6 Sep 2022 22:16:28 +0200	[thread overview]
Message-ID: <20220906201629.419160-3-michal.winiarski@intel.com> (raw)
In-Reply-To: <20220906201629.419160-1-michal.winiarski@intel.com>

Having a limit of 64 DRM devices is not good enough for modern world
where we have multi-GPU servers, SR-IOV virtual functions and virtual
devices used for testing.
Let's utilize full minor range for DRM devices.
To avoid regressing the existing userspace, we're still maintaining the
numbering scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 drivers/gpu/drm/drm_drv.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 41799e4d0432..2c6e0b8d3b7a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -119,8 +119,17 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 	minor->type = type;
 	minor->dev = dev;
 
+	/*
+	 * DRM used to support 64 devices, for backwards compatibility we need to maintain the
+	 * minor allocation scheme where minors 0-63 are primary nodes, 64-127 are control nodes,
+	 * and 128-191 are render nodes.
+	 * After reaching the limit, we're allocating minors dynamically - first-come, first-serve.
+	 */
 	r = xa_alloc(&drm_minors_xa, &id, NULL,
 		     XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
+	if (r == -EBUSY)
+		r = xa_alloc(&drm_minors_xa, &id, NULL,
+			     XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL);
 	if (r < 0)
 		return r;
 
-- 
2.37.3


WARNING: multiple messages have this Message-ID (diff)
From: "Michał Winiarski" <michal.winiarski@intel.com>
To: <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<intel-gfx@lists.freedesktop.org>
Cc: "Michał Winiarski" <michal.winiarski@intel.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Simon Ser" <contact@emersion.fr>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>
Subject: [Intel-gfx] [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS
Date: Tue, 6 Sep 2022 22:16:28 +0200	[thread overview]
Message-ID: <20220906201629.419160-3-michal.winiarski@intel.com> (raw)
In-Reply-To: <20220906201629.419160-1-michal.winiarski@intel.com>

Having a limit of 64 DRM devices is not good enough for modern world
where we have multi-GPU servers, SR-IOV virtual functions and virtual
devices used for testing.
Let's utilize full minor range for DRM devices.
To avoid regressing the existing userspace, we're still maintaining the
numbering scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 drivers/gpu/drm/drm_drv.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 41799e4d0432..2c6e0b8d3b7a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -119,8 +119,17 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 	minor->type = type;
 	minor->dev = dev;
 
+	/*
+	 * DRM used to support 64 devices, for backwards compatibility we need to maintain the
+	 * minor allocation scheme where minors 0-63 are primary nodes, 64-127 are control nodes,
+	 * and 128-191 are render nodes.
+	 * After reaching the limit, we're allocating minors dynamically - first-come, first-serve.
+	 */
 	r = xa_alloc(&drm_minors_xa, &id, NULL,
 		     XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
+	if (r == -EBUSY)
+		r = xa_alloc(&drm_minors_xa, &id, NULL,
+			     XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL);
 	if (r < 0)
 		return r;
 
-- 
2.37.3


WARNING: multiple messages have this Message-ID (diff)
From: "Michał Winiarski" <michal.winiarski@intel.com>
To: <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
	<intel-gfx@lists.freedesktop.org>
Cc: "David Airlie" <airlied@linux.ie>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Simon Ser" <contact@emersion.fr>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Michał Winiarski" <michal.winiarski@intel.com>
Subject: [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS
Date: Tue, 6 Sep 2022 22:16:28 +0200	[thread overview]
Message-ID: <20220906201629.419160-3-michal.winiarski@intel.com> (raw)
In-Reply-To: <20220906201629.419160-1-michal.winiarski@intel.com>

Having a limit of 64 DRM devices is not good enough for modern world
where we have multi-GPU servers, SR-IOV virtual functions and virtual
devices used for testing.
Let's utilize full minor range for DRM devices.
To avoid regressing the existing userspace, we're still maintaining the
numbering scheme where 0-63 is used for primary, 64-127 is reserved
(formerly for control) and 128-191 is used for render.
For minors >= 192, we're allocating minors dynamically on a first-come,
first-served basis.

Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
---
 drivers/gpu/drm/drm_drv.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 41799e4d0432..2c6e0b8d3b7a 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -119,8 +119,17 @@ static int drm_minor_alloc(struct drm_device *dev, unsigned int type)
 	minor->type = type;
 	minor->dev = dev;
 
+	/*
+	 * DRM used to support 64 devices, for backwards compatibility we need to maintain the
+	 * minor allocation scheme where minors 0-63 are primary nodes, 64-127 are control nodes,
+	 * and 128-191 are render nodes.
+	 * After reaching the limit, we're allocating minors dynamically - first-come, first-serve.
+	 */
 	r = xa_alloc(&drm_minors_xa, &id, NULL,
 		     XA_LIMIT(64 * type, 64 * (type + 1) - 1), GFP_KERNEL);
+	if (r == -EBUSY)
+		r = xa_alloc(&drm_minors_xa, &id, NULL,
+			     XA_LIMIT(192, (1 << MINORBITS) - 1), GFP_KERNEL);
 	if (r < 0)
 		return r;
 
-- 
2.37.3


  parent reply	other threads:[~2022-09-06 20:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-06 20:16 [PATCH v4 0/3] drm: Use full allocated minor range for DRM Michał Winiarski
2022-09-06 20:16 ` Michał Winiarski
2022-09-06 20:16 ` [Intel-gfx] " Michał Winiarski
2022-09-06 20:16 ` [PATCH v4 1/3] drm: Use XArray instead of IDR for minors Michał Winiarski
2022-09-06 20:16   ` Michał Winiarski
2022-09-06 20:16   ` [Intel-gfx] " Michał Winiarski
2022-09-06 21:02   ` Matthew Wilcox
2022-09-06 21:02     ` [Intel-gfx] " Matthew Wilcox
2022-09-06 21:02     ` Matthew Wilcox
2022-09-11 21:13     ` Michał Winiarski
2022-09-11 21:13       ` [Intel-gfx] " Michał Winiarski
2022-09-11 21:13       ` Michał Winiarski
2022-09-06 20:16 ` Michał Winiarski [this message]
2022-09-06 20:16   ` [PATCH v4 2/3] drm: Expand max DRM device number to full MINORBITS Michał Winiarski
2022-09-06 20:16   ` [Intel-gfx] " Michał Winiarski
2022-09-06 20:16 ` [PATCH v4 3/3] drm: Introduce skip_legacy_minors modparam Michał Winiarski
2022-09-06 20:16   ` Michał Winiarski
2022-09-06 20:16   ` [Intel-gfx] " Michał Winiarski
2022-09-06 20:42 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Use full allocated minor range for DRM Patchwork

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=20220906201629.419160-3-michal.winiarski@intel.com \
    --to=michal.winiarski@intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.