On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson wrote:
> Quoting Chris Wilson (2017-12-01 17:55:15)
>> Quoting Sean Paul (2017-12-01 17:48:17)
>> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
>> > wrote:
>> > > The current wait_for() is a little more complicated nowadays (variable
>> > > W).
>>
Quoting Chris Wilson (2017-12-01 17:55:15)
> Quoting Sean Paul (2017-12-01 17:48:17)
> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> > wrote:
> > > The current wait_for() is a little more complicated nowadays (variable
> > > W).
> > >
> >
> > Hmm, am I based off the wrong tree? I'm using drm
Quoting Sean Paul (2017-12-01 17:48:17)
> On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> wrote:
> > Quoting Sean Paul (2017-12-01 17:20:24)
> >> /**
> >> - * _wait_for - magic (register) wait macro
> >> + * __wait_for - magic wait macro
> >> *
> >> - * Does the right thing for modeset paths w
On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson wrote:
> Quoting Sean Paul (2017-12-01 17:20:24)
>> /**
>> - * _wait_for - magic (register) wait macro
>> + * __wait_for - magic wait macro
>> *
>> - * Does the right thing for modeset paths when run under kdgb or similar
>> atomic
>> - * contexts.
Quoting Sean Paul (2017-12-01 17:20:24)
> /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
> *
> - * Does the right thing for modeset paths when run under kdgb or similar
> atomic
> - * contexts. Note that it's important that we check the condition again aft
This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
- need the value of the register after the wait_for
- run arbitrary operation for the read portion
This patch also chooses the correct sleep function (based on