Home
last modified time | relevance | path

Searched hist:"2754436913 b94626a5414d82f0996489628c513d" (Results 1 – 2 of 2) sorted by relevance

/openbmc/linux/drivers/gpu/drm/i915/
H A Di915_irq.cdiff 037bde19a43e299d30f0490bba9be32ab355975c Thu Mar 27 03:24:19 CDT 2014 Chris Wilson <chris@chris-wilson.co.uk> Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."

This reverts commit 2754436913b94626a5414d82f0996489628c513d.

Conflicts:
drivers/gpu/drm/i915/i915_irq.c

The partial application of interrupt masking without regard to other
pathways for adjusting the RPS frequency results in completely disabling
the PM interrupts. This leads to excessive power consumption as the GPU
is kept at max clocks (until the failsafe mechanism fires of explicitly
downclocking the GPU when all requests are idle). Or equally as bad for
the UX, the GPU is kept at minimum clocks and prevented from upclocking
in response to a requirement for more power.

Testcase: pm_rps/blocking
Cc: Deepak S <deepak.s@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
diff 2754436913b94626a5414d82f0996489628c513d Mon Jan 27 10:05:05 CST 2014 Deepak S <deepak.s@intel.com> drm/i915: Disable/Enable PM Intrrupts based on the current freq.

When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for PM DOWN THRESHOLD INTRRUPTS.

v2: Use bool variables (Daniel)

v3: Fix Interrupt masking bit (Deepak)

v4: Use existing symbolic constants in i915_reg.h (Daniel)

v5: Add pm interrupt mask after new_delay calculation (Ville)

Signed-off-by: Deepak S <deepak.s@intel.com>
[danvet: Pass new_delay by value as suggested by Ville. Also appease
checkpatch.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
H A Di915_drv.hdiff 037bde19a43e299d30f0490bba9be32ab355975c Thu Mar 27 03:24:19 CDT 2014 Chris Wilson <chris@chris-wilson.co.uk> Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."

This reverts commit 2754436913b94626a5414d82f0996489628c513d.

Conflicts:
drivers/gpu/drm/i915/i915_irq.c

The partial application of interrupt masking without regard to other
pathways for adjusting the RPS frequency results in completely disabling
the PM interrupts. This leads to excessive power consumption as the GPU
is kept at max clocks (until the failsafe mechanism fires of explicitly
downclocking the GPU when all requests are idle). Or equally as bad for
the UX, the GPU is kept at minimum clocks and prevented from upclocking
in response to a requirement for more power.

Testcase: pm_rps/blocking
Cc: Deepak S <deepak.s@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
diff 2754436913b94626a5414d82f0996489628c513d Mon Jan 27 10:05:05 CST 2014 Deepak S <deepak.s@intel.com> drm/i915: Disable/Enable PM Intrrupts based on the current freq.

When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and
viceversa for PM DOWN THRESHOLD INTRRUPTS.

v2: Use bool variables (Daniel)

v3: Fix Interrupt masking bit (Deepak)

v4: Use existing symbolic constants in i915_reg.h (Daniel)

v5: Add pm interrupt mask after new_delay calculation (Ville)

Signed-off-by: Deepak S <deepak.s@intel.com>
[danvet: Pass new_delay by value as suggested by Ville. Also appease
checkpatch.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>