Searched hist:"2754436913 b94626a5414d82f0996489628c513d" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/drivers/gpu/drm/i915/ |
H A D | i915_irq.c | diff 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 D | i915_drv.h | diff 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>
|