On Thu, 5 Jan 2012 17:59:47 +0100, Daniel Vetter <dan...@ffwll.ch> wrote:
> Absolutely agreed, maybe with the adadendum to only try to make things
> faster if it's actually a problem and shows up in a fast-path we care
> about.
Here's a longer series that does a bunch of cleanup before trying to fix
things. Patches marked with '***' fix bugs. The patch marked with '...'
is the optimization to inline the spinlocks.
The following changes since commit d8e70a254d8f2da141006e496a51502b79115e80:
drm/i915: only set the intel_crtc DPMS mode to on if the mode set succeeded
(2012-01-03 14:55:52 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux forcewake-spinlock
Keith Packard (9):
drm/i915: Split register access functions out from display functions
The forcewake functions are invoked unconditionally on >= gen6
hardware from the register read/write functions. Having these
initialized as a side-effect of display initialization seems
wrong to me. I've moved the functions out of the display
structure and into a separate structure, and moved the
initialization to driver load time.
drm/i915: Access registers through function pointers
This makes register access go through function pointers,
following similar changes in many other parts of the driver.
drm/i915: Split out reg read/write for pre/post gen6 hardware
Taking advantage of the previous indirection, this actually
creates separate register read/write functions for pre-gen6 and
post-gen6 hardware.
drm/i915: Move forcewake_count to reg_access structure
Just moves the count into the new structure to keep things
together.
drm/i915: hide forcewake_count behind i915_forcewake_count
Create a function to hide getting the forcewake_count value
drm/i915: Switch forcewake from atomic to using a spinlock
This changes the type from atomic to u32 and wraps all users in
a new spinlock. The spinlock is held across calls to
->force_wake_put and ->force_wake_get.
*** drm/i915: Hold forcewake spinlock across reset process
Changes the reset process to hold the spinlock -- this will
ensure that all register operations will be correct wrt the
spinlock, even if the hardware gets reset.
*** drm/i915: Hold forcewake spinlock during register write operations
This protects the gt_fifo_count value under the spinlock and
keeps modifications to that tied to the actual register write.
... drm/i915: inline spin_lock usage in register read macros
Here's the optimization I mentioned -- inlines the spinlocks
inside the register read operations.
--
keith.pack...@intel.com
pgpO1LijxUca4.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
