From: Paulo Zanoni
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
---
drivers/gpu/drm/i915/i915_irq.c |4
From: Paulo Zanoni
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 domains to enum intel_di
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
Date: Mon No
On Fri, Apr 19, 2013 at 8:39 PM, Jesse Barnes wrote:
> On Fri, 19 Apr 2013 20:17:10 +0200
> Daniel Vetter 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/
On Fri, 19 Apr 2013 20:17:10 +0200
Daniel Vetter 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
> @@ -4605,22 +4605,29 @@
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 pch
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 i
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 re-arm
On Fri, 19 Apr 2013 11:24:37 +0200
Daniel Vetter 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
set .dither for
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
---
drivers/gpu/drm/i915/intel_display.c |9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
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, mask
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 entir
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
Queued for -next, thanks for the patch.
-Daniel
--
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
---
drivers/gpu/drm/i915/intel_dp.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/
On Fri, Apr 19, 2013 at 12:28:30PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2013/4/19 Daniel Vetter :
> > 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
> >> >
> >> > This should replace intel
Hi
2013/4/19 Daniel Vetter :
> 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
>> >
>> > This should replace intel_using_power_well. The idea is that we're
>> > adding the requested power doma
Automatic color range selection was added in
commit 55bc60db5988c8366751d3d04dd690698a53412c
Author: Ville Syrjälä
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 modeset if the value is
unchan
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-dit
On Fri, Apr 19, 2013 at 5:14 AM, Daniel Vetter 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 restriction has been introdu
On Fri, Apr 19, 2013 at 1:05 AM, Jesse Barnes 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
+41 (0) 79 365 57 48 - h
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 i
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
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Ve
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
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.
From: 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
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/
From: Ville Syrjälä
This allows unifying a bunch of the PLL calculations and whatnot.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12
drivers/gpu/drm/i915/intel_drv.h | 18 +-
2 files changed, 13 insertions(+), 17 deletions(-)
diff
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_forc
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
> Date: Thu Mar 28 10:42:02 2013 +0100
>
> drm/i915: create pipe_config->dpll for cloc
On Fri, Apr 19, 2013 at 12:23:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Shame on me for not putting the bit definitions next to the register
> definition in the first place.
>
> Signed-off-by: Ville Syrjälä
Queued for -next, thanks for the patch.
-Daniel
> ---
>
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: 0x00
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 i
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
---
drivers/gpu/drm/i915/i915
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
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
Spotted while changing related code.
Signed-off-by: Daniel Vetter
---
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 6d35ccd..27a9ef6 100644
--- a/drivers/
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 comp
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
---
drivers/gpu/drm/i915/intel_display.c | 18 +-
1 file changed, 13 insertio
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 intel_crt_mode_valid.
Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers
Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 71 +---
1 file changed, 34 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/in
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
---
drivers/gpu/drm/i91
Signed-off-by: Daniel Vetter
---
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
--- a/drivers/gpu/drm/i915/int
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 search&replace in this patch, no functional change at all.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i9
The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_crt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 58b4a53..1b9ebf
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 any
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 pch
They can get at the adjusted mode through intel_crtc->config.
Signed-off-by: Daniel Vetter
---
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
b/drivers/gpu/drm/i915/intel_display.c
inde
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
Date: Mon No
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
---
drivers/gpu/drm/i915/intel_display.c | 7 +++
1 f
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 I
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 pch
From: Ville Syrjälä
Shame on me for not putting the bit definitions next to the register
definition in the first place.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/
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
---
drivers/gpu/drm/i915/intel_display.c | 58 +---
1 file changed, 27 insertions
If we compute the pch pll state, we _have_ a pch encoder.
Signed-off-by: Daniel Vetter
---
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
b/drivers/gpu/drm/i915/intel_display.c
index 9a69d83..eef5ab
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:
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
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 97 +--
This was somehow lost in the pipe_config->dpll introduction in
commit f47709a9502f3715cc488b788ca91cf0c142b1b1
Author: Daniel Vetter
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 common computations.
S
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
---
drivers/gpu/drm/i915/intel_display.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i9
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
Danie
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.
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
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 tran
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 :
Signed-off-by: Jani Nikula
---
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 100644
--- a/drivers/gpu/
From: Ville Syrjälä
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 boundary.
The scaling checks are don
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
> >
> > ... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
> > register per CPU transcoder, not per pipe. This solves "unc
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
> >
> > This should replace intel_using_power_well. The idea is that we're
> > adding the requested power domain as an argument, so this might ena
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/intel_sprite.c | 60 -
1 file changed, 32 inser
From: Ville Syrjälä
drm_rect_equals() tells whether two drm_rects are equal.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fe767b7..64fa265 100644
--- a/include/
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
> >
> > This is bad news and shouldn't be happening.
> >
> > V2: Rebase.
> >
> > Signed-off-by: Paulo Zanoni
>
> Looks ok:
> Reviewed-by: Imre Deak
Queu
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,
> > +
70 matches
Mail list logo