All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tormod Volden <lists.tormod@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: Dave Airlie <airlied@redhat.com>
Subject: [PATCH] drm: Compare only lower 32 bits of framebuffer map offsets
Date: Mon, 30 May 2011 01:12:30 +0200	[thread overview]
Message-ID: <1306710750-31992-1-git-send-email-lists.tormod@gmail.com> (raw)
In-Reply-To: <BANLkTim76K-84NKF4GpStG6XtYe+61gKKw@mail.gmail.com>

From: Tormod Volden <debian.tormod@gmail.com>

Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real offsets could not always be handed over for comparison.

Instead of ignoring the offset we will compare the lower 32 bit. Drivers
using multiple framebuffers should just make sure that the lower 32 bit
are different. The existing drivers in question are practically limited
to 32-bit systems so that should be fine for them.

It is assumed that current drivers always specify a correct framebuffer
map offset, even if this offset was ignored since above commit. So this
patch should not change anything for drivers using only one framebuffer.

Drivers needing multiple framebuffers with 64-bit map offsets will need
to cook up something, for instance keeping an ID in the lower bits,
which is to be aligned away when it comes to using the offset.

Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
---

What about this idea? (Untested patch)

Regards,
Tormod

 drivers/gpu/drm/drm_bufs.c |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 3e257a5..b4224eb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -46,10 +46,11 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
 	list_for_each_entry(entry, &dev->maplist, head) {
 		/*
 		 * Because the kernel-userspace ABI is fixed at a 32-bit offset
-		 * while PCI resources may live above that, we ignore the map
-		 * offset for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
-		 * It is assumed that each driver will have only one resource of
-		 * each type.
+		 * while PCI resources may live above that, we only compare the
+		 * lower 32 bits of the map offset for maps of type
+		 * _DRM_FRAMEBUFFER or _DRM_REGISTERS.
+		 * It is assumed that if a driver have more than one resource
+		 * of each type, the lower 32 bits are different.
 		 */
 		if (!entry->map ||
 		    map->type != entry->map->type ||
@@ -61,7 +62,9 @@ static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
 				break;
 		case _DRM_REGISTERS:
 		case _DRM_FRAME_BUFFER:
-			return entry;
+			if ((entry->map->offset & 0xffffffff) ==
+			    (map->offset & 0xffffffff))
+				return entry;
 		default: /* Make gcc happy */
 			;
 		}
-- 
1.7.0.4

  reply	other threads:[~2011-05-29 23:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-25 21:54 multiple framebuffer drm maps Tormod Volden
2011-05-03 21:20 ` Tormod Volden
2011-05-03 21:54   ` Tormod Volden
2011-05-22 19:27     ` [PATCH] drm/savage: Do not add framebuffer and aperture maps Tormod Volden
2011-05-27 18:19       ` [PATCH resend] " Tormod Volden
2011-05-27 20:48         ` Dave Airlie
2011-05-27 23:44           ` Tormod Volden
2011-05-29 23:12             ` Tormod Volden [this message]
2011-05-29 23:29               ` [PATCH] drm: Compare only lower 32 bits of framebuffer map offsets Dave Airlie
2011-05-30 19:45                 ` [PATCH v2] " Tormod Volden
2011-05-31 22:04                   ` Tormod Volden
2011-06-10 22:59                   ` Tormod Volden

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=1306710750-31992-1-git-send-email-lists.tormod@gmail.com \
    --to=lists.tormod@gmail.com \
    --cc=airlied@redhat.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.