From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: "Zhou, Jammy" <Jammy.Zhou@amd.com>, Daniel Vetter <daniel@ffwll.ch>
Cc: "Deucher, Alexander" <Alexander.Deucher@amd.com>,
"Koenig, Christian" <Christian.Koenig@amd.com>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] reservation: wait only with non-zero timeout specified (v3)
Date: Wed, 21 Jan 2015 10:12:05 +0100 [thread overview]
Message-ID: <54BF6D65.9080603@canonical.com> (raw)
In-Reply-To: <FD5696F5CDD4B04D92C97DB96167DECA16011475@SCYBEXDAG04.amd.com>
Hey,
Op 14-01-15 om 03:16 schreef Zhou, Jammy:
>>> I think it would be best to leave timeout=0 returning 0. Not handling it differently gives the same semantics as used by fence_wait_time and wait_event_timeout.
>>> Are there really many cases in which you don't know if timeout = 0 before or not?
>> Yeah I think with this it's more important to be consistent with all the other wait_something primitives the kernel exposes.
> Okay. I think we can live with that from driver perspective by handling timeout==0 and timeout>0 differently.
> But it should still be worth adding some notes for reservation_object_wait_timeout_rcu that the return value cannot be used to judge if the fences are signaled or not when timeout==0.
>
Oops it looks like I was wrong here..
Looking more closely at wait_event_timeout, ___wait_cond_timeout modifies __ret which makes it explicitly handle timeout = 0 by testing.
If you resend your patch I will ack it, but can you send a patch for fixing fence_wait_timeout too to clear any possible confusion?
~Maarten
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-01-21 9:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 9:36 [PATCH] reservation: wait only with non-zero timeout specified (v3) Jammy Zhou
2015-01-13 9:04 ` Maarten Lankhorst
2015-01-13 9:19 ` Zhou, Jammy
2015-01-13 9:22 ` Christian König
2015-01-13 10:18 ` Maarten Lankhorst
2015-01-13 22:10 ` Daniel Vetter
2015-01-14 2:16 ` Zhou, Jammy
2015-01-21 9:12 ` Maarten Lankhorst [this message]
2015-01-21 9:35 ` Zhou, Jammy
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=54BF6D65.9080603@canonical.com \
--to=maarten.lankhorst@canonical.com \
--cc=Alexander.Deucher@amd.com \
--cc=Christian.Koenig@amd.com \
--cc=Jammy.Zhou@amd.com \
--cc=daniel@ffwll.ch \
--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.