From: Tiago Vignatti <tiago.vignatti@intel.com>
To: "Chris Wilson" <chris@chris-wilson.co.uk>,
"David Herrmann" <dh.herrmann@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
devel@driverdev.osuosl.org, "Hans Verkuil" <hverkuil@xs4all.nl>
Subject: Re: [PATCH] dma-buf: Update docs for SYNC ioctl
Date: Mon, 28 Mar 2016 16:42:13 -0300 [thread overview]
Message-ID: <56F98915.1030200@intel.com> (raw)
In-Reply-To: <20160323154223.GJ21717@nuc-i3427.alporthouse.com>
On 03/23/2016 12:42 PM, Chris Wilson wrote:
> On Wed, Mar 23, 2016 at 04:32:59PM +0100, David Herrmann wrote:
>> Hi
>>
>> On Wed, Mar 23, 2016 at 12:56 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>> On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote:
>>>> My question was rather about why we do this? Semantics for EINTR are
>>>> well defined, and with SA_RESTART (default on linux) user-space can
>>>> ignore it. However, looping on EAGAIN is very uncommon, and it is not
>>>> at all clear why it is needed?
>>>>
>>>> Returning an error to user-space makes sense if user-space has a
>>>> reason to react to it. I fail to see how EAGAIN on a cache-flush/sync
>>>> operation helps user-space at all? As someone without insight into the
>>>> driver implementation, it is hard to tell why.. Any hints?
>>>
>>> The reason we return EAGAIN is to workaround a deadlock we face when
>>> blocking on the GPU holding the struct_mutex (inside the client's
>>> process), but the GPU is dead. As our locking is very, very coarse we
>>> cannot restart the GPU without acquiring the struct_mutex being held by
>>> the client so we wake the client up and tell them the resource they are
>>> waiting on (the flush of the object from the GPU into the CPU domain) is
>>> temporarily unavailable. If they try to immediately wait upon the ioctl
>>> again, they are blocked waiting for the reset to occur before they may
>>> complete their flush. There are a few other possible deadlocks that are
>>> also avoided with EAGAIN (again, the issue is more or less the lack of
>>> fine grained locking).
>>
>> ...so you hijacked EAGAIN for all DRM ioctls just for a driver
>> workaround?
>
> No, we utilized the fact that EAGAIN was already enshrined by libdrm as
> the defacto mechanism for repeating the ioctl in order to repeat the
> ioctl for a driver workaround.
Do we have an agreement here after all? David? I need to know whether
this fixup is okay to go cause I'll need to submit to Chrome OS then.
Best Regards,
Tiago
next prev parent reply other threads:[~2016-03-28 19:42 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 20:02 [PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access() Chris Wilson
2016-03-19 10:09 ` [PATCH] dma-buf, drm, ion: " Daniel Vetter
2016-03-19 10:09 ` Daniel Vetter
2016-03-21 6:13 ` Sumit Semwal
2016-03-21 7:30 ` [PATCH] dma-buf: Update docs for SYNC ioctl Daniel Vetter
2016-03-21 7:35 ` Sumit Semwal
2016-03-21 7:40 ` Hans Verkuil
2016-03-21 7:50 ` Daniel Vetter
2016-03-21 7:50 ` Daniel Vetter
2016-03-21 7:51 ` Daniel Vetter
2016-03-21 7:53 ` Hans Verkuil
2016-03-21 12:26 ` David Herrmann
2016-03-21 12:26 ` David Herrmann
2016-03-21 17:14 ` Daniel Vetter
2016-03-21 17:14 ` Daniel Vetter
2016-03-23 11:30 ` David Herrmann
2016-03-23 11:56 ` Chris Wilson
2016-03-23 11:56 ` Chris Wilson
2016-03-23 15:32 ` David Herrmann
2016-03-23 15:42 ` Chris Wilson
2016-03-23 15:42 ` Chris Wilson
2016-03-28 19:42 ` Tiago Vignatti [this message]
2016-03-29 9:47 ` David Herrmann
2016-03-29 9:47 ` David Herrmann
2016-03-29 17:20 ` Tiago Vignatti
2016-03-21 13:16 ` Tiago Vignatti
2016-03-21 13:16 ` Tiago Vignatti
2016-03-21 13:13 ` [PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access() Tiago Vignatti
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=56F98915.1030200@intel.com \
--to=tiago.vignatti@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=devel@driverdev.osuosl.org \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=sumit.semwal@linaro.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.