On Sat, Jun 8, 2013 at 6:35 AM, Ville Syrjälä
wrote:
> On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
>> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
>> > From: Foo Bar
>>
>> ^ ??
>>
>> git config error?
>
> Whoops. Sorry about that. I created the original patch on a test
> machine wher
On Fri, Jun 07, 2013 at 11:46:08PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 07, 2013 at 10:03:20PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 07, 2013 at 07:32:56PM +0300, Ville Syrjälä wrote:
> > > On Wed, Jun 05, 2013 at 01:34:05PM +0200, Daniel Vetter wrote:
> > > > Before I start to make a co
Well, the first step of a long road at least, it only reads out
the pipe -> shared dpll association thus far. Other state which needs
to follow:
- hw state of the dpll (on/off + dpll registers). Currently we just
read that out from the hw state, but that doesn't work too well when
the dpll is
With the big sed-job prep work done this is now really simple. With
the exception that we only assign the right shared dpll id in the
->mode_set callback but also depend upon the old one still being
around.
Until that mess is fixed up we need to jump through a few hoops to
keep the old value save.
Dealing with discrete enum values is simpler for hw state readout and
pipe config computations than pointers - having neat names instead of
chasing pointers should look better in the code.
This isn't a that good reason for pch plls, but on haswell we actually
have 3 different types of plls: WRPLL,
Before I start to make a complete mess out of this, crank up
the paranoia level a bit.
v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid
as spotted by Ville since we currently only put the dpll when we
already have the new pipe config. So a direct pch port -> cpu edp
transition
On Fri, Jun 07, 2013 at 10:03:20PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2013 at 07:32:56PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 05, 2013 at 01:34:05PM +0200, Daniel Vetter wrote:
> > > Before I start to make a complete mess out of this, crank up
> > > the paranoia level a bit.
> > >
On Sat, Jun 08, 2013 at 06:09:42AM +1000, Dave Airlie wrote:
> On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> > From: Foo Bar
>
> ^ ??
>
> git config error?
Whoops. Sorry about that. I created the original patch on a test
machine where I apparently had been too lazy to set up my git
correctly. And
On Fri, Jun 07, 2013 at 08:23:33PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 05, 2013 at 01:34:10PM +0200, Daniel Vetter wrote:
> > Well, the first step of a long road at least, it only reads out
> > the pipe -> shared dpll association thus far. Other state which needs
> > to follow:
> >
> > - hw
On Sat, Jun 8, 2013 at 1:43 AM, wrote:
> From: Foo Bar
^ ??
git config error?
Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, Jun 07, 2013 at 07:32:56PM +0300, Ville Syrjälä wrote:
> On Wed, Jun 05, 2013 at 01:34:05PM +0200, Daniel Vetter wrote:
> > Before I start to make a complete mess out of this, crank up
> > the paranoia level a bit.
> >
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/int
On Fri, Jun 07, 2013 at 09:32:33PM +0200, Daniel Vetter wrote:
> On Fri, Jun 7, 2013 at 9:14 PM, Chris Wilson wrote:
> > On Fri, Jun 07, 2013 at 09:10:23PM +0200, Daniel Vetter wrote:
> >> On Fri, Jun 07, 2013 at 01:47:41PM +0100, Chris Wilson wrote:
> >> > + if (intel_crtc_set_c
On Fri, Jun 7, 2013 at 9:14 PM, Chris Wilson wrote:
> On Fri, Jun 07, 2013 at 09:10:23PM +0200, Daniel Vetter wrote:
>> On Fri, Jun 07, 2013 at 01:47:41PM +0100, Chris Wilson wrote:
>> > + if (intel_crtc_set_config(&set))
>> > + __intel_set_mode(crtc, &c
On Fri, Jun 07, 2013 at 09:10:23PM +0200, Daniel Vetter wrote:
> On Fri, Jun 07, 2013 at 01:47:41PM +0100, Chris Wilson wrote:
> > + if (intel_crtc_set_config(&set))
> > + __intel_set_mode(crtc, &crtc->mode,
> > +
On Fri, Jun 07, 2013 at 01:47:41PM +0100, Chris Wilson wrote:
> On random machines, the BIOS changes the hardware state of the display
> when it detects a lid event. In return, we have to then do a forced
> restore of the users requested configuration as soon as we handle the
> lid event. Currently
Apparently there are some horrible BIOSen out there :(
And under any normal circumstances this shouldn't ever hurt us since
the panel should light up successfully much earlier.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65497
Tested-by: Zoltán Böszörményi
Signed-off-by: Daniel Vetter
On Fri, Jun 07, 2013 at 05:59:45PM +0100, Damien Lespiau wrote:
> I could also test it I guess...
Well, it does seem to behave. The confusion may be from the WA name, the
field is called "Block Msg channel during resets". This is still mostly
guess work though.
--
Damien
I've just gone over patches 01-13.
For patches 01,02,04,05,07,09-13
Reviewed-by: Ville Syrjälä
For patches 03,06,08 I replied with some concerns/ideas.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists
On Wed, Jun 05, 2013 at 01:34:10PM +0200, Daniel Vetter wrote:
> Well, the first step of a long road at least, it only reads out
> the pipe -> shared dpll association thus far. Other state which needs
> to follow:
>
> - hw state of the dpll (on/off + dpll registers). Currently we just
> read tha
On Wed, Jun 05, 2013 at 01:34:08PM +0200, Daniel Vetter wrote:
> With the big sed-job prep work done this is now really simple.
Since the pipe config is built up from scratch for modeset_pipes,
aren't we losing track of which PLL we were using previously?
We only unref the previous PLL for modese
On Fri, Jun 07, 2013 at 05:51:57PM +0100, Chris Wilson wrote:
> On Fri, Jun 07, 2013 at 05:41:16PM +0100, Damien Lespiau wrote:
>
> During GFX reset? This patch looks a little permanent to me, so please
> explain.
The description of the bits is "Enable msg channel blockreq/ack
mechanism for [GFX
On Fri, Jun 07, 2013 at 05:41:16PM +0100, Damien Lespiau wrote:
During GFX reset? This patch looks a little permanent to me, so please
explain.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freed
On Wed, Jun 05, 2013 at 01:34:07PM +0200, Daniel Vetter wrote:
> @@ -5731,11 +5740,15 @@ static int ironlake_crtc_mode_set(struct drm_crtc
> *crtc,
> if (encoder->pre_pll_enable)
> encoder->pre_pll_enable(encoder);
>
> - if (intel_crtc->shared_dpll) {
> -
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
drivers/gpu/drm/i915/i915_reg.h | 9 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 58048d4..187a9a4 100644
--- a/dri
Let's disable RC6+ by default. We still leave the possibility to
override this with the module parameter.
I've also shuffled the code around so we always log if we have RC6
enabled or disabled.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 25 +
1 f
intel_enable_rc6() is used to check if we can compute the RC6 residency
in the sysfs code. Disable this for platforms older than Ironlake.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/d
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ce14594..009e616 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/dri
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 486c46b..bc7dd9a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 827d7ca..9e0d69c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 0e72da6..ce14594 100644
--- a/drivers/gpu/drm/i915/intel_ringb
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb3c2c4..2eb1846 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i91
We also wait for that blank on other platforms but the w/a doesn't
apply there. Not an issue at all.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 50f
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 57e99b1..eb3c2c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@
Hi,
Patches 1-7: Some comments to signal the Wa we're implementing for the next
person that goes through the list.
Patch 8: Random detail when reading that code
Patch 9-10: Two new workarounds. I don't remember at all the discussions around
RC6+ on GEN6+, but there's definitely a workaround that
On Wed, Jun 05, 2013 at 01:34:05PM +0200, Daniel Vetter wrote:
> Before I start to make a complete mess out of this, crank up
> the paranoia level a bit.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
On Fri, Jun 07, 2013 at 06:43:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The structures and strings involved with various pretty-print functions
> aren't meant to be modified, so make them all const. The exception is
> drm_connector_enum_list which does get modifie
On Fri, Jun 07, 2013 at 06:52:24PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Don't enable the cursor until g4x_fixup_plane() had a chance to do
> cast its magic spell.
>
> Egbert writes:
> "Today I had the chance to test this. First I tried
> if I can still reproduce
On Thu, Jun 06, 2013 at 04:58:16PM -0300, Rodrigo Vivi wrote:
> WaFbcNukeOn3DBlt for IVB, HSW.
>
> According BSPec: "Workaround: Do not enable Render Command Streamer tracking
> for FBC.
> Instead insert a LRI to address 0x50380 with data 0x0004 after the
> PIPE_CONTROL that
> follows each r
From: Ville Syrjälä
Don't enable the cursor until g4x_fixup_plane() had a chance to do
cast its magic spell.
Egbert writes:
"Today I had the chance to test this. First I tried
if I can still reproduce the blank with this patch
added when I disable my voodoo g4x_fixup_plane():
It turned out it
From: Ville Syrjälä
The structures and strings involved with various pretty-print functions
aren't meant to be modified, so make them all const. The exception is
drm_connector_enum_list which does get modified in drm_connector_init().
While at it move the drm_get_connector_status_name() prototyp
From: Ville Syrjälä
Use drm_get_format_name to print more readable pixel format names
in debug output.
Also unify the debug messages to say "unsupported pixel format",
which better describes what is going on.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 12 -
From: Ville Syrjälä
The string isn't modified so make it const.
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
drivers/video/fbmem.c | 2 +-
include/linux/fb.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-
From: Foo Bar
Rather than just printing the pixel format as a hex number, decode the
fourcc into human readable form, and also decode the LE vs. BE flag.
Keep printing the raw hex number too in case it contains non-printable
characters.
Some examples what the new drm_get_format_name() produces:
On Fri, Jun 7, 2013 at 11:41 AM, wrote:
> From: Ville Syrjälä
>
> Don't enable the cursor until g4x_fixup_plane() had a chance to do
> cast its magic spell.
>
> Egbert writes:
> "Today I had the chance to test this. First I tried
> if I can still reproduce the blank with this patch
> added whe
On Fri, Jun 7, 2013 at 2:47 PM, Chris Wilson wrote:
> On random machines, the BIOS changes the hardware state of the display
> when it detects a lid event. In return, we have to then do a forced
> restore of the users requested configuration as soon as we handle the
> lid event. Currently, this is
Chris Wilson writes:
> This is of no value to the developer reading the report, let alone the
> bamboozled user.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedeskt
This is of no value to the developer reading the report, let alone the
bamboozled user.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville)
Signed-off-
On random machines, the BIOS changes the hardware state of the display
when it detects a lid event. In return, we have to then do a forced
restore of the users requested configuration as soon as we handle the
lid event. Currently, this is done by calling the lowlevel CRTC
configuration functions di
On Fri, Jun 07, 2013 at 03:31:20PM +0300, Jani Nikula wrote:
> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
> drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
> argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
>
> Signed-o
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’:
drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects
argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat]
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 f
Summary
We finished a new round of kernel testing. Generally, in this circle, 8 new
bugs are filed, 21 bugs are still opened, 3 WONTFIX bugs, 1 NOTOURBUG bugs, 2
Resolved fixed bugs, 8 Duplicated bugs, 6 bugs are closed.
Test Environment
commit e1c4dacebae25e2deeef4d189ac7456c5dd42366
Merge:
From: Ville Syrjälä
Don't enable the cursor until g4x_fixup_plane() had a chance to do
cast its magic spell.
Egbert writes:
"Today I had the chance to test this. First I tried
if I can still reproduce the blank with this patch
added when I disable my voodoo g4x_fixup_plane():
It turned out it
If we detect a ring is in a valid wait for another, just let it be.
Eventually it will either begin to progress again, or the entire system
will come grinding to a halt and then hangcheck will fire as soon as the
deadlock is detected.
This error was foretold by Ben in
commit 05407ff889ceebe383aa59
On Fri, Jun 07, 2013 at 09:00:00AM +0100, Chris Wilson wrote:
> On Fri, Jun 07, 2013 at 10:47:00AM +0300, ville.syrj...@linux.intel.com wrote:
> > This is a re-send of the trickle feed patches.
> >
> > Patches 1-3 are unchanged.
> >
> > I left out the VLV patch until I can clarify the situation a
On Fri, Jun 07, 2013 at 09:00:51AM +0100, Chris Wilson wrote:
> On Fri, Jun 07, 2013 at 07:51:10AM +0200, Daniel Vetter wrote:
> > On Sat, Jun 01, 2013 at 07:45:56PM +0200, Daniel Vetter wrote:
> > > We always limited the link bw calculations to 24bpp. Tested with
> > > my shiny new high-bpc screen
On Fri, Jun 07, 2013 at 10:47:00AM +0300, ville.syrj...@linux.intel.com wrote:
> This is a re-send of the trickle feed patches.
>
> Patches 1-3 are unchanged.
>
> I left out the VLV patch until I can clarify the situation a bit more.
>
> I also got sick of the amount of copy pasted code, so I al
On Fri, Jun 07, 2013 at 07:51:10AM +0200, Daniel Vetter wrote:
> On Sat, Jun 01, 2013 at 07:45:56PM +0200, Daniel Vetter wrote:
> > We always limited the link bw calculations to 24bpp. Tested with
> > my shiny new high-bpc screen, seems to work as advertised.
> >
> > Signed-off-by: Daniel Vetter
This is a re-send of the trickle feed patches.
Patches 1-3 are unchanged.
I left out the VLV patch until I can clarify the situation a bit more.
I also got sick of the amount of copy pasted code, so I also added another
patch to refactor the code a bit (patch 4)
_
From: Ville Syrjälä
Pull the code to disable trickle feed for all primary planes into a
separate function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 62 +
1 file changed, 19 insertions(+), 43 deletions(-)
diff --git a/drivers/gp
From: Ville Syrjälä
According to BSpec, trickle feed should be disabled for BW and
mobile CL. Those constraints seem to match all of our gen4 chipsets.
Trickle feed is disabled via the MI_ARB_STATE register instead of
per plane controls on gen4.
Reviewed-by: Chris Wilson
Signed-off-by: Ville S
From: Ville Syrjälä
We disable trickle feed in all the (relevant) clock gating functions,
except ironlake_init_clock_gating(). Copy paste the same code there as
well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8
1 file changed, 8 insertions(+)
diff --git a/dr
From: Ville Syrjälä
The docs say that the trickle feed disable bit is present (for primary
planes only, not video sprites) on CTG, and that it must be set
for ELK. Just set it for all g4x chipsets.
v2: Do it in init_clock_gating too
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
On Thu, Jun 06, 2013 at 08:58:10PM -0700, Ben Widawsky wrote:
> On Thu, Jun 06, 2013 at 10:45:42AM +0100, Chris Wilson wrote:
> > + if (ring->hangcheck.seqno == seqno) {
> > + if (ring_idle(ring, seqno)) {
> > + if (waitqueue_active(&ring->irq_q
64 matches
Mail list logo