On Friday 28 March 2014 06:36 PM, Chris Wilson wrote:
On Fri, Mar 28, 2014 at 02:53:48PM +0200, Ville Syrjälä wrote:
On Thu, Mar 27, 2014 at 12:05:01PM +0530, deepa...@linux.intel.com wrote:
@@ -1403,6 +1411,13 @@ typedef struct drm_i915_private {
/* gen6+ rps state */
struct
From: Deepak S deepa...@linux.intel.com
With RC6 enabled, BYT has an HW issue in determining the right
Gfx busyness.
WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide
on increasing/decreasing the freq. This logic will monitor C0
counters of render/media power-wells over EI period
On Friday 28 March 2014 01:33 PM, Chris Wilson wrote:
The speculation is that we can conserve more power by masking off
the interrupts at source (PMINTRMSK) rather than filtering them by the
up/down thresholds (RPINTLIM). We can select which events we know will
be active based on the current
On Thursday 27 March 2014 01:54 PM, Chris Wilson wrote:
What used to be a short-circuit now needs to adjust interrupt masking in
response to user requests for changing the min/max allowed frequencies.
This is currently done by a special case and early return, but the next
patch adds another
On Thursday 27 March 2014 01:54 PM, Chris Wilson wrote:
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
From: Deepak S deepa...@linux.intel.com
This reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6.
As per the inputs provided by hardware team we still use DDR
Rates as 0,1=800, 2=1066, 3=1333.
With this change, Turbo freqs used on current machines matches.
---
From: Deepak S deepa...@intel.com
Let's change the i915_cur_delayinfo to i915_cur_freqinfo to be in sync
with new RPS naming convention.
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hi Kenneth,
On Fri, 28 March 2014 Kenneth de Mello kdemello1...@gmail.com wrote:
On my system, the maximum resolution of my monitor, 2560x1440, is no longer
automatically detected properly with kernel 3.13.7. This worked with
3.13.6, and 5 with this hardware and identical kernel configs.
On Sun, Mar 30, 2014 at 01:51:30PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@intel.com
Let's change the i915_cur_delayinfo to i915_cur_freqinfo to be in sync
with new RPS naming convention.
Signed-off-by: Deepak S deepa...@intel.com
If we're doing a rename, we might
Bruno,
Thank you for your reply.
What about dual-link DVI? I though the additional link addressed the
pixel clock limitation. Has it only been using a single link this entire
time, and it's only worked by ignoring the maximum dotclock, so in other
words, the fact it works at all is the bug?
Hi Kenneth,
On Sun, 30 March 2014 Kenneth de Mello wrote:
What about dual-link DVI? I though the additional link addressed the
pixel clock limitation. Has it only been using a single link this entire
time, and it's only worked by ignoring the maximum dotclock, so in other
words, the fact
11 matches
Mail list logo
