Summary
We finished a new round of kernel testing. Generally, in this circle, one bug
are re-opened, 12 bugs are still open.
Test Environment
Kernel: (drm-intel-testing)6760818aad5622d7f20d7f1c45d75a8165aeaf24
Some additional commit info:
Merge: 39bc66c be3cd5e
Author: Daniel Vetter
Date
On Thu, Oct 18, 2012 at 06:21:38PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
Again, I think we can drop the hunks for the load detect code and the pch
stuff for now. For the pch stuff I think we'll better do that once we give
vga a good look.
-Daniel
> ---
On Thu, Oct 18, 2012 at 06:21:37PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Same thing as the previous commits. Not renaming this one since it
> exists since way before Haswell.
>
> Signed-off-by: Paulo Zanoni
Again I think we can drop the fdi hunks here. We better keep the set_m_n
On Thu, Oct 18, 2012 at 06:21:35PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Because the PIPECONF register is actually part of the CPU transcoder,
> not the CPU pipe.
>
> Ideally we would also rename PIPECONF to TRANSCONF to remind people
> that they should use the transcoder instead o
On Thu, Oct 18, 2012 at 06:21:34PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need to check if any of the pipes is using TRANSCODER_EDP.
>
> Signed-off-by: Paulo Zanoni
I wonder whether it doesn't make more sense for haswell to return the
transcoder in the encoder->get_hw_state fun
On Thu, Oct 18, 2012 at 06:21:31PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Before Haswell we used to have the CPU pipes and the PCH transcoders.
> We had the same amount of pipes and transcoders, and there was a 1:1
> mapping between them. After Haswell what we used to call CPU pipe w
From: Paulo Zanoni
Now that all the eDP enablement bits are there, we can actually try to
use the eDP.
Signed-off-by: Paulo Zanoni
---
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/drivers/gpu/drm/i915/in
From: Paulo Zanoni
It's an important step :)
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 18 --
drivers/gpu/drm/i915/intel_dp.c | 11 ---
drivers/gpu/drm/i915/intel_drv.h | 4
3 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 15 +--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 6 --
3 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/
From: Paulo Zanoni
The cdclk frequency is not always the same, so the value here should
be adjusted to match it.
Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c30cb14..08881f1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++
From: Paulo Zanoni
See the documentation for the DDI_FUNC_CTL register, EDP Input Select
bits: when the EDP input selection is B, the VTOTAL_B must be
programmed with the VTOTAL_EDP value, same thing for selection C.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
From: Paulo Zanoni
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 7 ++---
drivers/gpu/drm/i915/i915_reg.h | 14 +-
drivers/gpu/drm/i915/intel_crt.c | 6 ++---
drivers/gpu/drm/i915/intel_display.c | 52 +++-
4 files chan
From: Paulo Zanoni
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_display.c | 12 ++--
drivers/gpu/drm/i915/intel_
From: Paulo Zanoni
Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 19 ++-
drivers/gpu/drm/i915/intel_ddi.c | 18 +-
2 files c
From: Paulo Zanoni
Because the PIPECONF register is actually part of the CPU transcoder,
not the CPU pipe.
Ideally we would also rename PIPECONF to TRANSCONF to remind people
that they should use the transcoder instead of the pipe, but let's
keep it like this for now since most Gens still name i
From: Paulo Zanoni
We need to check if any of the pipes is using TRANSCODER_EDP.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/inte
From: Paulo Zanoni
Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new
From: Paulo Zanoni
This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcod
From: Paulo Zanoni
Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A
From: Paulo Zanoni
Hi
Now that DP is merged, time for eDP :)
Most of the patches here exist because on Haswell what we used to call "CPU
pipe" was split into "CPU pipe" and "CPU transcoder" (and we still have the "PCH
transcoder") and now we have 3 CPU pipes (A, B and C) and 4 CPU transcoders (
Reported-and-tested-by: Francois Tigeot
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lv
On Thu, Oct 18, 2012 at 02:06:28PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/10/17 Daniel Vetter :
> > Found while strolling for ilk workarounds since this one is listed
> > there, too. I think that's a mistake though, since the w/a isn't
> > listed for snb/ivb, and the relevant register doesn't se
On Thu, Oct 18, 2012 at 02:14:52PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/10/17 Daniel Vetter :
> > On Tue, Oct 16, 2012 at 02:49:58PM +0300, Jani Nikula wrote:
> >> On Mon, 15 Oct 2012, Paulo Zanoni wrote:
> >> > From: Paulo Zanoni
> >> >
> >> > Much simpler and looks more like the M/N code i
So we can write them properly.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6f03b26..39c53ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++
So store into the scratch space of the HWS to make sure the invalidate
occurs.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |6 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 ++
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
3 files c
"If ENABLED, PIPE_CONTROL command will flush the in flight data written
out by render engine to Global Observation point on flush done. Also
Requires stall bit ([20] of DW1) set."
So set the stall bit to ensure proper invalidation.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_rin
This allows us to get the right vblank interrupt frequency.
v2: pull in register definition
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c |7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250
Reviewed-by: Ben Widawsky
Signed-off-by: Jesse Barnes
---
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 15328a3..969
Workaround for dual port PS dispatch on GT1.
v2: pull in register definition & offset handling
v3: use IVB GT1 macro to get the right regs (Ben)
v4: add for VLV too (Ben)
v5: don't read the reg, it's masked so we'll only enable the one extra bit
(Chris)
v6: use a _GT2 suffix for the second reg (C
Needs to be set on every context restore as well, so set it as part of
the initial state so we can save/restore it. Note this removes the IVB
workaround value from VLV and uses the default value, just adding in the
L3 cache aging disable bit, since the IVB value is wrong for VLV.
Signed-off-by: J
v2: use correct register
v3: remove extra hunks, pull in register definitions & offset check directly
v4: add GT1 vs GT2 distinction for IVB portion (Ben)
References: https://bugs.freedesktop.org/show_bug.cgi?id=50233
Reviewed-by: Ben Widawsky
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i91
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> This is the final remaining piece of Haswell DP enablement. After this
> patch, just calling intel_dp_init on any port will make DP work. We
> still do not do this because we're currently initializing HDMI on all
> the
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Previous patch "drm/i915: add basic Haswell DP link train bits"
> implemented the basic structure to set the voltage levels and training
> patterns. This patch adds the higher-level bits that are part of the
> mode set
Hi
2012/10/17 Daniel Vetter :
> On Tue, Oct 16, 2012 at 02:49:58PM +0300, Jani Nikula wrote:
>> On Mon, 15 Oct 2012, Paulo Zanoni wrote:
>> > From: Paulo Zanoni
>> >
>> > Much simpler and looks more like the M/N code inside intel_display.c.
>>
>> Reviewed-by: Jani Nikula
>
> Merged up to this p
Hi
2012/10/17 Daniel Vetter :
> Found while strolling for ilk workarounds since this one is listed
> there, too. I think that's a mistake though, since the w/a isn't
> listed for snb/ivb, and the relevant register doesn't seem to exist on
> ilk.
>
> Signed-off-by: Daniel Vetter
Tested-by: Paulo
So we can write them properly.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6f03b26..39c53ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++
"If ENABLED, PIPE_CONTROL command will flush the in flight data written
out by render engine to Global Observation point on flush done. Also
Requires stall bit ([20] of DW1) set."
So set the stall bit to ensure proper invalidation.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_rin
Workaround for dual port PS dispatch on GT1.
v2: pull in register definition & offset handling
v3: use IVB GT1 macro to get the right regs (Ben)
v4: add for VLV too (Ben)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c |1 +
drivers/gpu/drm/i915/i915_reg.h |5 +
driv
So store into the scratch space of the HWS to make sure the invalidate
occurs.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |6 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 ++
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
3 files c
This allows us to get the right vblank interrupt frequency.
v2: pull in register definition
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c |7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250
Reviewed-by: Ben Widawsky
Signed-off-by: Jesse Barnes
---
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 15328a3..969
v2: use correct register
v3: remove extra hunks, pull in register definitions & offset check directly
v4: add GT1 vs GT2 distinction for IVB portion (Ben)
References: https://bugs.freedesktop.org/show_bug.cgi?id=50233
Reviewed-by: Ben Widawsky
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i91
Needs to be set on every context restore as well, so set it as part of
the initial state so we can save/restore it.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/d
From: Paulo Zanoni
We have to write the correct values inside intel_dp_set_m_n and then
prevent these values from being overwritten later.
V2: Unconfuse double negation.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 7
Hi
2012/10/17 Damien Lespiau :
> From: Damien Lespiau
>
> We were programming register 0x42020 twice on those platforms. Once
> should be enough.
>
> Signed-off-by: Damien Lespiau
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c |6 --
> 1 files changed, 0 insertions
2012/10/17 Damien Lespiau :
> From: Damien Lespiau
>
> With the consolidated registers, it appears that we're setting the same
> bis several times. Let's just collect the bit we want to set and program
s/bis/bits/
> it once.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
> DP we need to do this earlier, and the values written to the register
> are also different.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Damien Le
Hi
2012/10/17 Damien Lespiau :
> From: Damien Lespiau
>
> Register 0x42020 was defined twice under the names PCH_DSPCLK_GATE_D and
> ILK_DSPCLK_GATE. This patch consolidate the 2 sets of defines in one.
>
> The transforms done are:
>
> PCH_DSPCLK_GATE_D-> ILK_DSPCLK_GATE_D
> ILK_DSPCLK_GATE
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Thu, Oct 18, 2012 at 3:48 PM, Alex Deucher wrote:
> On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> I've frustrated myself the last few days yelling at our link training code.
>> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
>> set of dp h
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The old rule that the AUX registers are just an offset (+4 and +10)
> from output_reg is not true anymore, since output_reg in on the CPU
> and some AUX regs are on the PCH.
Right, dp.output_reg is now DDI_BUF_CTL(port
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There'
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> Hi all,
>
> I've frustrated myself the last few days yelling at our link training code.
> Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
> set of dp helper functions. So I've started to extract a few.
>
> There'
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter wrote:
> This requires a few changes since that dpcd value is above the
> range currently cached by radeon. I've check the dp specs, and
> above 0xf there's a big gap and nothing that looks like we should
> cache it while a given device is plugged in.
Single-threaded forcewake was only used on some early pre-production
ivybridge machines, all the latest ones should use mt forcewake. And
we already assume this in other places of the code (e.g. DERRMR
support in the ddx, or the latest intel_gt_reset patch to reset any
lingering forcewake reference
On Wed, Oct 17, 2012 at 06:49:00PM -0300, Paulo Zanoni wrote:
> Hi
>
> 2012/10/11 Daniel Vetter :
> > We now no longer rely on this.
> >
> > This is step 1 on a long journey to rid us of the save/restore
> > madness, which tends to lightly paper over many issues, and cause
> > tons of bad things i
Comment says that this applies to earlier gens, too. Since two more
MI_NOOP's can't hurt that much, I've figured I'll apply this w/a down
to gen2.
v2: Correct the ringbuffer dword count for gen3, spotted by Chris
Wilson.
v3: Fixup the comments.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/
Or at least our best understanding of it.
v2: Fixup commit message and put the wa name into the comment block.
And actually update the commit, too.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
Or at least our best understanding of it.
Reviewed-by: Chris Wilson
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7837e5..c3f4f04 1006
On Thu, 18 Oct 2012 11:49:53 +0200, Daniel Vetter
wrote:
> Unfortunately this requires a bit of book-keeping to return the
> right values for get_colorkey and to set things up correctly
> when re-enabling the plane.
Needs to worry about per-pipe values and ilk_get_colorkey().
Maybe the code woul
On Thu, Oct 18, 2012 at 10:49 AM, Daniel Vetter wrote:
> +static void
> +ilk_dummy_write(struct drm_i915_private *dev_priv)
> +{
> + /* Ilk w/a: Issue a dummy write to wake up the chip from rc6 before
> +* touching it for real. MI_MODE is masked, hence harmless to write 0
> +
On Thu, 18 Oct 2012 11:49:52 +0200, Daniel Vetter
wrote:
> Comment says that this applies to earlier gens, too. Since two more
> MI_NOOP's can't hurt that much, I've figured I'll apply this w/a down
> to gen2.
>
> v2: Correct the ringbuffer dword count for gen3, spotted by Chris
> Wilson.
>
> S
On Thu, 18 Oct 2012 11:49:51 +0200, Daniel Vetter
wrote:
> Comment says for eaglelake/cantiga, but it's listed in the ilk table,
> too. So apply it to both.
>
> Signed-off-by: Daniel Vetter
Looks harmless due to the massive number of other p/c errata and that
pipelined render cache flushes hav
On Thu, Oct 18, 2012 at 1:17 PM, Chris Wilson wrote:
> On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter
> wrote:
>> #define __i915_read(x, y) \
>> u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
>> u##x val = 0; \
>> + if (IS_GEN5(dev_priv->dev)) \
>> +
On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter
wrote:
> #define __i915_read(x, y) \
> u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
> u##x val = 0; \
> + if (IS_GEN5(dev_priv->dev)) \
> + ilk_dummy_write(dev_priv); \
IS_GEN5(dev_priv->dev) just make
On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter
wrote:
> Or at least our best understanding of it.
>
> Signed-off-by: Daniel Vetter
Looks legit. Just a minor alteration to include the w/a name inside
ilk_dummy_write() as well.
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open
Hi Dave,
The big thing is the disabling of the hsw support by default, cc: stable.
We've aimed for basic hsw support in 3.6, but due to a few bad
happenstances we've screwed up and only 3.8 will have better modeset
support than vesa. To avoid yet another round of fallout from such a
gaffle on for
Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.
Reported-by:
Si
Am Donnerstag, den 18.10.2012, 09:10 +0200 schrieb Thilo-Alexander Ginkel:
> On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel wrote:
> > since upgrading from kernel 3.4.10 to 3.5.x or 3.6.2 (on Kubuntu
> > 12.04) I am getting sporadic (but frequent) lockups when switching
> > displays using
On Thu, Oct 18, 2012 at 9:10 AM, Thilo-Alexander Ginkel
wrote:
> On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel
> wrote:
>> since upgrading from kernel 3.4.10 to 3.5.x or 3.6.2 (on Kubuntu
>> 12.04) I am getting sporadic (but frequent) lockups when switching
>> displays using xrandr:
>>
Found while strolling docs.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index aa77639..45ffb2c 100644
--- a/drivers/gpu/drm/i915/intel_p
Comment says that this applies to earlier gens, too. Since two more
MI_NOOP's can't hurt that much, I've figured I'll apply this w/a down
to gen2.
v2: Correct the ringbuffer dword count for gen3, spotted by Chris
Wilson.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c |
Unfortunately this requires a bit of book-keeping to return the
right values for get_colorkey and to set things up correctly
when re-enabling the plane.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h|2 ++
drivers/gpu/drm/i915/intel_sprite.c | 27
Comment says for eaglelake/cantiga, but it's listed in the ilk table,
too. So apply it to both.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c |8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg
Or at least our best understanding of it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7837e5..c3f4f04 100644
--- a/drivers/gpu/drm/i9
Hi all,
Dave reported a gpu hang regression on his ilk, likely due to the re-enabled rc6
support (but not confirmed). So I've scrounged through the w/a database and
found a few bits. Preliminary verdict is that this seems to prevent the hangs.
If that stands for a few more days, I'd like to merge
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
drivers/gpu/drm/nouveau/nouveau_dp.c | 2 +-
drivers/gpu/drm/radeon/atombios_dp.c | 7 +--
include/drm/drm_dp_helper.h | 7 +++
4 files changed, 11 insertions(+), 22 deletions(-)
dif
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 28
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/radeon/atombios_dp.c | 32 +++-
include/drm/drm_dp_helper.h | 8
4 files changed
Only really required for dp 1.2. I've hoped this would help with some
link training woes I'm fighting, but alas those are only dp 1.1
devices.
Also move a comment that went misplaced in the recent refactorings to
the right spot again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_
This requires a few changes since that dpcd value is above the
range currently cached by radeon. I've check the dp specs, and
above 0xf there's a big gap and nothing that looks like we should
cache it while a given device is plugged in. It's also the same value
that i915.ko uses.
Hence extend the
nouveau again score with an impressive density of magic numbers.
Again only compile-tested due to lack of hw, but should be equivalent
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/g
Safe for the minor difference that the intel versions get an offset
into the link_status as an argument, both are the same again.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
drivers/gpu/drm/i915/intel_dp.c | 30 ++--
Only compile-tested, due to a lack of nouveau dp hw. Should be
equivalent code though.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dri
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/radeon/atombios_dp.c | 25 +
include/drm/drm_dp_helper.h | 2 ++
3 files changed, 5 insertions(+), 26 deletions(-)
d
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dp_helper.c | 50
drivers/gpu/drm/i915/intel_dp.c | 35 ++---
drivers/gpu/drm/radeon/atombios_dp.c | 24 ++---
inclu
I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_dp_helper.c | 208
drivers/gpu/drm/d
Hi all,
I've frustrated myself the last few days yelling at our link training code.
Comparing the i915 code to radeon and nouveau I've noticed the lack of a nice
set of dp helper functions. So I've started to extract a few.
There's lots more that we can do I think (link configuration selection, t
On Wed, 17 Oct 2012 21:55:10 -0300, Rodrigo Vivi wrote:
> On Wed, Oct 17, 2012 at 4:22 PM, Daniel Vetter wrote:
>
> > On Mon, Oct 15, 2012 at 05:16:23PM -0300, Rodrigo Vivi wrote:
> > > On the worst scenario, users with new hardwares and old kernel from
> > enabling times can get black screens.
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH wrote:
> On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
>> Hi Greg&stable-team,
>>
>> The below patch papers over a graphics corruption issue in 3.5/3.6. The
>> regression happened due to pwrite tunings in 3.5, which made cpu relocations
>>
On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel
wrote:
> since upgrading from kernel 3.4.10 to 3.5.x or 3.6.2 (on Kubuntu
> 12.04) I am getting sporadic (but frequent) lockups when switching
> displays using xrandr:
> [...]
BTW, the lockups also happen with i915.i915_enable_rc6=1 (instead
On Thu, Oct 18, 2012 at 2:55 AM, Rodrigo Vivi wrote:
> To be honest I don't like any of those i915_... all redundants i195.i915_
Yeah, unfortunately we can't kill them because tons of people set
random options they've found while googling (i915.rc6=7 anyone?) and
if we rename them, the module won
95 matches
Mail list logo
