[Intel-gfx] [PATCH 1/3] drm/i915: Hide the atomic_read(reset_counter) behind a helper

Daniel Vetter daniel at ffwll.ch
Thu Dec 3 01:20:37 PST 2015

On Thu, Dec 03, 2015 at 09:02:16AM +0000, Chris Wilson wrote:
> On Thu, Dec 03, 2015 at 09:57:01AM +0100, Daniel Vetter wrote:
> > On Tue, Dec 01, 2015 at 11:05:33AM +0000, Chris Wilson wrote:
> > > This is just a little bit of syntatic sugar to hide the atomic_reads()
> > > throughout the code to retrieve the current reset_counter. It also
> > > provides the other utility functions to check the reset state on the
> > > already read reset_counter, so that we can read it once and do multiple
> > > tests rather than risk the value changing between tests.
> > 
> > This patch also changes the meaning of reset_in_progress to not include
> > WEDGED afaict. I agree with that change, but it needs to be mentioned in
> > the commit message.
> > 
> > Also with that change there's some cleanup potential since a bunch of
> > callers that explicitly checked for reset_in_progress &&
> > !terminally_wedged now can drop the 2nd part of the condition. That
> > simplification is why I've done this change in my patch.
> I was just splitting out the header change and simplest of seds from the
> complete patch. Changing the reset/recovery interfaces I left till last.

I've found at least 1 huk I was looking for in patch 3. The other is in
reset_and_wakeup, and I think it's better to change the control flow there
differently. See my "[PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio"
for what I think should be changed around terminally_wedged() calls if you
drop the terminal state from reset_in_progress().
Daniel Vetter
Software Engineer, Intel Corporation

More information about the Intel-gfx mailing list