Earlier code would leave both bits set, so any reset after the first
would only reset media.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_reg.h |1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drive
The existing code was trying different vswing and preemphasis settings
in the wrong place, and wasn't trying them enough. So add a loop to
walk through them, properly disabling FDI TX and RX in between if a
failure is detected.
v2: remove unneeded reg writes, add delays around bit lock checks (Je
The existing code was trying different vswing and preemphasis settings
in the wrong place, and wasn't trying them enough. So add a loop to
walk through them, properly disabling FDI TX and RX in between if a
failure is detected.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.
The Gunit has a separate reg for this, so allocate some stolen space for
the power context and initialize the reg.
v2: check for allocation before freeing at cleanup (Jani)
v3: add comment about stolen allocation (Chris)
check for lock bit before init (jbarnes)
v4: check for allocation before
Thus preventing the display from keeping the GT awake with unnecessary
signals.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_pm.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2b0
From: Pallavi G
Program few Tx buffer Swing control settings through DPIO.
Signed-off-by: Pallavi G
Signed-off-by: Yogesh M
Signed-off-by: Gajanan Bhat
---
drivers/gpu/drm/i915/intel_display.c |3 +-
drivers/gpu/drm/i915/intel_dp.c | 114 +-
drivers/
Needed to handle pre/post enable/disable paths on VLV and avoid a few
fields that are marked reserved on VLV.
v2: don't set color range or DP PLL fields (Jani)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
di
Slightly different than other platforms.
v2 [Jani]: Fix IOSF_BYTE_ENABLES_SHIFT shift. Use common routine.
Signed-off-by: Jesse Barnes
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h | 22
drivers/gpu/drm/i915/intel_p
From: Ben Widawsky
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)
fixup thresholds to match other platforms (Ben)
c
PPS register offsets have changed in Valleyview.
v2: don't clobber port select bits on VLV when fixing up PPS timings
don't bother with G4x PPS regs (Jani)
Signed-off-by: Jesse Barnes
Signed-off-by: Gajanan Bhat
Signed-off-by: Vijay Purushothaman
Signed-off-by: Ben Widawsky
---
drivers/g
From: Pallavi G
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
Signed-off-by: Vijay Purushothaman
Signed-off-by: Yogesh M
Signed-off-by: Gajanan Bhat
---
drivers/gpu/drm/i915/intel_display.c | 25
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
se
Need to make sure sprites are disabled before shutting off a pipe.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component order confusion (Ville)
clean up platform init (Ville)
use comp
Le 28/03/2013 16:45, Chris Wilson a écrit :
On Thu, Mar 28, 2013 at 04:35:15PM +0100, zaverel wrote:
Hello,
i attach
i915_error_state
.zip
intel_reg_read 0x20d0 => 0x20D0 : 0x0
Whoops, thanks very much for the report!
commit 43181692f752f0a552d2e2c76d8379fe16e521cf
Author: Chris Wilson
D
On Thu, Mar 28, 2013 at 05:45:06PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 28, 2013 at 04:38:08PM +0100, Daniel Vetter wrote:
> > Ville pointed out that my assumption that no unsupported pixel format
> > can get past the pipe config computation stage to the platform
> > update_plane callbacks is
On Thu, Mar 28, 2013 at 04:35:15PM +0100, zaverel wrote:
> Hello,
>
> i attach
> i915_error_state
> .zip
>
> intel_reg_read 0x20d0 => 0x20D0 : 0x0
Whoops, thanks very much for the report!
commit 43181692f752f0a552d2e2c76d8379fe16e521cf
Author: Chris Wilson
Date: Thu Mar 28 15:41:38 2013 +0
On Thu, Mar 28, 2013 at 04:38:08PM +0100, Daniel Vetter wrote:
> Ville pointed out that my assumption that no unsupported pixel format
> can get past the pipe config computation stage to the platform
> update_plane callbacks is wrong. The reason is that this function
> still checks the old fb->dept
On Thu, Mar 28, 2013 at 01:00:56PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 28, 2013 at 12:03:25AM +0100, Daniel Vetter wrote:
> > As Thomas Gleixner spotted, it's rather horrible racy:
> > - We can miss almost a full tick, so need to compensate by 1 jiffy.
>
> I have a feeling this is a rather c
Ville pointed out that my assumption that no unsupported pixel format
can get past the pipe config computation stage to the platform
update_plane callbacks is wrong. The reason is that this function
still checks the old fb->depth value instead of the new pixel_format.
While checking with all the o
From: Paulo Zanoni
- It's a static function
- I just added a few more users to it
- Its sister ironlake_enable_display_irq is not marked as inline
- The compiler will still inline if it thinks it should do
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i
On Thu, Mar 28, 2013 at 04:01:35PM +0100, Daniel Vetter wrote:
> We've mostly switched over to the new more flexible schema, but
> there's one check left in the modeset code.
>
> Motivated by a question from Ville whether there's really no way an
> unsupported pixel_format can escape into our plat
On Thu, Mar 28, 2013 at 01:49:27PM +0100, Daniel Vetter wrote:
> Ville pointed out that my assumption that no unsupported pixel format
> can get past the pipe config computation stage to the platform
> update_plane callbacks is wrong. The reason is that this function
> still checks the old fb->dept
On Thu, Mar 28, 2013 at 04:06:52PM +0100, zaverel wrote:
> Hello,
>
> the commit sna/gen7: Use GT2 values for GT2 variants
>
>
> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=235a3981ea9759317b392302a2b2b8f4fafab410
>
> break sna acceleration.
Interesting. Can you send m
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> Hi Al,
>
> Hans de Bruin found a regression due to one of your changes. I asked him to
> test a fix and he reported back that it worked. (Thanks!) Can you see if you
> agree with the fix? Patch is attached due to webmail..
Hello,
the commit sna/gen7: Use GT2 values for GT2 variants
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=235a3981ea9759317b392302a2b2b8f4fafab410
break sna acceleration.
I use kde and when it start desktop is buggy with black butterfly like this
http://imageshack.us/
We've mostly switched over to the new more flexible schema, but
there's one check left in the modeset code.
Motivated by a question from Ville whether there's really no way an
unsupported pixel_format can escape into our platform update_plane
callbacks.
v2: Ville noticed that the fb->depth check
On Thu, Mar 28, 2013 at 01:49:26PM +0100, Daniel Vetter wrote:
> We've mostly switched over to the new more flexible schema, but
> there's one check left in the modeset code.
Having to do a full modeset for an fb change kind of sucks, but
as long as we're choosing the pipe bpp based on the primary
On Fri, Feb 22, 2013 at 9:05 PM, Paulo Zanoni wrote:
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 010e998..aa8f948 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -238,6 +238,9 @@ struct intel_crtc {
>
>
On Fri, Feb 22, 2013 at 05:05:30PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This is bad news and shouldn't be happening.
>
> Signed-off-by: Paulo Zanoni
No bikesheds here and I like this. So when you resend the underrun
reporting patch, please also resend this one here, thanks.
-Dan
On Fri, Feb 22, 2013 at 05:05:29PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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 interrupt, so
> we won't get an "
On Fri, Feb 22, 2013 at 05:05:31PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> - It's a static function
> - I just added a few more users to it
> - Its sister ironlake_enable_display_irq is not marked as inline
> - The compiler will still inline if it thinks it should do
>
> Signed-o
On Thu, Mar 28, 2013 at 01:59:59PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 28, 2013 at 12:46:42PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 28, 2013 at 01:26:28PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 27, 2013 at 12:45:00AM +0100, Daniel Vetter wrote:
> > > > - Update_plane should never
Ville pointed out that my assumption that no unsupported pixel format
can get past the pipe config computation stage to the platform
update_plane callbacks is wrong. The reason is that this function
still checks the old fb->depth value instead of the new pixel_format.
While checking with all the o
We've mostly switched over to the new more flexible schema, but
there's one check left in the modeset code.
Motivated by a question from Ville whether there's really no way an
unsupported pixel_format can escape into our platform update_plane
callbacks.
Cc: Ville Syrjälä
Signed-off-by: Daniel Ve
On Thu, Mar 28, 2013 at 12:46:42PM +0100, Daniel Vetter wrote:
> On Thu, Mar 28, 2013 at 01:26:28PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 27, 2013 at 12:45:00AM +0100, Daniel Vetter wrote:
> > > - Update_plane should never see a wrong fb bpp value, BUG in the
> > > corresponding cases.
> >
On Thu, Mar 28, 2013 at 01:26:28PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 27, 2013 at 12:45:00AM +0100, Daniel Vetter wrote:
> > - Update_plane should never see a wrong fb bpp value, BUG in the
> > corresponding cases.
>
> That's not true actually. For sprites the common drm code already
> ch
On Wed, Mar 27, 2013 at 12:45:00AM +0100, Daniel Vetter wrote:
> - Update_plane should never see a wrong fb bpp value, BUG in the
> corresponding cases.
That's not true actually. For sprites the common drm code already
checks the format against the list provided by the driver, but for
primary pl
On Thu, Mar 28, 2013 at 12:03:25AM +0100, Daniel Vetter wrote:
> As Thomas Gleixner spotted, it's rather horrible racy:
> - We can miss almost a full tick, so need to compensate by 1 jiffy.
I have a feeling this is a rather common pattern, so I wonder
if [mu]secs_to_jiffies() should do the +1 alre
On Thu, Mar 28, 2013 at 11:31:04AM +0100, Daniel Vetter wrote:
> Since
>
> commit bcf9dcc1e6269fac674e41f25d007ff75f76e840
> Author: Chris Wilson
> Date: Sun Jul 15 09:42:38 2012 +0100
>
> drm/i915: Workaround hang with BSD and forcewake on SandyBridge
>
> and
>
> commit 0cc2764cc4a4bd73
Since
commit bcf9dcc1e6269fac674e41f25d007ff75f76e840
Author: Chris Wilson
Date: Sun Jul 15 09:42:38 2012 +0100
drm/i915: Workaround hang with BSD and forcewake on SandyBridge
and
commit 0cc2764cc4a4bd73df55f8893c871778cf7ddd0f
Author: Ben Widawsky
Date: Sat Sep 1 22:59:48 2012 -0700
On Thu, Mar 28, 2013 at 12:03:24AM +0100, Daniel Vetter wrote:
> Since
>
> commit bcf9dcc1e6269fac674e41f25d007ff75f76e840
> Author: Chris Wilson
> Date: Sun Jul 15 09:42:38 2012 +0100
>
> drm/i915: Workaround hang with BSD and forcewake on SandyBridge
>
> and
>
> commit 0cc2764cc4a4bd73
Hi Dave,
I've figured I'll flush my -fixes queue before I head off to an extended
w/e. All just really small stuff: 3 small regression fixes plus a build
fix for especially dense gcc versions.
Cheers, Daniel
The following changes since commit b1289371fcd580b4c412e6d05c4cb8ac8d277239:
Revert "
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).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 97 +---
drivers/
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To f
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to ad
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 37 +++-
1 file c
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
p
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
v2: Rebased on top of Takashi Iwai's fix to (again) fix the ta
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cp
Hi all,
So now that the basic infrastructure is in I'll (re)dump the next series. It
fixes up the mess around m/n dp/fdi handling, which has been nicely splattered
all over the code.
Missing bit here is that vlv doesn't have a set of specially selected dp pll
values, so will keep on using the gen
On Wed, 27 Mar 2013, Jesse Barnes wrote:
> From: Chris Wilson
>
> Modifying the clock sources (via the DREF control on the PCH) is a slow
> multi-stage process as we need to let the clocks stabilise between each
> stage. If we are not actually changing the clock sources, then we can
> return earl
53 matches
Mail list logo
