On Thu, Oct 18, 2012 at 2:55 AM, Rodrigo Vivi rodrigo.v...@gmail.com 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
On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel
th...@ginkel.com 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
On Mon, Oct 15, 2012 at 5:11 PM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Oct 15, 2012 at 10:11:22AM +0200, Daniel Vetter wrote:
Hi Gregstable-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
On Wed, 17 Oct 2012 21:55:10 -0300, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Wed, Oct 17, 2012 at 4:22 PM, Daniel Vetter dan...@ffwll.ch 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
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,
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 daniel.vet...@ffwll.ch
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_dp_helper.c | 208
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_dp_helper.c | 50
drivers/gpu/drm/i915/intel_dp.c | 35 ++---
drivers/gpu/drm/radeon/atombios_dp.c | 24
radeon and intel use the exact same definition.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
Only compile-tested, due to a lack of nouveau dp hw. Should be
equivalent code though.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 26 +-
1 file changed, 5 insertions(+), 21 deletions(-)
diff --git
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 daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_dp_helper.c | 27 +++
drivers/gpu/drm/i915/intel_dp.c |
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 daniel.vet...@ffwll.ch
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
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
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 daniel.vet...@ffwll.ch
---
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
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
Or at least our best understanding of it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
Comment says for eaglelake/cantiga, but it's listed in the ilk table,
too. So apply it to both.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c |8
2 files changed, 9 insertions(+)
diff --git
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 daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_drv.h|2 ++
drivers/gpu/drm/i915/intel_sprite.c |
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 daniel.vet...@ffwll.ch
---
Found while strolling docs.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
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
---
On Thu, Oct 18, 2012 at 9:10 AM, Thilo-Alexander Ginkel
th...@ginkel.com wrote:
On Wed, Oct 17, 2012 at 1:26 AM, Thilo-Alexander Ginkel
th...@ginkel.com 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
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
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:
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
On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
Or at least our best understanding of it.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Looks legit. Just a minor alteration to include the w/a name inside
ilk_dummy_write() as well.
Reviewed-by: Chris
On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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); \
On Thu, Oct 18, 2012 at 1:17 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 18 Oct 2012 11:49:50 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
#define __i915_read(x, y) \
u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
u##x val = 0; \
+ if
On Thu, 18 Oct 2012 11:49:51 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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 daniel.vet...@ffwll.ch
Looks harmless due to the massive number of other p/c errata
On Thu, 18 Oct 2012 11:49:52 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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
On Thu, Oct 18, 2012 at 10:49 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
On Thu, 18 Oct 2012 11:49:53 +0200, Daniel Vetter daniel.vet...@ffwll.ch
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().
Or at least our best understanding of it.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
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 ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 13
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
On Wed, Oct 17, 2012 at 06:49:00PM -0300, Paulo Zanoni wrote:
Hi
2012/10/11 Daniel Vetter daniel.vet...@ffwll.ch:
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
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
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
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 daniel.vet...@ffwll.ch 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
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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,
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
___
Intel-gfx
On Thu, Oct 18, 2012 at 3:48 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Thu, Oct 18, 2012 at 4:15 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
___
Intel-gfx
Hi
2012/10/17 Damien Lespiau damien.lesp...@gmail.com:
From: Damien Lespiau damien.lesp...@intel.com
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
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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:
2012/10/17 Damien Lespiau damien.lesp...@gmail.com:
From: Damien Lespiau damien.lesp...@intel.com
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
Hi
2012/10/17 Damien Lespiau damien.lesp...@gmail.com:
From: Damien Lespiau damien.lesp...@intel.com
We were programming register 0x42020 twice on those platforms. Once
should be enough.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Reviewed-by: Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com
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 paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 3
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_pm.c |2 +-
2 files changed, 2 insertions(+), 1
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 b...@bwidawsk.net
Signed-off-by: Jesse Barnes
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
This allows us to get the right vblank interrupt frequency.
v2: pull in register definition
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c |7 +++
2 files changed, 9 insertions(+)
diff --git
So store into the scratch space of the HWS to make sure the invalidate
occurs.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |6 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 ++
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 jbar...@virtuousgeek.org
---
So we can write them properly.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
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
---
Hi
2012/10/17 Daniel Vetter daniel.vet...@ffwll.ch:
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
Hi
2012/10/17 Daniel Vetter dan...@ffwll.ch:
On Tue, Oct 16, 2012 at 02:49:58PM +0300, Jani Nikula wrote:
On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Much simpler and looks more like the M/N code inside intel_display.c.
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Mon, Oct 15, 2012 at 7:51 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
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 b...@bwidawsk.net
Signed-off-by: Jesse Barnes
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:
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
This allows us to get the right vblank interrupt frequency.
v2: pull in register definition
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_pm.c |7 +++
2 files changed, 9 insertions(+)
diff --git
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 jbar...@virtuousgeek.org
---
So store into the scratch space of the HWS to make sure the invalidate
occurs.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |6 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 22 ++
So we can write them properly.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
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
---
On Thu, Oct 18, 2012 at 02:14:52PM -0300, Paulo Zanoni wrote:
Hi
2012/10/17 Daniel Vetter dan...@ffwll.ch:
On Tue, Oct 16, 2012 at 02:49:58PM +0300, Jani Nikula wrote:
On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Much
Reported-and-tested-by: Francois Tigeot ftig...@wolfpond.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55375
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 file changed, 8 insertions(+)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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,
From: Paulo Zanoni paulo.r.zan...@intel.com
We need to check if any of the pipes is using TRANSCODER_EDP.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 25 +
1 file changed, 25 insertions(+)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
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 paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 19 ++-
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as the previous commits. Not renaming this one since it
exists since way before Haswell.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 16
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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 paulo.r.zan...@intel.com
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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
From: Paulo Zanoni paulo.r.zan...@intel.com
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
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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(-)
From: Paulo Zanoni paulo.r.zan...@intel.com
It's an important step :)
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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
From: Paulo Zanoni paulo.r.zan...@intel.com
Now that all the eDP enablement bits are there, we can actually try to
use the eDP.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Oct 18, 2012 at 06:21:31PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, Oct 18, 2012 at 06:21:34PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We need to check if any of the pipes is using TRANSCODER_EDP.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
I wonder whether it doesn't make more sense for haswell to return the
On Thu, Oct 18, 2012 at 06:21:35PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
On Thu, Oct 18, 2012 at 06:21:38PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
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
87 matches
Mail list logo
