Ok, that took all evening. And, I don't have a fix, but I do know a lot
more about the problem.
To recap:
On Sandybridge, sometimes, when you simultaneously change two
outputs, one of them turns into stripes, or as solid color.
Here's how I reproduce it:
First, connect
that triggers the double buffer latch.
Yup, that's what the docs say too. And, it fixes the stripey-monitor bug
nicely.
Thanks jbarnes!
Reviewed-by: Keith Packard kei...@keithp.com
Tested-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgppXHXHudULe.pgp
Description: PGP signature
On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard kei...@keithp.com wrote:
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I'd like to amend my reviewed by and say
On Thu, 28 Jul 2011 17:07:12 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+#define _TRANSA_CHICKEN2 0xf0064
+#define _TRANSB_CHICKEN2 0xf1064
+#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2, _TRANSB_CHICKEN2)
+#define TRANS_AUTOTRAIN_GEN_STALL_DIS (131)
+
On Fri, 29 Jul 2011 20:02:27 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
It's not meant to be and it causes havoc, from wavy/blurry output to no
sync. The other part of the patch on that bug was to walk the crtcs and
turn off SSC on the shared refclk if any output could not handle
On Fri, 29 Jul 2011 12:42:37 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
v2: again with the git send-email fail
v3: add macros for getting per-pipe override enable bits
v4: enable phase sync pointer on SNB and IVB configs as well
Yeah, this looks good -- a bit tricky in
Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1
On Tue, 26 Jul 2011 14:00:32 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
We should be writing this reg. The only question is whether we should
be trusting the BIOS values (which may have custom pulse duration
settings) or just unconditionally enabling hot plug for ports we care
On Mon, 1 Aug 2011 13:03:33 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ udelay(100);
udelay isn't my favorite function to use while waiting for hardware to
clean up. Do we expect to get into this path regularly? Is it just when
hardware is broken? How many times around
On Mon, 1 Aug 2011 14:14:35 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ for (try = 0; try 3; try++) {
+ status = I915_READ(ch_ctl);
+ if ((status DP_AUX_CH_CTL_SEND_BUSY) == 0)
+ break;
+ msleep(1);
+ }
+
+
On Mon, 1 Aug 2011 21:51:40 +0800, Wu Fengguang fengguang...@intel.com wrote:
1) intel_write_eld() is not called at all
It seems we need to call intel_write_eld() in other places besides
inside -mode_set(). Is -detect() the right place to do so? In
other words, are there established
fallert...@gmail.com
Cc: Ted Phelps phe...@gnusto.com
Cc: Gu Rui chaos.pro...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.c |2
On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang fengguang...@intel.com wrote:
Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(),
the drm_encoder object is there, however encoder-crtc is NULL at the
time.
Correct. encoder-crtc is set only when the output is active.
On Thu, 4 Aug 2011 07:10:27 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
Hi Keith,
On Wed, Aug 03, 2011 at 08:23:54PM -0700, Keith Packard wrote:
Jesse Barnes and I found a couple of issues where incorrect mode
setting would cause problems with RC6 enabled. We're hopeful
On Thu, 4 Aug 2011 16:29:50 +0800, Grissiom chaos.pro...@gmail.com wrote:
1) I got to know that I'm not the only one who encountered with this bug.
Even one failure would have been sufficient to revert this for 3.0 (and,
for 3.1 as well if we find more troubles).
2) I tried
Here's a fun sequence:
$ xrandr --output LVDS1 --auto --crtc 1
$ sudo chvt 1
(then switch back to X)
The LVDS goes black. Why? The LVDS is *disabled*. Turns out that the
cause was that after the mode was all nicely set,
intel_disable_pch_ports went and turned it back off.
Well, a couple of
During mode setting, check to make sure the panel power sequencing has
completed before doing further operations on the device. This
uncovered errors with DPMS not turning the device off as it was left locked.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_lvds.c
There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were locked making
the disable not work.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_lvds.c | 46 +++-
1 files
Just an extra parameter which isn't actually needed.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915
mistakenly
decide that all of these outputs were on pipe A and turn them off.
This is an extension of the CPT DP disable fix (why didn't I fix this then?)
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h | 13 ++-
drivers/gpu/drm/i915/intel_display.c | 60
Good questions! In general the audio functionalities should not
depend on the display activeness. There are even audio-only HDMI
devices. So I'll need to make intel_write_eld() work even without
information about the current display mode.
Yeah, we'll need to figure out what the ELD should
On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yep, looks fine. The only think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
So, I'd like to know if we could
c0f946bf41e49d9a10bcc0e4ae18a481bb8cdab3 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Sat, 6 Aug 2011 10:33:12 -0700
Subject: [PATCH 2/5] drm/i915: Leave LVDS registers unlocked
There's no reason to relock them; it just makes operations more
complex. This fixes DPMS where the panel registers were
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yep, it's safe and possible to do on pre-PCH
On Mon, 08 Aug 2011 11:54:22 -0700, Kamal Mostafa ka...@canonical.com wrote:
So what happened to that patch? Did it get lost or is it stuck
somewhere? I humbly ask that it be re-reviewed and pushed upstream.
Afraid it was forgotten -- Matthew, is this patch still useful?
--
On Mon, 8 Aug 2011 22:31:40 +0100, Matthew Garrett mj...@srcf.ucam.org wrote:
Yup. There's a small set of systems that appear to provide no firmware
control mechanism.
There were a few comments in that old thread about the patch as
submitted; is there an updated version?
--
On Tue, 9 Aug 2011 09:17:46 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
IVB uses the same interrupt reg layout as SNB, so add an IS_GEN7 to the
interrupt debugfs file.
Here's a list of code which uses IS_GEN6 but is not also using
IS_GEN7 or IS_IVYBRIDGE. Seems like some of these
On Tue, 9 Aug 2011 09:29:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
- I915_WRITE(GEN6_PMIMR, 0);
+ I915_WRITE(GEN6_PMIMR, ~GEN6_PM_DEFERRED_EVENTS);
spin_unlock_irq(dev_priv-rps_lock);
- /* enable all PM interrupts */
- I915_WRITE(GEN6_PMINTRMSK, 0);
+
On Wed, 10 Aug 2011 15:14:09 +0200, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
FYI, I'm using that on top of Linux 3.0 and 3.1-rc1 and it still works
fine.
Matthew -- shall I just merge the old patch? Or did you want to make
some changes?
--
keith.pack...@intel.com
On Wed, 10 Aug 2011 12:20:14 -0400, Andy Lutomirski l...@mit.edu wrote:
Can you ack at least this one:
Revert and fix drm/i915/dp: remove DPMS mode tracking from DP
(i.e. d2b996ac698aebb28557355857927b8b934bb4f9)
for -stable? It fixes an annoying regression in 3.0.
I'm working
a firmware or platform mechanism for changing the
backlight intensity on i915, so add native driver support.
Signed-off-by: Matthew Garrett m...@redhat.com
Cc: intel-gfx intel-gfx@lists.freedesktop.org
Tested-by: Michel Alexandre Salim sali...@fedoraproject.org
Signed-off-by: Keith Packard kei
On Fri, 12 Aug 2011 12:11:33 +0200, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
Matthew's last patch from July 16th applies without modification on top
of Linux 3.0 and 3.1-rc1, and applies with some offsets on top of
drm-intel-fixes.
I must have skipped right over it somehow.
On Fri, 12 Aug 2011 15:58:52 +0800, Sun, Yi yi@intel.com wrote:
Non-text part: multipart/mixed
Non-text part: multipart/alternative
drm/i915: enable/disable spread spectrum as needed on mode set
40031https://bugs.freedesktop.org/show_bug.cgi?id=40031
[Regression] testdisplay can't
On Sat, 13 Aug 2011 23:22:14 -0400, Hai Lan hai@intel.com wrote:
case 32:
if (fb-depth == 24)
dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
+ else if (fb-depth == 32)
+ dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
On Mon, 15 Aug 2011 19:38:34 +0200, Michel Alexandre Salim
sali...@fedoraproject.org wrote:
any update on the merge? I've not seen it anywhere on
It's merged locally; I'm struggling with an SSC bug that's sitting on
top of drm-intel-fixes and needs to either be fixed or reverted. In any
case,
PCH refclk update code
Keith Packard (6):
drm/i915: Wait for LVDS panel power sequence
drm/i915: Leave LVDS registers unlocked
drm/i915: Fix PCH port pipe select in CPT disable paths
drm/i915: Remove unused 'reg' argument to dp_pipe_enabled
drm/i915: Can't do accurate
On Mon, 22 Aug 2011 11:05:31 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This fixes a race where we may try to finish a page flip and decrement
the refcount even if our vblank_get failed and we ended up with a
spurious flip pending interrupt.
Fixes
On Wed, 31 Aug 2011 14:30:00 -0400, Andrew Lutomirski l...@mit.edu wrote:
Yes. On the latest -rc, the system still freezes hard when mutter starts up
if I set i915.semaphores=1.
Ok. You said that you were running compiz before and that failed, and
are now running mutter and that fails also?
On Sat, 3 Sep 2011 13:09:47 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Keith, worth cleaning this one up?
Yes, I think so. If nothing else, we'll have more people who actually
understand how the code is supposed to work, which should help with
future maintenance.
--
keith.pack...@intel.com
be larger than the display bpc.
Signed-off-by: Keith Packard kei...@keithp.com
Reported-by: Oliver Hartkopp socket...@hartkopp.net
Tested-by: Oliver Hartkopp socket...@hartkopp.net
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git
On Tue, 06 Sep 2011 15:11:12 +0200, Philipp Klaus Krause p...@spth.de wrote:
Here's the output from git-bisect:
d74362c9e45689d8d7e3d4bcf6681c4358ef4f2e is the first bad commit
commit d74362c9e45689d8d7e3d4bcf6681c4358ef4f2e
Author: Keith Packard kei...@keithp.com
Date: Thu Jul 28 14:47
On Wed, 7 Sep 2011 22:50:02 +0200, Zdenek Kabelac zdenek.kabe...@gmail.com
wrote:
Hi
This happened to today probably in the moment, LCD was turned off by
Xserver as a screenblank
My hw is Lenovo T61 4GB, intel driver.
Can you describe what your desktop software environment looks like? Are
On Wed, 7 Sep 2011 16:12:41 -0700, Ben Widawsky b...@bwidawsk.net wrote:
-update_semaphore(struct intel_ring_buffer *ring, int i, u32 seqno)
+update_mboxes(struct intel_ring_buffer *ring,
+ u32 seqno,
+ u32 mmio_offset)
Yeah, definitely like this change; lots less magic
On Tue, 13 Sep 2011 19:17:56 -0700, Ben Widawsky b...@bwidawsk.net wrote:
-static int
+/**
+ * gen6_add_request - Update the semaphore mailbox registers
+ *
+ * @ring - ring that is adding a request
+ * @mbox1_reg - mailbox address for RCS or VCS ring
+ * @mbox2_reg - mailbox address for
On Mon, 19 Sep 2011 10:41:27 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
Hello Keith,
I've not seen any replies to this patch in the last month, nor can I find it
in
your tree at http://cgit.freedesktop.org/~keithp/linux/ (I'd check kernel.org
as well, but it's still
Here's a sequence of eDP patches which are necessary to make the
driver work on the Sandybridge MacBook Air
The key trick was to make sure that the eDP power was applied before
trying to communicate with the device.
___
Intel-gfx mailing list
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h |5 -
drivers/gpu/drm/i915/intel_display.c | 12
2 files changed, 16 insertions(+), 1 deletions(-)
diff
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
Avoid any question about locked registers by just writing the unlock
pattern with every write to the register.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 14 +-
2 files changed, 14 insertions(+), 1
This value doesn't come directly from the VBT, and so is rather
specific to the particular DP output.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 35 ---
2 files changed, 16
an awfully long time.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/intel_dp.c | 56 --
2 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers
is respected before trying to turn it back on.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
This is a single patch which cleans up almost all of the whitespace
errors in the i915 driver. It currently merges cleanly with your fdo
drm-core-next tree.
I've checked this patch quite carefully, examining the .o files with
objdump -s to make sure nothing significant changed. The only thing
Make the default FBC behaviour chipset specific, allowing us to turn
it on by default for everything except Ironlake where it has been
seen to cause trouble with screen updates.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm
On Mon, 19 Sep 2011 21:25:03 -0700, Ben Widawsky b...@bwidawsk.net wrote:
When doing a GTT mapping, the pages are not backed until taking a fault.
If we know that the object is write only, when the fault happens we do not
need
to make the pages coherent with the CPU. This allows for semi
On Tue, 20 Sep 2011 07:18:16 +0100, Magnus Kessler magnus.kess...@gmx.net
wrote:
As the default is no longer off on all chipset, shouldn't this debug
message
be changed to simply read fbc disabled per module param\n?
Sure.
--
keith.pack...@intel.com
pgpwIAOSjUG4j.pgp
Description: PGP
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
v2: set the hotplug bits in the irq post-install hook, just
like we do for pre-PCH hardware.
drivers/gpu/drm/i915/i915_irq.c | 24
drivers
On Tue, 20 Sep 2011 15:17:38 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
- if (on) {
- intel_sdvo_write_cmd(intel_sdvo, SDVO_CMD_GET_HOT_PLUG_SUPPORT,
NULL, 0);
- status = intel_sdvo_read_response(intel_sdvo, response, 2);
+
On Tue, 20 Sep 2011 17:24:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Tue, 20 Sep 2011 08:47:21 -0700, Keith Packard kei...@keithp.com wrote:
We were relying on the BIOS to set these bits, which doesn't always
happen.
Do we need to clear IRQ bits on uninstall, for example
On Tue, 20 Sep 2011 12:41:16 +0200, Rainer Dorsch m...@bokomoko.de wrote:
I am wondering what I could do to figure out the root cause of the problem. I
forgot to try, but I assume, that I could ssh into the machine and do some
diagnosis, when the problem occurs. Are there logs which could
On Tue, 20 Sep 2011 17:38:37 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
This interacts badly with the need I've found to call this function every
time
a hotplug interrupt comes through (explained below) - I'm not sure how to
track back from the encoder (which gets the
On Tue, 20 Sep 2011 17:57:21 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
Sounds perfectly reasonable to me. I'll whip up patch v5 before I head home
tonight.
Thanks much, I hate to bikeshed this far, but I doubt anyone else will
ever go back and rework this code later on.
On Tue, 20 Sep 2011 18:31:25 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
+ /* Set up hotplug command - note paranoia about contents of reply.
+ * We simply clear out the bits we understand, and hope that
+ * the rest are in good shape for the hardware.
+
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This one mixes up lots of cleanups plus the EDID read with the power
changes.
I think the cleanups are;
1) edp checks inside vdd_on and vdd_off to make the other code a bit
easier to read.
2) Hold VDD on
On Wed, 21 Sep 2011 09:47:59 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I'm worried this makes our PPS even more complex and hard to follow.
I'd rather see VDD AUX applied only when we need it (dpms, mode set and
detect; for hotplug we can assume the panel is alive) and that we
On Wed, 21 Sep 2011 10:08:13 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
I'm clearing the bits (= not |=). I could respin setting it to 0, but that
takes me even further from the old (commented out) code, and I'd really want
someone to check SDVO specs before doing that.
On Wed, 21 Sep 2011 14:23:01 +0200, Rainer Dorsch m...@bokomoko.de wrote:
Hello,
after resuming my graphics card sometimes does not come up (see my post
yesterday).
Comparing drm outputs with drm.debug=6 in syslog reveals among others
[drm:intel_crt_detect], CRT not detected via
On Wed, 21 Sep 2011 16:18:55 +0100, Simon Farnsworth
simon.farnswo...@onelan.co.uk wrote:
I'm ANDing the value returned by hardware with 3 - I should be ANDing it with
an appropriate ~3. The rest of the code (setting those bits in
intel_sdvo_dvi_init based on what functions I have) should
On Wed, 21 Sep 2011 18:15:27 +0200, Rainer Dorsch m...@bokomoko.de wrote:
Since I can ssh into the machine, when the problem occurs, are there some
diagnosis scripts/tools I could run?
Hrm. As far as I can tell, we're turning on the monitor successfully.
You might try playing with xrandr
On Thu, 22 Sep 2011 10:36:12 +0200, Rainer Dorsch m...@bokomoko.de wrote:
This kind of output I do not see in the syslog anymore during regular
operation now (is that the 10-second polling?):
Yes. So, the patch is definitely included.
Let me know if it actually helps your suspend/resume
On Thu, 22 Sep 2011 10:00:14 -0400, Adam Jackson a...@redhat.com wrote:
This code is still present in Linus' tree, and still crap. Any
reviewers for this series?
It all looks reasonable to me, and Chris reviewed or ack'd every patch
but #4, which looks reasonable on the surface to me.
Are
use SSC?
I've tested this on LVDS and CPU-connected eDP with and without SSC and
it seems to work for me.
From ea63d98df915f81c80cf4f91bf9d1bcaece7fce0 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Thu, 22 Sep 2011 12:01:57 -0700
Subject: [PATCH 1/3] drm/i915: Fix PCH SSC
On Fri, 23 Sep 2011 08:25:13 +0530, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yeah that sounds good. (2) and (3) are ok cleanups, but it would be
best if they were a separate patch just in case the subtle timing
change breaks the panel power sequencing state machine.
Ok, I'll split
On Fri, 23 Sep 2011 09:06:31 -0300, Paulo Zanoni przan...@gmail.com wrote:
If you look at the patch posted on comment #20 of bug #38750 [0],
you'll see that it checks on the video bios for a field called
display_clock_mode and then uses this field in the following code:
+ if
On Fri, 23 Sep 2011 21:05:37 +0200, Rainer Dorsch m...@bokomoko.de wrote:
Are there any other data I could gather to figure out what is going
wrong?
Oh, have we gotten register dumps from a working vs non-working resume?
git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools
On Mon, 26 Sep 2011 20:16:04 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
PIPE_CONTROL and its workarounds is a very bitter pill to swallow if
MI_FLUSH continues to function.
If you look at the simulator source code, you'll see that it implements
MI_FLUSH as a specific kind of
On Fri, 23 Sep 2011 20:07:52 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Fri, 23 Sep 2011 09:15:05 -0700, Keith Packard kei...@keithp.com wrote:
What I didn't find there was any mention of the display_clock_mode
field; perhaps jbarnes has newer VBIOS sources or actual BDB
On Mon, 26 Sep 2011 13:56:17 -0700, Keith Packard kei...@keithp.com wrote:
So, what I think we should be doing is using display_clock_mode to
select between ck505 and internal clock source on pre-PCH hardware. For
PCH hardware, we unconditionally use the ck505 source for the non-SSC
reference
Here's a patch sequence which cleans up a bunch of PCH refclk related
bits. There are a couple of questionable patches that I'd like to see
people look at:
[PATCH 6/9] drm/i915: Fix PCH SSC reference clock settings
[PATCH 9/9] drm/i915: Initialize PCH refclks at modeset init time
Here's the
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_bios.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 61abef8..4c530fa 100644
--- a/drivers/gpu/drm/i915
This tells the driver whether a CK505 clock source is available on
pre-PCH hardware. If so, it should be used as the non-SSC source,
leaving the internal clock for use as the SSC source.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu
Allow SSC to be enabled even when the BIOS disables it for testing SSC paths.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_drv.c |4 ++--
drivers/gpu/drm/i915/intel_display.c |4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git
This includes whether an eDP panel is present, and whether that should
use SSC (and at what frequency)
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_bios.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 96 +-
1 files changed, 59 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6039496..f35 100644
This eliminates VGA shimmer on some Ironlake machines which have a
CK505 clock source.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
On Tue, 27 Sep 2011 10:01:33 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Oddly in the diagram SSC4 is given as a 100MHz clock that can be used for
any output other than DP_A. However, the configuration register marks that
as being a test-only mode.
Ok, it's all irrelevant -- the only
On Tue, 27 Sep 2011 17:47:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Mon, 26 Sep 2011 23:11:43 -0700, Keith Packard kei...@keithp.com wrote:
The PCH refclk settings are global, so we need to look at all of the
encoders, not just the current encoder when deciding how
On Tue, 27 Sep 2011 17:56:39 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Ah, now I see why we moved from using the active configuration earlier. ;-)
My evil plan is revealed!
Doesn't this prevent us from ever using SSC though, as virtually every
single PCH machine has HDMI encoders
On Wed, 28 Sep 2011 10:09:13 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
My understanding was that we could not enable SSC at all if we had a VGA,
DVI/HDMI or TV output; DP may or may not work with SSC.
Yeah, which makes no sense at all. If this were true, we'd have to turn
off the
On Wed, 28 Sep 2011 15:22:48 -0300, Paulo Zanoni przan...@gmail.com wrote:
I also tested the patch you sent today 1 hour ago (inline in one of
the emails) and things still work with it. I'll keep using these
patches since they fix my laptop. Any problem will be reported.
Thanks. I think we're
The reference clock configuration must be done before any mode setting
can occur as all outputs must be disabled to change
anything. Initialize the clocks after turning everything off during
the initialization process.
Also, re-initialize the refclk at resume time.
Signed-off-by: Keith Packard
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.
Given the length of
We're going to assume that EDID is more reliable than the VBT tables
for eDP panels, which is notably true on MacBook machines where the
VBT contains completely bogus data.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 ++--
1 files
We were relying on the BIOS to set these bits, which doesn't always
happen.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/i915_reg.h |5 -
2 files changed, 28 insertions(+), 1 deletions(-)
diff
There's no reason to enforce a 300ms delay during eDP mode setting.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
This masks out all interrupts and ack's any pending ones at IRQ
uninstall time to make sure we don't receive any unexpected interrupts
later on.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_irq.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff
Verify that the eDP VDD is on, either with the panel being on or with
the VDD force-on bit being set.
This demonstrates that in many instances, VDD is not on when needed,
which leads to failed EDID communications.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
201 - 300 of 603 matches
Mail list logo
