On Thu, 2013-05-02 at 11:33 +0200, Daniel Vetter wrote:
> On Thu, May 2, 2013 at 11:31 AM, Daniel Vetter wrote:
> > On Thu, May 2, 2013 at 11:17 AM, Chris Wilson
> > wrote:
> >> On Thu, May 02, 2013 at 12:00:03PM +0300, Imre Deak wrote:
> >>> Due to possible scheduling latencies wait_event_timeo
On Thu, 2013-05-02 at 10:17 +0100, Chris Wilson wrote:
> On Thu, May 02, 2013 at 12:00:03PM +0300, Imre Deak wrote:
> > Due to possible scheduling latencies wait_event_timeout doesn't
> > guarantee a non-zero return value, even if the condition becomes true
> > before the specified timeout expires.
On Thu, May 2, 2013 at 11:31 AM, Daniel Vetter wrote:
> On Thu, May 2, 2013 at 11:17 AM, Chris Wilson
> wrote:
>> On Thu, May 02, 2013 at 12:00:03PM +0300, Imre Deak wrote:
>>> Due to possible scheduling latencies wait_event_timeout doesn't
>>> guarantee a non-zero return value, even if the cond
On Thu, May 2, 2013 at 11:17 AM, Chris Wilson wrote:
> On Thu, May 02, 2013 at 12:00:03PM +0300, Imre Deak wrote:
>> Due to possible scheduling latencies wait_event_timeout doesn't
>> guarantee a non-zero return value, even if the condition becomes true
>> before the specified timeout expires. Thu
On Thu, May 02, 2013 at 12:00:03PM +0300, Imre Deak wrote:
> Due to possible scheduling latencies wait_event_timeout doesn't
> guarantee a non-zero return value, even if the condition becomes true
> before the specified timeout expires. Thus we can incorrectly signal a
> timeout and abort a DP AUX
Due to possible scheduling latencies wait_event_timeout doesn't
guarantee a non-zero return value, even if the condition becomes true
before the specified timeout expires. Thus we can incorrectly signal a
timeout and abort a DP AUX transaction.
If wait_event_timeout returns 0, it's guaranteed that
