drm/i915: fix comment on I915_{READ, WRITE}_FW
Comment mentioned use of intel_uncore_forcewake_irq{unlock, lock} functions which are nonexistent (and never were). The description was also incomplete and could cause confusion. Updated comment is more elaborate on usage and caveats. v2: mention __locked variant of intel_uncore_forcewake_{get,put} instead of plain ones Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilsono.c.uk> [Mika: removed two superfluous lines on comment noted by Chris] Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477399682-3133-1-git-send-email-arkadiusz.hiler@intel.com
This commit is contained in:
parent
489375c866
commit
aafee2eb8c
|
@ -3844,11 +3844,30 @@ __raw_write(64, q)
|
|||
#undef __raw_write
|
||||
|
||||
/* These are untraced mmio-accessors that are only valid to be used inside
|
||||
* critical sections inside IRQ handlers where forcewake is explicitly
|
||||
* critical sections, such as inside IRQ handlers, where forcewake is explicitly
|
||||
* controlled.
|
||||
*
|
||||
* Think twice, and think again, before using these.
|
||||
* Note: Should only be used between intel_uncore_forcewake_irqlock() and
|
||||
* intel_uncore_forcewake_irqunlock().
|
||||
*
|
||||
* As an example, these accessors can possibly be used between:
|
||||
*
|
||||
* spin_lock_irq(&dev_priv->uncore.lock);
|
||||
* intel_uncore_forcewake_get__locked();
|
||||
*
|
||||
* and
|
||||
*
|
||||
* intel_uncore_forcewake_put__locked();
|
||||
* spin_unlock_irq(&dev_priv->uncore.lock);
|
||||
*
|
||||
*
|
||||
* Note: some registers may not need forcewake held, so
|
||||
* intel_uncore_forcewake_{get,put} can be omitted, see
|
||||
* intel_uncore_forcewake_for_reg().
|
||||
*
|
||||
* Certain architectures will die if the same cacheline is concurrently accessed
|
||||
* by different clients (e.g. on Ivybridge). Access to registers should
|
||||
* therefore generally be serialised, by either the dev_priv->uncore.lock or
|
||||
* a more localised lock guarding all access to that bank of registers.
|
||||
*/
|
||||
#define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
|
||||
#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__), (val__))
|
||||
|
|
Loading…
Reference in New Issue