All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>, Steven Price <steven.price@arm.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>
Subject: Re: [PATCH] drm/panfrost: Use drm_gem_dump_map_offset()
Date: Mon, 13 May 2019 15:47:22 +0100	[thread overview]
Message-ID: <155775884217.2165.11223399053598674062@skylake-alporthouse-com> (raw)
In-Reply-To: <20190513143921.GP17751@phenom.ffwll.local>

Quoting Daniel Vetter (2019-05-13 15:39:21)
> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> > panfrost_ioctl_mmap_bo() contains a reimplementation of
> > drm_gem_dump_map_offset() but with a bug - it allows mapping imported
> > objects (without going through the exporter). Fix this by switching to
> > use the generic drm_gem_dump_map_offset() function instead which has the
> > bonus of simplifying the code.
> 
> gem_dumb stuff is for kms drivers, panfrost is a render driver. We're
> generally trying to separate these two worlds somewhat cleanly.
> 
> I think it'd be good to have a non-dumb version of this in the core, and
> use that. Or upgrade the dumb version to be that helper for everyone (and
> drop the _dumb).

More specifically, since panfrost is using the drm_gem_shmem helper and
vm_ops, it too can provide the wrapper as it is the drm_gem_shmem layer
that implies that trying to mmap an imported object is an issue as that
is not a universal problem.
-Chris

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>, Steven Price <steven.price@arm.com>
Cc: David Airlie <airlied@linux.ie>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>
Subject: Re: [PATCH] drm/panfrost: Use drm_gem_dump_map_offset()
Date: Mon, 13 May 2019 15:47:22 +0100	[thread overview]
Message-ID: <155775884217.2165.11223399053598674062@skylake-alporthouse-com> (raw)
In-Reply-To: <20190513143921.GP17751@phenom.ffwll.local>

Quoting Daniel Vetter (2019-05-13 15:39:21)
> On Mon, May 13, 2019 at 03:32:44PM +0100, Steven Price wrote:
> > panfrost_ioctl_mmap_bo() contains a reimplementation of
> > drm_gem_dump_map_offset() but with a bug - it allows mapping imported
> > objects (without going through the exporter). Fix this by switching to
> > use the generic drm_gem_dump_map_offset() function instead which has the
> > bonus of simplifying the code.
> 
> gem_dumb stuff is for kms drivers, panfrost is a render driver. We're
> generally trying to separate these two worlds somewhat cleanly.
> 
> I think it'd be good to have a non-dumb version of this in the core, and
> use that. Or upgrade the dumb version to be that helper for everyone (and
> drop the _dumb).

More specifically, since panfrost is using the drm_gem_shmem helper and
vm_ops, it too can provide the wrapper as it is the drm_gem_shmem layer
that implies that trying to mmap an imported object is an issue as that
is not a universal problem.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-05-13 14:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-13 14:32 [PATCH] drm/panfrost: Use drm_gem_dump_map_offset() Steven Price
2019-05-13 14:39 ` Daniel Vetter
2019-05-13 14:39   ` Daniel Vetter
2019-05-13 14:47   ` Chris Wilson [this message]
2019-05-13 14:47     ` Chris Wilson
2019-05-13 15:14     ` Steven Price
2019-05-13 16:46       ` Chris Wilson

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=155775884217.2165.11223399053598674062@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@linux.ie \
    --cc=alyssa@rosenzweig.io \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=steven.price@arm.com \
    --cc=tomeu.vizoso@collabora.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 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.