From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: daniel.vetter@ffwll.ch, linux@armlinux.org.uk,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
Date: Fri, 18 Aug 2017 01:35:41 +0300 [thread overview]
Message-ID: <6865827.mChELdC8mW@avalon> (raw)
In-Reply-To: <150300011457.9341.3354985295867819833@mail.alporthouse.com>
Hi Chris,
On Thursday 17 Aug 2017 21:01:54 Chris Wilson wrote:
> Quoting Laurent Pinchart (2017-08-17 20:40:52)
> > On Thursday 17 Aug 2017 20:09:20 Chris Wilson wrote:
> >> Quoting Laurent Pinchart (2017-08-17 20:01:40)
> >>> On Thursday 17 Aug 2017 19:30:44 Chris Wilson wrote:
> >>>> Quoting Laurent Pinchart (2017-08-17 18:56:09)
> >>>>> On Thursday 17 Aug 2017 18:21:30 Noralf Trønnes wrote:
> >>>>>> Reject mapping an imported dma-buf since is's an invalid
> >>>>>> use-case.
> >>>>>>
> >>>>>> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >>>>>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>>>>> Cc: Sean Paul <seanpaul@chromium.org>
> >>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>>>>> Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
> >>>>>> ---
> >>>>>>
> >>>>>> drivers/gpu/drm/drm_gem.c | 6 ++++++
> >>>>>> 1 file changed, 6 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/drm_gem.c
> >>>>>> b/drivers/gpu/drm/drm_gem.c
> >>>>>> index ad4e9cf..8da5801 100644
> >>>>>> --- a/drivers/gpu/drm/drm_gem.c
> >>>>>> +++ b/drivers/gpu/drm/drm_gem.c
> >>>>>> @@ -333,6 +333,12 @@ int drm_gem_dumb_map_offset(struct drm_file
> >>>>>> *file, struct drm_device *dev,
> >>>>>> if (!obj)
> >>>>>> return -ENOENT;
> >>>>>>
> >>>>>> + /* Don't allow imported objects to be mapped */
> >>>>>> + if (obj->import_attach) {
> >>>>>> + ret = -EINVAL;
> >>>>>> + goto out;
> >>>>>> + }
> >>>>>> +
> >>>>>
> >>>>> Wouldn't it be better to move this check to
> >>>>> drm_gem_create_mmap_offset_size() to reject mapping of all
> >>>>> imported dmabuf, not just the ones associated with dumb buffers ?
> >>>>
> >>>> No, we use that and we don't ban mapping an imported object.
> >>>
> >>> Do you use that with driver-specific buffers only or with dumb buffers
> >>> too ?
> >>
> >> For dma-buf we import? The current presumption is that the sg_table is
> >> backed by struct page. How would we know otherwise? I am actually not
> >> sure what would happen if we tried to use another mmio bar from the GPU.
> >>
> >> For dumb buffers we create, they are just ordinary buffers.
> >
> > My question was whether you need to mmap the dma-buf you import through
> > the dumb buffers API (which this patch prevents for drivers using the GEM
> > dumb helpers), or only through your driver-specific buffer API.
>
> i915_gem_mmap_gtt_ioctl -> drm_gem_create_mmap_offset/_size
> drvier->dumb_map_offset also uses the i915_gem_mmap_gtt mechanism.
>
> I was responding to the suggestion that this check could be centralised in
> drm_gem_create_mmap_offset_size, as that would prevent us from offering
> the mmap interface on imported buffers.
Fair enough. I wonder, however, why mmap()ing an imported buffer through the
dumb buffers API is an invalid use case, while doing the same through the
driver-specific buffer API isn't.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-08-17 22:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 16:21 [PATCH v3 0/2] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy Noralf Trønnes
2017-08-17 16:21 ` [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf Noralf Trønnes
2017-08-17 17:56 ` Laurent Pinchart
2017-08-17 18:30 ` Chris Wilson
2017-08-17 19:01 ` Laurent Pinchart
2017-08-17 19:09 ` Chris Wilson
2017-08-17 19:40 ` Laurent Pinchart
2017-08-17 20:01 ` Chris Wilson
2017-08-17 22:35 ` Laurent Pinchart [this message]
2017-08-18 7:45 ` Daniel Vetter
2017-08-18 8:01 ` Laurent Pinchart
2017-08-18 8:21 ` Chris Wilson
2017-08-18 7:46 ` Daniel Vetter
2017-08-18 16:13 ` Noralf Trønnes
2017-08-18 17:41 ` Eric Anholt
2017-08-18 20:17 ` Daniel Vetter
2017-08-18 20:34 ` Eric Anholt
2017-08-18 21:01 ` Daniel Vetter
2017-08-18 23:37 ` Eric Anholt
2017-08-24 10:04 ` Brian Starkey
2017-08-25 13:34 ` Daniel Vetter
2017-08-29 16:03 ` Brian Starkey
2017-08-30 7:44 ` Daniel Vetter
2017-08-30 8:38 ` Brian Starkey
2017-09-02 12:42 ` Noralf Trønnes
2017-08-21 5:26 ` Thierry Reding
2017-08-17 16:21 ` [PATCH v3 2/2] drm/armada: Use .dumb_map_offset and .dumb_destroy defaults Noralf Trønnes
2017-08-18 7:47 ` Daniel Vetter
2017-08-30 8:25 ` 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=6865827.mChELdC8mW@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux@armlinux.org.uk \
/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