From: Daniel Vetter <daniel@ffwll.ch>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Jiang, Fei" <fei.jiang@intel.com>,
"Vetter, Daniel" <daniel.vetter@intel.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392
Date: Sun, 19 Oct 2014 13:28:52 +0200 [thread overview]
Message-ID: <20141019112852.GM26941@phenom.ffwll.local> (raw)
In-Reply-To: <CANq1E4STLwyXqmgTov5dhARsONFCBNXwqgOQ=ZBeAMnwSF2MWg@mail.gmail.com>
On Thu, Oct 16, 2014 at 03:47:08PM +0200, David Herrmann wrote:
> Hi
>
> On Thu, Oct 16, 2014 at 3:39 PM, Cheng, Yao <yao.cheng@intel.com> wrote:
> > Accepted :) I will update the patch to implement the mmap interface and remove the legacy MMAP_IOCTL.
> > BTW I didn't see a field to get mmap_offset in struct drm_gem_open, I guess something like a new "GET_MMAP_OFFSET_IOCTL" need be added to support mapping flinked/primed BO, is it?
>
> Yes. There is currently no generic interface to get mmap offsets for
> any gem bo (because some of them may not be mapped from user-space or
> require extra parameters).
>
> So, either support dumb-buffers (if you don't need any advanced
> parameters like tiling or cache constraints), or add an
> MMAP_OFFSET_IOCTL like you proposed (and most drivers do so).
Dave Airlie _really_ doesn't like it if userspace abuses the dumb buffer
interface for rendering. That really should only be used for sw rendering
for boot splash and similar. Some armsoc drivers don't really follow that
though.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2014-10-19 11:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 12:15 [RFC PATCH 0/3] drm driver for baytrail's vxd392 Yao Cheng
2014-10-13 12:15 ` [RFC PATCH 1/3] drm/i915: add vxd392 bridge in i915 Yao Cheng
2014-10-14 13:26 ` Jani Nikula
2014-10-15 2:02 ` [Intel-gfx] " Cheng, Yao
2014-10-16 10:15 ` Daniel Vetter
2014-10-16 15:05 ` Cheng, Yao
2014-10-19 11:27 ` Daniel Vetter
2014-10-13 12:15 ` [RFC PATCH 2/3] drm/ipvr: drm driver for vxd392 Yao Cheng
2014-10-13 14:26 ` David Herrmann
2014-10-15 2:14 ` Cheng, Yao
2014-10-16 9:46 ` David Herrmann
2014-10-16 10:28 ` Daniel Vetter
2014-10-16 13:39 ` [Intel-gfx] " Cheng, Yao
2014-10-16 13:47 ` David Herrmann
2014-10-19 11:28 ` Daniel Vetter [this message]
2014-10-14 11:53 ` [RFC PATCH 0/3] drm driver for baytrail's vxd392 Thierry Reding
2014-10-14 15:50 ` [Intel-gfx] " Sean V Kelley
2014-10-15 2:04 ` Cheng, Yao
2014-10-15 8:13 ` [Intel-gfx] " Thierry Reding
2014-10-15 8:18 ` Stéphane Marchesin
2014-10-15 8:31 ` Thierry Reding
2014-10-16 10:34 ` [Intel-gfx] " Daniel Vetter
2014-10-16 18:42 ` Rob Clark
2014-10-17 0:40 ` Jiang, Fei
2014-10-16 11:45 ` Daniel Vetter
2014-10-16 14:36 ` [Intel-gfx] " Cheng, Yao
2014-10-16 16:26 ` Sean V Kelley
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=20141019112852.GM26941@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fei.jiang@intel.com \
--cc=intel-gfx@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox