From: Deepak S deepa...@linux.intel.com
After feedback from the hardware team, now we set the GPU min freq to RPe.
If we drop the freq to RPn, we found that the punit was not setting the
voltage to Vnn, So recommendation is to set min freq to RPe.
Signed-off-by: Deepak S deepa...@linux.intel.com
From: Deepak S deepa...@linux.intel.com
After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2
From: Deepak S deepa...@linux.intel.com
Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 17
-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_sysfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b
From: Deepak S deepa...@linux.intel.com
Added new media_rc6_residency_subtest for chv vlv.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
tests/pm_rc6_residency.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tests/pm_rc6_residency.c b/tests
From: Deepak S deepa...@linux.intel.com
With current code we are not considering the RC6 residency during sysfs
read. This is causing test to fail due to incorrect residency_accuracy check
This patch consider code time spent for accuracy check
Signed-off-by: Deepak S deepa...@linux.intel.com
On Thursday 26 February 2015 09:13 PM, Ville Syrjälä wrote:
On Thu, Feb 26, 2015 at 08:46:54PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore
From: Deepak S deepa...@linux.intel.com
Adding few of PM fixes and Improvements for CHV/VLV.
Deepak S (5):
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915: Re-adjusting rc6 promotional timer for chv
drm/i915/chv: Set min freq to efficient frequency on chv
drm/i915
From: Deepak S deepa...@linux.intel.com
The restriction of pinningFramebuffer to first 256MB is removed from gen8+.
Removing the restriction so that FB can be pinned in any space within
GTT/PPGTT. Also, for gen8+ no need to use pin_mappable for Framebuffer
also we do not take fence
On Thursday 26 February 2015 09:38 PM, Chris Wilson wrote:
On Thu, Feb 26, 2015 at 08:46:57PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more
it on for now, just to avoid making CHV a
special case.
This fixes the performance regression from:
commit 5a0afd4b78ec23f27f5d486ac3d102c2e8d66bd7
Author: Deepak S deepa...@linux.intel.com
Date: Sat Dec 13 11:43:27 2014 +0530
drm/i915/chv: Use timeout mode for RC6 on chv
Cc: Deepak S deepa
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On VLV/CHV the media well rc6 residency gets reported separately
from the render well, so add another file to sysfs so that we can
report the residency to the user.
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We use decimal for all the other RP magic values, so change
GEN6_RP_DOWN_TIMEOUT to decimal as well. Also change the order
of the register writes to match the BIOS spec
On Monday 19 January 2015 03:14 PM, Daniel Vetter wrote:
On Fri, Jan 16, 2015 at 08:42:16PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On VLV/CHV the rc6 residency calculations read a second register to
determine the actual units used for the residency value. The variable
name 'reg' where that register
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't register the rc6p and rc6pp sysfs files on VLV, so there's no
point in having any VLV checks in them. Drop the checks.
Signed-off-by: Ville Syrjälä
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The performance regression from the CHV RC6 EI-TO change is now fixed
so re-enable TO mode for better RC6 resicency.
This reverts commit
On Monday 19 January 2015 05:20 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Follow the sequence in the BIOS spec and clear the RC_CONTROL register
before changing any of the other RC6/RP registers.
Signed-off-by: Ville Syrjälä
From: Deepak S deepa...@linux.intel.com
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support different frequency for
different fuse data. We use this patch to help get total eu enabled and
read the right offset to get RP0
Based
From: Deepak S deepa...@linux.intel.com
CHV/BSW production system has new turbo offset to read different freq.
This series adds the support.
Deepak S (3):
drm/i915/chv: Populate total EU count on Cherryview
drm/i915: Increase the range of sideband address.
drm/i915: New offset for reading
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq based on the SKU it
is running on. Based on the Number of EU, we read different bits to
identify the max frequencies at which system can run.
v2: reuse mask definitions INTEL_INFO() to get device info
From: Deepak S deepa...@linux.intel.com
Looks like latest BSW/CHV production system has sideband address 128.
Use u32 data types to cover new offset/address range :)
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915
On Friday 16 January 2015 10:39 PM, Ville Syrjälä wrote:
On Fri, Jan 16, 2015 at 08:42:18PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq based on the SKU it
is running on. Based on the Number of EU, we read
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq based on the SKU it
is running on. Based on the Number of EU, we read different bits to
identify the max frequencies at which system can run.
v2: reuse mask definitions INTEL_INFO() to get device info
On Friday 12 December 2014 10:04 PM, Ville Syrjälä wrote:
On Sat, Dec 13, 2014 at 11:43:27AM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
v2
On Monday 15 December 2014 12:21 PM, Jani Nikula wrote:
On Fri, 12 Dec 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Fri, Dec 12, 2014 at 02:18:15PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq
From: Deepak S deepa...@linux.intel.com
With cherryview onwards, Gunit hardware itself save and restore all the
Gunit registers. Skipping the vlv_save_gunit_s0ix_state
vlv_restore_gunit_s0ix_state for cherryview in S3/S0ix sequence.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers
From: Deepak S deepa...@linux.intel.com
Use new Sideband offset to read max/min/gaur freq based on the SKU it
is running on. Based on the Number of EU, we read different bits to
identify the max frequencies at which system can run.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers
From: Deepak S deepa...@linux.intel.com
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support different frequency for
different fuse data. We use this patch to help get total eu enabled and
read the right offset to get RP0
Based
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
Signed-off-by: Deepak S deepa...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 5
. , \
+jiffies + 1); \
why timer, we can do a put after register read right?
Other changes looks fine to me
Reviewed-by: Deepak S deepa...@linux.intel.com
} \
+ val = __raw_i915_read##x(dev_priv, reg); \
hsw_unclaimed_reg_debug(dev_priv, reg, true
On Thursday 11 December 2014 03:45 PM, Chris Wilson wrote:
On Fri, Dec 12, 2014 at 03:30:14PM +0530, Deepak S wrote:
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
Calling intel_runtime_pm_put() is illegal from a soft-irq context, so
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
On user forcewake access, assert that runtime pm reference is held.
Fix and cleanup the callsites accordingly.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Mika
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
With gen 6 we don't need to take uncore lock as we
don't have anything to protect from concurrent access.
v2: rebase and account for gen9 changes
Signed-off-by: Chris Wilson
On Thursday 11 December 2014 05:23 PM, Chris Wilson wrote:
On Fri, Dec 12, 2014 at 05:09:26PM +0530, Deepak S wrote:
@@ -564,17 +542,20 @@ void gen6_gt_force_wake_get(struct drm_i915_private
*dev_priv, int fw_engine)
intel_runtime_pm_get(dev_priv);
I think we need to remove
On Thursday 11 December 2014 05:39 PM, Jani Nikula wrote:
On Fri, 12 Dec 2014, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support different frequency
From: Deepak S deepa...@linux.intel.com
Starting with Cherryview, devices may have a varying number of EU for
a given ID due to creative fusing. Punit support different frequency for
different fuse data. We use this patch to help get total eu enabled and
read the right offset to get RP0
Based
from step #1 comes (count -1)? right?
or i am missing something here?
Others Looks fine to me.
Acked-by: Deepak S deepa...@linux.intel.com
if (IS_VALLEYVIEW(dev))
vlv_force_wake_reset(dev_priv);
@@ -454,28 +382,6 @@ void intel_uncore_forcewake_reset(struct drm_device
, FW_DOMAIN_ID_RENDER,
+ FORCEWAKE, FORCEWAKE_ACK);
}
switch (INTEL_INFO(dev)-gen) {
Looks fine
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
These two were using a fw dance logic where posting read was done
after both domain bit were set. When in other gens, the posting
read is done immediately after setting the forcewake bit for each
domain.
Now bring these in line with
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
We have multiple forcewake domains now on recent gens. Change the
function naming to reflect this.
v2: More verbose names (Chris)
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
On Monday 08 December 2014 11:57 PM, Mika Kuoppala wrote:
Forcewake domain code uses unsigned int as a type for 'domains mask'.
Bring the hw accessors inline with this.
Suggested-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
On Tuesday 09 December 2014 05:16 PM, Mika Kuoppala wrote:
Make the domains and domain identifiers enums. To emphasize
the difference in order to avoid mistakes.
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
v2: Add comment about timeout threshold. (Tom)
Signed-off-by: Deepak S deepa...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v
On Wednesday 10 December 2014 08:01 PM, Ville Syrjälä wrote:
On Thu, Dec 11, 2014 at 12:48:41PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid
From: Deepak S deepa...@linux.intel.com
According to updated BSpec, Render/Common/media Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.
v2: Update media forcewake range (Ville)
Signed-off-by: Deepak S deepa...@linux.intel.com
From: Deepak S deepa...@linux.intel.com
According to updated BSpec, Render/Common Wells register range changed.
Updating the same to match the spec and avoid extra forcewake for none
forcewake range.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 9
On Wednesday 19 November 2014 01:37 AM, Dave Gordon wrote:
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the
On Wednesday 19 November 2014 01:37 AM, Dave Gordon wrote:
There are numerous places in the code where the driver's idea of
how much space is left in a ring is updated using the driver's
latest notions of the positions of 'head' and 'tail' for the ring.
Among them are some that update one or
) {
seqno = request-seqno;
Looks fine to me
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
be up due to the recent forcewake. Instead do the
power well status read first, and only then read the register needing
forcewake. This way the reported power well status can actually reflect
what's going on in the system.
Cc: Deepak S deepa...@intel.com
Signed-off-by: Ville Syrjälä ville.syrj
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Even with the rps debug messages signficantly recuced by
commit 67956867aa07c59d6d83628bbc9ee4bd9799a1e1
Author: Ville Syrjälä ville.syrj...@linux.intel.com
On Friday 14 November 2014 01:42 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give
0x0 no matter what the state of the render and media wells.
There was also some hint in the Gunit
On Friday 14 November 2014 01:42 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same
meaning since SNB. So treating them as something special for HSW doesn't
make sense to me.
Also the
-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently we miscalculate the GPU frequency on chv. This causes us to
report the GPU frequency as half of what it really is. Drop the extra
factor of 2 from the
-rps.max_freq = cherryview_rps_max_freq(dev_priv);
dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
:)
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman
;
default:
return -1;
}
right latest spec as div is 20
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
)
(pcbr VLV_PCBR_ADDR_SHIFT))
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
*/
+ WARN_ONCE((val GPLLENABLE) == 0, GPLL not enabled\n);
+
DRM_DEBUG_DRIVER(GPLL enabled? %s\n, val GPLLENABLE ? yes : no);
DRM_DEBUG_DRIVER(GPU status: 0x%08x\n, val);
Yup better to give warning if our assumption is wrong:)
Reviewed-by: Deepak S deepa...@linux.intel.com
0x10 ? yes : no);
+ DRM_DEBUG_DRIVER(GPLL enabled? %s\n, val GPLLENABLE ? yes : no);
DRM_DEBUG_DRIVER(GPU status: 0x%08x\n, val);
:)
Reviewed-by: Deepak S deepa...@linux.intel.com
dev_priv-rps.cur_freq = (val 8) 0xff
On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently we miscalculate the GPU frequency on chv
On Monday 17 November 2014 07:53 PM, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 12:10:51PM +0530, Deepak S wrote:
On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 906b985..f7fa0f7 100644
On Monday 17 November 2014 07:59 PM, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 12:09:54PM +0530, Deepak S wrote:
On Tuesday 18 November 2014 12:07 PM, Deepak S wrote:
With pin specific mutex from previous patch set removed
Oops This comment was for previous patch in the series :( Since i
On Monday 17 November 2014 06:11 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 05:59:07PM +0530, Deepak S wrote:
On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
On Tuesday 11 November 2014 02:25 AM, ville.syrj
On Monday 03 November 2014 06:59 PM, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode,
fine with the current changes after v5.
Reviewed-by: Deepak S deepa...@linux.intel.com
Thanks
Deepak
+ }
+}
+
void intel_logical_ring_stop(struct intel_engine_cs *ring)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
@@ -1248,6 +1256,7 @@ static int
On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).
Unfortunately, this case is also more complex than the previous one
because we need to map and access the
On Tuesday 18 November 2014 12:07 PM, Deepak S wrote:
On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).
Unfortunately, this case is also more complex than
On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
Up until now, we have pinned every logical ring context backing object
during creation, and left it pinned until destruction. This made my life
easier, but it's a harmful thing to do, because we
67c3bf6f55a97a0915a0f9ea07278a3073cc9601
Author: Deepak S deepa...@linux.intel.com
Date: Thu Jul 10 13:16:24 2014 +0530
drm/i915: populate mem_freq/cz_clock for chv
The problem was raised during review by Mika [1] but somehow slipped
through the cracks, and the patch got applied with the problem
On Thursday 18 September 2014 06:38 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2014 at 01:53:13PM +0200, Daniel Vetter wrote:
On Thu, Sep 18, 2014 at 11:39:25AM +0300, Ville Syrjälä wrote:
On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa
On Thursday 18 September 2014 02:09 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2014 at 06:51:50PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Based on the HW team inputs. We can should not wait for the old ack,
Waiting for old ack might fail, when other
From: Deepak S deepa...@linux.intel.com
Based on the HW team inputs. We can should not wait for the old ack,
Waiting for old ack might fail, when other forcewake came before the
present one is desserted.
for example, if forcewake bit 0 was set and before it could get cleared
forcewake bit 1 got
From: Deepak S deepa...@linux.intel.com
In chv, we have two power wells Render Media. We need to use
corresponsing forcewake count. If we dont follow this we are getting
error *ERROR*: Timed out waiting for forcewake old ack to clear due to
multiple entry into __vlv_force_wake_get.
Signed-off
On Monday 08 September 2014 08:10 PM, Daniel Vetter wrote:
On Mon, Sep 08, 2014 at 05:14:23PM +0300, Ville Syrjälä wrote:
On Mon, Sep 08, 2014 at 05:02:43PM +0300, Ville Syrjälä wrote:
On Tue, Sep 09, 2014 at 07:14:16PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa
-uncore.funcs.force_wake_get =
__gen7_gt_force_wake_mt_get;
dev_priv-uncore.funcs.force_wake_put =
__gen7_gt_force_wake_mt_put;
} else if (IS_IVYBRIDGE(dev)) {
Yup I Agree :)
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx
On Thursday 28 August 2014 11:00 AM, Daniel Vetter wrote:
On Fri, Aug 29, 2014 at 08:45:21AM +0530, Deepak S wrote:
On Tuesday 26 August 2014 07:24 PM, Daniel Vetter wrote:
On Fri, Aug 22, 2014 at 08:32:40AM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On Friday 29 August 2014 04:51 PM, Chris Wilson wrote:
On Fri, Aug 29, 2014 at 02:14:07PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
WaGsvRC0ResidenncyMethod is for vlv, it doesn't deal with chv
appropriately (eg. doesn't limit rps values to
: Deepak S deepa...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8a54870..6d5ae82 100644
) *
2);
return opcode;
Patch looks fine to me
Reviewed-by: Deepak S deepa...@linux.intel.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Monday 18 August 2014 05:12 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
init_clock_gating() is too late to read out the mem_freq. We already
want to print out the GPU MHz numbers before it's called. Move the
mem_freq setup to
From: Deepak S deepa...@linux.intel.com
Programing GT IER interrupts was fumbled while enabling Interrupts for
gen8
This is a regression from
commit abd58f0175915bed644aa67c8f69dc571b8280e0
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Sat Nov 2 21:07:09 2013 -0700
On Wednesday 20 August 2014 04:26 PM, Ville Syrjälä wrote:
On Thu, Aug 21, 2014 at 01:37:09PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Programing GT IER interrupts was fumbled while enabling Interrupts for
gen8
True, but...
This is a regression from
From: Deepak S deepa...@linux.intel.com
Programing GT IER interrupts was fumbled while enabling Interrupts for
gen8
This is a regression from
commit abd58f0175915bed644aa67c8f69dc571b8280e0
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Sat Nov 2 21:07:09 2013 -0700
for diverse scenarios beyond the author's imagination.
Chris Wilson (3):
drm/i915: Clearing buffer objects via blitter engine
drm/i915: Introduce a new create ioctl for user specified placement
drm/i915: Add support for stealing purgable stolen pages
Deepak S (1):
drm/i915: Clearing
On Monday 21 July 2014 10:42 PM, Ben Widawsky wrote:
On Tue, Jul 22, 2014 at 01:50:20PM +0530, Deepak S wrote:
On Thursday 17 July 2014 09:16 AM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode
On Thursday 17 July 2014 09:16 AM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm
From: Deepak S deepa...@intel.com
This was fumbled while trying to use the cached min/min/rpe values in the vlv
debugfs code.
This is a regression from
commit 03af20458a57a50735b12c1e3c23abc7ff70c6fa
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Sat
From: Deepak S deepa...@linux.intel.com
This was fumbled while trying to use the cached min/min/rpe values in
the vlv debugfs code.
This is a regression from
commit 03af20458a57a50735b12c1e3c23abc7ff70c6fa
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Sat Jun 28 02
From: Deepak S deepa...@linux.intel.com
Higher RC6 residency is observed using timeout mode
instead of EI mode. It's Recommended to use TO Method for RC6.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
On Saturday 28 June 2014 11:26 AM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Drop WaGsvBringDownFreq on CHV.
When in RC6 requesting the min freq should be fine to bring the
voltage down.
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915
On Friday 20 June 2014 08:03 PM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
We might be leaving the GPU Frequency (and thus vnn) high during the suspend.
Force gt to move to lowest freq while suspending.
v2: Fixed typo in commit message (Deepak)
v3: Force gt
On Monday 14 July 2014 08:47 PM, Jesse Barnes wrote:
On Tue, 15 Jul 2014 13:03:55 +0530
Deepak S deepa...@linux.intel.com wrote:
On Saturday 28 June 2014 11:26 AM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Drop WaGsvBringDownFreq on CHV.
When in RC6 requesting
On Monday 14 July 2014 08:47 PM, Jesse Barnes wrote:
On Tue, 15 Jul 2014 13:05:48 +0530
Deepak S deepa...@linux.intel.com wrote:
On Friday 20 June 2014 08:03 PM, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
We might be leaving the GPU Frequency (and thus vnn) high
From: Deepak S deepa...@linux.intel.com
Adding chv specific fre/encode conversion.
v2: Remove generic function and platform check (Daniel)
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 78 +++--
1 file changed, 76
From: Deepak S deepa...@linux.intel.com
This is useful for userspace utilities to verify and micromanaging
the increase/decrease frequncy.
v2: Use vlv_gpu_freq to get freq (Deepak)
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 15 +++
1 file
On Saturday 28 June 2014 04:33 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
mem_freq is needed to decode the GPU freq opcodes.
FIXME: Punit reg seems to contain garbage so this isn't right
Signed-off-by: Ville Syrjälä
valleyview_rps_min_freq(struct drm_i915_private *dev_priv)
+static int valleyview_rps_min_freq(struct drm_i915_private *dev_priv)
{
return vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM) 0xff;
}
Looks good. Reviewed-by: Deepak S deepa...@linux.intel.com
);
+ if (WARN_ON_ONCE(dev_priv-rps.max_freq 1))
+ dev_priv-rps.max_freq = ~1;
Cannot we use ALIGN Here?
Other than this it looks fine
Reviewed-by: Deepak S deepa...@linux.intel.com
dev_priv-rps.rp0_freq = dev_priv-rps.max_freq;
DRM_DEBUG_DRIVER(max GPU freq: %d
101 - 200 of 362 matches
Mail list logo
