On Wed, Apr 17, 2013 at 03:54:58PM -0700, Jesse Barnes wrote:
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
On Wed, Apr 17, 2013 at 03:54:59PM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
Program few Tx buffer Swing control settings through DPIO.
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Yogesh M yogesh.mohan.marimu...@intel.com
Signed-off-by: Gajanan Bhat
On Wed, Apr 17, 2013 at 03:55:00PM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
For high res modes m n p calculation is fixed for VLV platform.
v2: use 64 bit types and math (Ville)
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Vijay Purushothaman
On Wed, Apr 17, 2013 at 03:55:01PM -0700, Jesse Barnes wrote:
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We need to make sure that the tx lane reset occurs in both the full mode
Imo extracting vlv_enable_pll should be done now, the other stuff
is imo ok as follow-up (you could keep the comments as FIXME sections).
---
drivers/gpu/drm/i915/intel_display.c | 28
1 file changed, 28 insertions(+)
diff --git
Since Paulo's hdmi/dp encoder rework we have the port number ready
at hand, so no need to do ugly hardcoding like that. Also, there's
the -pre_enable hook right above waiting to be used.
Please encapsulate this into a vlv_check_dpll_port_ready(dev_priv, port)
or so and call it from
- Separate patch
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 86c4b6d..95b7f09 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
- Just confusing
---
drivers/gpu/drm/i915/intel_display.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 95b7f09..15bdbd0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
- should be squashed with the other pll limits stuff I think
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7042b2f..fd95c62 100644
---
On Thu, Apr 18, 2013 at 10:10:46AM +0200, Daniel Vetter wrote:
On Wed, Apr 17, 2013 at 03:55:00PM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
For high res modes m n p calculation is fixed for VLV platform.
v2: use 64 bit types and math (Ville)
Signed-off-by:
Hi all,
Please forgive me if I post my questions to the wrong place, but I don't know
where else to post.
I am new to graphic programming. I found that the Linux graphic architecture
is very complicated. Luckily I found an Intel Graphics Stack on 01.org. There
are 8 components in the 2013Q1
Please forgive me if I post my questions to the wrong place, but I don't know
where else to post.
Probably dri-de...@lists.freedesktop.org might get more non-Intel people.
I am new to graphic programming. I found that the Linux graphic architecture
is very complicated. Luckily I found an
On April 17, 2013 04:36:23 PM Chris Wilson wrote:
On Wed, Apr 17, 2013 at 11:23:41AM -0400, bob295 wrote:
Thanks for the speedy response.How do I go about upgrading to v3.8?
It wasn't clear from the website what to do. Am I likely to encounter
that ./configure problem I had with
On Thu, 18 Apr 2013 10:46:13 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
I somewhat suspect that we should also do this on resume. So maybe move
this to the clock gating functions where we tend to do all such setup
stuff?
Also I still think s/vlv_init_dpio/vlv_reset_dpio/
---
On Thu, 18 Apr 2013 10:46:14 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
- Will break everything else.
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
On Thu, Apr 18, 2013 at 08:14:03AM -0700, Jesse Barnes wrote:
On Thu, 18 Apr 2013 10:46:14 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
- Will break everything else.
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
On Thu, 18 Apr 2013 10:46:09 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Imo extracting vlv_enable_pll should be done now, the other stuff
is imo ok as follow-up (you could keep the comments as FIXME sections).
---
drivers/gpu/drm/i915/intel_display.c | 28
On Wed, Apr 17, 2013 at 05:38:57PM -0300, Paulo Zanoni wrote:
2013/4/17 ville.syrj...@linux.intel.com:
This series attempts to make our CEA mode matching recognize both the
60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97,
30/29.97, etc.).
The benefits should include:
On Thu, Apr 18, 2013 at 10:46:08AM +0200, Daniel Vetter wrote:
@@ -3782,6 +3905,27 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
i9xx_pfit_disable(intel_crtc);
+ for_each_encoder_on_crtc(dev, crtc, encoder)
+ if (encoder-post_disable)
+
This gets the panel fitter working on eDP on VLV, and should also apply
to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one
panel as eDP anyway).
A few cleanups are still possible on top of this, for example the LVDS
border control could be placed in the LVDS encoder structure
On Thu, Apr 18, 2013 at 10:03:48AM +0200, Daniel Vetter wrote:
On Wed, Apr 17, 2013 at 03:54:59PM -0700, Jesse Barnes wrote:
From: Pallavi G pallav...@intel.com
Program few Tx buffer Swing control settings through DPIO.
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by:
On Thu, Apr 18, 2013 at 10:46:10AM +0200, Daniel Vetter wrote:
Since Paulo's hdmi/dp encoder rework we have the port number ready
at hand, so no need to do ugly hardcoding like that. Also, there's
the -pre_enable hook right above waiting to be used.
Please encapsulate this into a
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
This is yet another series of patches that prevent our driver from touching
registers that don't exist or are powered off. With this series applied we
shouldn't trigger any unclaimed register message when there's a GPU hang or
when
From: Paulo Zanoni paulo.r.zan...@intel.com
This fixes unclaimed register messages when booting with eDP only
and i915.disable_power_well=1.
The error messages were caused by:
commit 0e8ffe1bf81b0780cc6229cb38664754dffe8776
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Mar 28
From: Paulo Zanoni paulo.r.zan...@intel.com
... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
register per CPU transcoder, not per pipe. This solves unclaimed register
messages when booting with eDP only and using the i915.disable_power_well=1.
Also fix a comment and
From: Paulo Zanoni paulo.r.zan...@intel.com
This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also allows us to easily
add new domains in case we need.
From: Paulo Zanoni paulo.r.zan...@intel.com
We need to dump these registers if we want to properly interpret the
others.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
In the error state function we read the registers without checking if
the power well is on, so after doing this we have to clear the
FPGA_DBG_RM_NOCLAIM bit to prevent the next I915_WRITE from detecting
it and printing an error message.
The first
From: Paulo Zanoni paulo.r.zan...@intel.com
This fixes unclaimed register messages when the power well is
disabled and there's a GPU hang.
v2: Use the new intel_display_power_enabled().
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c |4
1 file
From: Paulo Zanoni paulo.r.zan...@intel.com
We already have the same check on intel_enable_ddi. This patch
prevents unclaimed register messages when the power well is
disabled.
V2: Reset intel_crtc-eld_vld to false after the mode_set function.
V3: Add both type != INTEL_OUTPUT_EDP requested.
On April 17, 2013 04:08:52 PM Chris Wilson wrote:
On Wed, Apr 17, 2013 at 10:25:42AM -0400, icanprog...@295.ca wrote:
I'm new to your mailing list, so I'm not sure exactly how to report this.
My KDE system is quite flaky.The Xorg.0.log and dmesg both are
reporting that my GPU is
This way we can lift the port == C restriction, too!
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_dp.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
Sandybridge/Ivybridge, Bay Trail, and Haswell all have slightly
different page table entry formats. Rather than polluting one function
with generation checks, simply use a function pointer and set up the
correct PTE encoding function at startup.
Signed-off-by: Kenneth Graunke
This refactors our PTE encoding functions, splitting them out into
per-generation functions. Patch 2 fixes the page table entries for
the latest revision of Bay Trail, which is necessary to avoid GPU hangs.
I've tested these patches on Bay Trail and Haswell. Not SNB/IVB.
On Bay Trail, bit 1 means writeable by the GPU. Failing to set that
means basically anything using the GPU will cause hangs.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 33 +++--
1 file changed, 31 insertions(+), 2
Now that we have function pointers, it's cleaner to just create a new
per-platform PTE encoding function.
This should be identical in behavior to the previous code.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 32 +---
Hi,
one comment below:
On Fri, 2013-04-12 at 17:57 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one of these errors, we mask the
On Fri, 2013-04-12 at 17:57 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This is bad news and shouldn't be happening.
V2: Rebase.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Looks ok:
Reviewed-by: Imre Deak imre.d...@intel.com
---
Hi Dave,
As promised a stash of (mostly) fixes. Two pieces of non-fixes included:
- A notch more gtt refactoring from Ben, beating to death with igt in our
nightly testing.
- Support for display display-less server chips (again from Ben). New hw
support which is only likely to break itself
From: Pallavi G pallav...@intel.com
Program few Tx buffer Swing control settings through DPIO.
v2: fix up codingstyle (Daniel)
call from set_signal_levels (Ville, Daniel)
use proper port numbers (Jesse)
Signed-off-by: Pallavi G pallav...@intel.com
Signed-off-by: Yogesh M
This is a reset feature we don't actually need.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We need to make sure that the tx lane reset occurs in both the full mode
On Thu, 18 Apr 2013 21:35:12 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Apr 18, 2013 at 10:46:10AM +0200, Daniel Vetter wrote:
Since Paulo's hdmi/dp encoder rework we have the port number ready
at hand, so no need to do ugly hardcoding like that. Also, there's
the -pre_enable hook
On Thu, Apr 18, 2013 at 02:44:29PM -0700, Jesse Barnes wrote:
This is a reset feature we don't actually need.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Both patches merged with a bit of screaming, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1
On Thu, Apr 18, 2013 at 02:51:36PM -0700, Jesse Barnes wrote:
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We
This gets the panel fitter working on eDP on VLV, and should also apply
to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one
panel as eDP anyway).
A few cleanups are still possible on top of this, for example the LVDS
border control could be placed in the LVDS encoder structure
And put the pfit stuff into substructs while we're at it.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h |2 --
drivers/gpu/drm/i915/intel_ddi.c |2 +-
drivers/gpu/drm/i915/intel_display.c | 65 --
On Thu, Apr 18, 2013 at 01:28:33PM -0700, Kenneth Graunke wrote:
This refactors our PTE encoding functions, splitting them out into
per-generation functions. Patch 2 fixes the page table entries for
the latest revision of Bay Trail, which is necessary to avoid GPU hangs.
I've tested these
From: Xiang, Haihao haihao.xi...@intel.com
From: Xiang, Haihao haihao.xi...@intel.com
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
tests/gem_ring_sync_loop.c | 37 ++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git
On Thu, Apr 18, 2013 at 04:35:40PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This fixes unclaimed register messages when booting with eDP only
and i915.disable_power_well=1.
The error messages were caused by:
commit 0e8ffe1bf81b0780cc6229cb38664754dffe8776
On Thu, Apr 18, 2013 at 04:35:41PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
register per CPU transcoder, not per pipe. This solves unclaimed register
messages when booting with eDP only
On Thu, Apr 18, 2013 at 04:35:42PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also
On Thu, Apr 18, 2013 at 04:35:43PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We need to dump these registers if we want to properly interpret the
others.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
On Thu, Apr 18, 2013 at 04:35:44PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
In the error state function we read the registers without checking if
the power well is on, so after doing this we have to clear the
FPGA_DBG_RM_NOCLAIM bit to prevent the next
On Thu, Apr 18, 2013 at 04:35:45PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This fixes unclaimed register messages when the power well is
disabled and there's a GPU hang.
v2: Use the new intel_display_power_enabled().
Signed-off-by: Paulo Zanoni
56 matches
Mail list logo
