On Thu, Apr 18, 2013 at 04:35:46PM -0300, Paulo Zanoni wrote:
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
On Thu, 18 Apr 2013, Kenneth Graunke kenn...@whitecape.org wrote:
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
On Thu, 18 Apr 2013, Kenneth Graunke kenn...@whitecape.org wrote:
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.
It does drop the extra paranoia BUG() on unknown cache level.
On Thu, Apr 18, 2013 at 11:29:17PM +0300, Imre Deak wrote:
On Fri, 2013-04-12 at 17:57 -0300, Paulo Zanoni wrote:
+static void cpt_set_fifo_underrun_reporting(struct drm_device *dev,
+ enum transcoder pch_transcoder,
+
On Thu, Apr 18, 2013 at 11:47:07PM +0300, Imre Deak wrote:
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:
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_rect_equals() tells whether two drm_rects are equal.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
include/drm/drm_rect.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/drm/drm_rect.h
From: Ville Syrjälä ville.syrj...@linux.intel.com
Reduce the size of the the src/dst viewport to keep the scalign ratios
in check.
Also treat sprites below the minimum size as invisble.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 60
On Fri, Apr 19, 2013 at 06:44:47AM +0100, Damien Lespiau wrote:
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,
On Fri, Apr 19, 2013 at 06:21:18AM +0100, Damien Lespiau wrote:
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.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 367b534..0b3b9ac
It seems the error state often contains plenty of zero data [citation
needed]. It's also fairly big. Truncate more than (arbitrarily chosen)
three consecutive zero values:
: 0b640001
0004 : 47f8
0008 : 2044
000c :
0010 :
0014 :
Hello
As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.
The attached patch fixes this by falling back to bit banging mode for
the time DVO
On Fri, Apr 19, 2013 at 11:16:11AM +0300, Jani Nikula wrote:
It seems the error state often contains plenty of zero data [citation
needed]. It's also fairly big. Truncate more than (arbitrarily chosen)
three consecutive zero values:
: 0b640001
0004 : 47f8
0008 :
On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
Hello
As discussed in this thread
http://lists.freedesktop.org/archives/dri-devel/2013-April/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.
The
Hi all,
So I've resurrected the pch dpll conversion patch which somehow was lost and DP
now also works on ilk+. For fun I've also thrown in a few other minor patches to
make good use of pipe_config (or at least stuff I've noticed while doing
pipe_config related conversions).
Cheers, Daniel
We need the dpll/fp/fp2 values only when we need a pch pll. So move
them together with the code to acquire such a pll.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff
This was somehow lost in the pipe_config-dpll introduction in
commit f47709a9502f3715cc488b788ca91cf0c142b1b1
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Mar 28 10:42:02 2013 +0100
drm/i915: create pipe_config-dpll for clock state
While at it, extract a few small helpers for
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Up to now we've relied on the bios to get this right for us. Let's try
out whether our code has improved a bit, since we should dither
always when the output bpp doesn't match the plane bpp.
- gen5+ should be fine, since we only use the bios hint as an upgrade.
- gen4 changes, since here dithering
g4x dplls and ilk+ pch plls have a separate field for the reduced p1
setting, so this restriction does not apply. Only older platforms have
the restriction that the p1 divisors must match.
This unnecessary restriction has been introduced in
commit cec2f356d59d9e070413e5966a3c5a1af136d948
Author:
If we compute the pch pll state, we _have_ a pch encoder.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
We only ever check whether it's strictly bigger than one, so all the
is_sdvo/is_hdmi checks are redundant. Flatten the code a bit.
Also, s/temp/dpll_md/
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 58 +---
1 file
From: Ville Syrjälä ville.syrj...@linux.intel.com
Shame on me for not putting the bit definitions next to the register
definition in the first place.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
1 file changed, 3 insertions(+), 4
Hi all,
This fixes all the bugs I've found in my various systems when using non-24bpp
modes as the first part of the series.
And with working non-standard bpp support I've figured we can go fancy and
implemented auto-dithering if we hit an fdi bw limit. Which means that you can
now use 3-pipe
We need to multiply the hdmi port dotclock by 1.5x since it's not
really a dotclock, but the 10/8 encoding bitclock divided by 10.
Also add correct limit checks for the dotclock and reject modes which
don't fit. HDMI 1.4 would allow more, but our hw doesn't support that
unfortunately :(
Somehow
Prevents black screens when using 30bpp framebuffers on my
HDMI screens here. The DP input on the same screen though reports a
1.4 EDID with the correct 8bpc limit set.
v2: Actually check for the right thing!
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145
Author: Jani Nikula
They can get at the adjusted mode through intel_crtc-config.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to
Totally untested due to lack of screens supporting more than 8bpc. But
now we should have closed all holes in our bpp handling, so this
should be safe. The last missing piece was 10bpc support for g4x/vlv,
since we directly use the pipe bpp to feed the display link (and
anyway, only the cpt has
The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_crt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_crt.c
We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
dithering down a bit.
Just searchreplace in this patch, no functional change at all.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7cb1abf..b7774c1 100644
---
And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1 file changed, 34 insertions(+), 37 deletions(-)
diff --git
Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 31 +--
1 file changed, 25 insertions(+), 6
This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.
v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!
v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports
Spotted while changing related code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
This code will get _really_ repetive, and we'll end up with tons more
of this kind. So extract the common patterns.
This should also help when we add a lazy pipe_config compare mode for
fastboot.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 24
We want to use the fdi m/n values to easily compute the adjusted mode
dotclock on pch ports. Hence make sure the values stored in the pipe
config are always reliable.
v2: Fixup FDI TU readout.
v3: Rebase on top of moved cpu_transcoder.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.
Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure
On Fri, Apr 19, 2013 at 11:16:36AM +0200, Jiri Slaby wrote:
Hi, with today's -next I got this:
[drm] capturing error event; look for more information in
/sys/kernel/debug/dri/0/i915_error_state
i915: render error detected, EIR: 0x0010
i915: page table error
i915: PGTBL_ER: 0x0002
On Fri, Apr 19, 2013 at 12:23:02PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Shame on me for not putting the bit definitions next to the register
definition in the first place.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
On Fri, Apr 19, 2013 at 11:14:32AM +0200, Daniel Vetter wrote:
This was somehow lost in the pipe_config-dpll introduction in
commit f47709a9502f3715cc488b788ca91cf0c142b1b1
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Thu Mar 28 10:42:02 2013 +0100
drm/i915: create
Daniel Vetter wrote:
On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
+/* GMBUS NAK handling seems to be unstable, hence let the
+ * transmitter detection run in bit banging mode for now.
+ */
+intel_gmbus_force_bit(i2c,
From: Ville Syrjälä ville.syrj...@linux.intel.com
This allows unifying a bunch of the PLL calculations and whatnot.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12
drivers/gpu/drm/i915/intel_drv.h | 18 +-
From: Damien Lespiau damien.lespiau
We are trying to have more platform-orthogonal pieces of code. The DDI
code shouldn't mention Haswell.
Signed-off-by: Damien Lespiau damien.lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
We are trying to have more platform-orthogonal pieces of code. The DDI
code shouldn't mention Haswell.
v2: Fix the email address
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Apr 19, 2013 at 02:27:31PM +0100, Damien Lespiau wrote:
We are trying to have more platform-orthogonal pieces of code. The DDI
code shouldn't mention Haswell.
v2: Fix the email address
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
On Fri, Apr 19, 2013 at 12:54:00PM +0200, David Müller (ELSOFT AG) wrote:
Daniel Vetter wrote:
On Fri, Apr 19, 2013 at 10:41:50AM +0200, David Müller (ELSOFT AG) wrote:
+ /* GMBUS NAK handling seems to be unstable, hence let the
+ * transmitter detection run in bit
On Fri, Apr 19, 2013 at 1:05 AM, Jesse Barnes jbar...@virtuousgeek.org wrote:
\o/ I'll call off the hit man and cancel my plane ticket. Thanks.
And I already looked eagerly forward to an epic showdown somewhere in
the Swiss Alps ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
On Fri, Apr 19, 2013 at 5:14 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
g4x dplls and ilk+ pch plls have a separate field for the reduced p1
setting, so this restriction does not apply. Only older platforms have
the restriction that the p1 divisors must match.
This unnecessary
On Fri, Apr 19, 2013 at 11:24:32AM +0200, Daniel Vetter wrote:
Hi all,
This fixes all the bugs I've found in my various systems when using non-24bpp
modes as the first part of the series.
And with working non-standard bpp support I've figured we can go fancy and
implemented auto-dithering
Automatic color range selection was added in
commit 55bc60db5988c8366751d3d04dd690698a53412c
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Thu Jan 17 16:31:29 2013 +0200
drm/i915: Add Automatic mode for the Broadcast RGB property
but that removed the check to avoid a full
On Fri, Apr 19, 2013 at 12:28:30PM -0300, Paulo Zanoni wrote:
Hi
2013/4/19 Daniel Vetter dan...@ffwll.ch:
On Fri, Apr 19, 2013 at 06:44:47AM +0100, Damien Lespiau wrote:
On Thu, Apr 18, 2013 at 04:35:42PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This
Minor cleanup. Would be nice to use an enum for channel in the DPIO
macros so we don't mix up pipes and channels, but that's for another
patch.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_dp.c |9 +
1 file changed, 1 insertion(+), 8
On Fri, Apr 19, 2013 at 08:46:35AM -0700, Jesse Barnes wrote:
Minor cleanup. Would be nice to use an enum for channel in the DPIO
macros so we don't mix up pipes and channels, but that's for another
patch.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Queued for -next, thanks for the
Hi,
On 16.04.2013 09:50, Zhigang Gong wrote:
[Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need
some time to rebase to the latest beignet code base.
If you are interested, this is the link http://psi5.com/~geier/beignet.git.
Indeed, the extension handling is
Hi, with today's -next I got this:
[drm] capturing error event; look for more information in
/sys/kernel/debug/dri/0/i915_error_state
i915: render error detected, EIR: 0x0010
i915: page table error
i915: PGTBL_ER: 0x0002
[drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010,
We already enable dithering above if needed, and we definitely shouldn't
be enabling the pipe at this point, so just drop this whole block.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c |9 -
1 file changed, 9 deletions(-)
diff --git
On Fri, 19 Apr 2013 11:24:37 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
+ pipeconf = ~(PIPECONF_BPC_MASK | PIPECONF_DITHER_EN);
+ if (intel_crtc-config.dither intel_crtc-config.pipe_bpp !=
30)
I think the magic != 30 check needs a comment, or we should never
On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt handler. It'll generally only fire when we go idle
(or if for some reason there's a long delay between RPS interrupts), but
won't be
This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.
Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to
On Fri, 19 Apr 2013 20:17:10 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8c36376..7f1ab8b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@
On Fri, Apr 19, 2013 at 8:39 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 19 Apr 2013 20:17:10 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8c36376..7f1ab8b 100644
---
We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
commit 2f4f649a69a9eb51f6e98130e19dd90a260a4145
Author: Jani Nikula
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.
v2: Add more
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().
v3: Use the new domains for intel_display_power_enabled().
Signed-off-by: Paulo Zanoni
72 matches
Mail list logo
