On Thu, 05 Jan 2012 21:41:34 -0800, Keith Packard <keithp at keithp.com> wrote:
> I talked with Eric about this and we decided that the whole splitting
> out of the i/o functions just doesn't make any sense. That makes this
> series very similar to Daniel's patches, so I'll rebase my bug fixes on
> top of those changes and send out a (shorter) series tomorrow.
And here's an updated version of my patches built on top of Daniel's:
The following changes since commit d06d2756a21a0c666f167ae9e4f13ef5f07f67d9:
acpi/video: Don't restore backlight to 0 at boot time (2012-01-06 11:10:25 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux forcewake-spinlock
Daniel Vetter (1):
drm/i915: protect force_wake_(get|put) with the gt_lock
Daniel's patch (v3)
Keith Packard (3):
drm/i915: Move reset forcewake processing to gen6_do_reset
This moves the forcewake code inside gen6_do_reset, at
the same time it changes from unconditionally calling
__gen6_gt_force_wake_get to using
dev_priv->display.force_wake_get. That could be broken
out as a separate patch -- it's just a bug.
drm/i915: Hold gt_lock during reset
drm/i915: Hold gt_lock across forcewake register reads
These two patches eliminate a race between chip reset
and other read operations. By holding the gt_lock during
all read operations, as well as across reset, we can
ensure that forcewake is active for all register
reads. Otherwise, right after chip reset, forcewake can
be inactive, but the internal forcewake_count may be
non-zero.
As a nice side-effect, this eliminates taking the
gt_lock twice during all register reads.
Please take a look and see if these are all reasonable additions to the
original patch and when it's ready, I'll push the whole sequence to
drm-intel-fixes.
--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120106/e02d3c80/attachment.pgp>
