Thread (8 messages) 8 messages, 3 authors, 2017-07-03

Re: [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore

From: Chris Wilson <hidden>
Date: 2017-06-29 17:57:37
Also in: dri-devel, intel-gfx

Possibly related (same subject, not in this thread)

Quoting ville.syrjala@linux.intel.com (2017-06-29 15:36:42)
From: Ville Syrjälä <redacted>

Introduce an rw_semaphore to protect the display commits. All normal
commits use down_read() and hence can proceed in parallel, but GPU reset
will use down_write() making sure no other commits are in progress when
we have to pull the plug on the display engine on pre-g4x platforms.
There are no modeset/gem locks taken inside __intel_atomic_commit_tail()
itself, and we wait for all dependencies before the down_read(), and
thus there is no chance of deadlocks with this scheme.
This matches what I thought should be done (I didn't think of using
rwsem just a mutex, nice touch). The point I got stuck on was what
should be done after the reset? I expected another modeset to return the
state back or otherwise the inflight would get confused?
 
During reset we should be recommiting the state that was committed last.
But for now we'll settle for recommiting the last state for each object.
Ah, I guess that explains the above. What is the complication with
restoring the current state as opposed to the next state?

But I have to leave debating the merits of atomic internals to others.  :|
-Chris
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help