On Fri, 11 Jun 2010 18:00:09 -0400, Alex Deucher alexdeuc...@gmail.com wrote:
Disables the crts as per dpms and also disables the ppll
associated with the crtc. This should save additional power.
Any reason the pll isn't just disabled for dpms as well?
--
keith.pack...@intel.com
On Thu, 8 Jul 2010 11:23:25 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
- a mechanism to attach a binary blob to an flink_to buffer name.
open_with_data returns the data. Userspace (typically libdrm)
decides the layout and versioning of the blob and the contents
will be
On Thu, 8 Jul 2010 09:49:26 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
That's the part I had trouble with as well. Passing the blob through
the kernel saves a little IPC but also seems unnecessary, and so rubs
against my kernel minimalist side...
Yeah, if the kernel doesn't need to
.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a51ee0..9ab8708 100644
--- a/drivers/gpu/drm/i915
only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 62 +-
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 38 insertions(+), 25 deletions
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Do these fixes help with the DP issues you've been seeing, Keith?
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
It appears that all users (crtc and encoders) are tracking dpms_mode, in
one form or another. Should we move this to core?
Sounds like a good idea. Would you prefer to do that yourself?
Is there any hardware
.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie airl...@gmail.com wrote:
don't you do this already? both radeon/nouveau handle DP replug fine,
I thought Intel would have been where I stole the code from.
There was a one-line bug. Patch already posted.
--
keith.pack...@intel.com
On Mon, 4 Oct 2010 01:15:08 +0200, Peter Stuge pe...@stuge.se wrote:
If there is the infrastructure to do so, then it seems that the 600ms
delay while polling unconnected monitors could easily be removed.
Newer hardware generates interrupts for VGA and TV hotplug events; older
hardware
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c
.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
V3: document Hotplug option in man page
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
man/intel.man |6 +++
src/Makefile.am|4 +-
src/intel.h| 12 +
src
On Mon, 4 Oct 2010 20:13:33 +1000, Dave Airlie airl...@gmail.com wrote:
We don't do dynamic connectors now, so adding locking with no way of
actually really testing it would just mean you'd probably have just as
much pain when you do add dyanamic connectors.
I looked in the radeon and nouveau
On Thu, 25 Nov 2010 11:10:58 -0500, Nick Bowler nbow...@elliptictech.com
wrote:
On 2010-11-25 16:58 +0100, Michal Hocko wrote:
[Let's add Rafael for regression tracking]
On Tue 23-11-10 13:32:34, Michal Hocko wrote:
Hi,
since early 2.6.37 (I haven't bisected when exactly) my screen
On Fri, 26 Nov 2010 11:45:38 +0300, Dan Carpenter erro...@gmail.com wrote:
Where are the patches? I pulled drm-next but I don't see them.
Looks like he hasn't merged them. I'm building drm-intel-next with this
and another patch.
I've pushed my bits to
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc_helper.c
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector-status
value instead of being discarded.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc_helper.c |7 ---
1 files changed, 4 insertions
On Sun, 5 Dec 2010 13:27:43 +0100, Florian Mickler flor...@mickler.org wrote:
On Fri, 26 Nov 2010 10:45:59 -0800
Keith Packard kei...@keithp.com wrote:
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector-status
On Wed, 08 Dec 2010 17:08:04 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 8 Dec 2010 17:34:24 +0100, Florian Mickler flor...@mickler.org
wrote:
Does that mean that the kernel regression will not be
fixed/worked-around for old userspace?
I think there is some confusion in
On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote:
Enabling and disabling the vblank interrupt (on devices that
support it) is cheap. So disable it quickly after each
interrupt.
So, the concern (and reason for the original design) was that you might
lose count of vblank
On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski l...@mit.edu wrote:
But five seconds is a *long* time, and anything short enough that the
interrupt actually gets turned off in normal use risks the same race.
Right, so eliminating any race seems like the basic requirement. Can
that be
38507bb3a67441425e11085d17d727f3b230f927 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Thu, 3 Feb 2011 16:57:28 -0800
Subject: [PATCH] drm: Only set DPMS ON when actually configuring a mode
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON
On Thu, 3 Feb 2011 17:11:14 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
Ok, patch looks sane, but it does leave me with the what about the
'fb_changed' case? question. Is that case basically guaranteed to not
change any existing dpms state?
None of the existing drivers turn
for this is that some ancient platforms wire this bit to
be go to max backlight, or at least that's why this was in the 2D
driver from which this code was derived.
Reviewed-by: Keith Packard kei...@keithp.com
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
keith.pack...@intel.com
pgpKhf3aaWCKj.pgp
On Fri, 11 Mar 2011 02:23:08 +0100 (CET), Indan Zupancic in...@nul.nu wrote:
Some nitpicks below. I know you're just restoring the original code,
but if we improve it we can as well do it now.
Let's pend these changes until after 2.6.38; the backlight code is
fragile enough without trying to
On Tue, 5 Apr 2011 01:38:31 +0100 (IST), Dave Airlie airl...@linux.ie wrote:
drm/i915: Reset GMBUS controller after NAK
We've got a report of a regression from this patch and have a fix in
review right now. Please don't merge this to master until that fix has
been verified and added to
On Mon, 4 Apr 2011 18:09:55 -0700, Linus Torvalds
torva...@linux-foundation.org wrote:
I'm not doing an -rc2 until tomorrow, though, so hopefully the issue
will be resolved and a fix pushed to me by then.
Should be resolved this evening; someone is trying to use an i2c address
of 0xa0, which
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie airl...@gmail.com wrote:
From: Dave Airlie airl...@redhat.com
This has always used a big hammer, but that hammer is probably
too big, I'm also not sure its necessary but at least this
should be safe.
Am I correct in reading the
On Mon, 11 Apr 2011 18:31:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
During panics? Just not lastclose. :)
I'm still mystified -- why is it useful to do more than one modesetting
operation on the video card?
--
keith.pack...@intel.com
pgp8O8IQun1Se.pgp
Description: PGP
Here's a couple of minor fixes for intel modesetting.
These should resolve the following bugs:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35977
References: https://bugs.freedesktop.org/show_bug.cgi?id=35903
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35796
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Are overlays/underlays not associated with a specific
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that matches my understanding as well. I've deliberately made the
implementation flexible there though, under the assumption that some
hardware allows a plane to be directed at more than one CRTC (though
On Mon, 25 Apr 2011 16:52:58 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
struct drm_mode_surface {
enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
int depth;
enum packing; /* some list of packing types? */
...
};
Might just make a uint32_t 'type',
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The defintion of the swap complete event was wrong; XEvents are only 32
bytes long, and with padding the swap event was longer. So use some
creative packing to get all the bits we want transmitted. Requires a
On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
We only spec a 32 bit swap count, so drop the high sbc field.
You're missing the explicit 16-bit padding field after 'event_type'
The documented encoding
http://www.opengl.org/registry/specs/INTEL/swap_event.txt
On Tue, 3 May 2011 14:08:58 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Fixed version below.
Reviewed-by: Keith Packard kei...@keithp.com
(assuming that the GLX protocol specification gets updated to match :-)
--
keith.pack...@intel.com
pgpc0zttIhtY3.pgp
Description: PGP signature
Here are a few very small changes for Intel mode setting.
They should fix the following bugs:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
The
This reverts commit 49183b2818de6899383bb82bc032f9344d6791ff.
Franz Melchior:
This patch introduces a bug on my infamous Acer Travelmate
5735Z-452G32Mnss: when KMS takes over, the frame buffer contents
get completely garbled up on screen, with colored stripes and
unreadable text (photo on
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files
/i915: split clock gating init into per-chipset functions
drm/i915: add Ivybridge clock gating init function
drm/i915: split PCH clock gating init
Keith Packard (1):
MAINTAINERS: Switch maintainer for drm/i915 to Keith Packard
MAINTAINERS |4
I've pushed four more patches to this branch for your merging pleasure.
* Disabling FBC on Ironlake to enable RC6 instead
Two patches for this are included.
The following changes since commit 645c62a5e95a5f9a8e0d0627446bbda4ee042024:
drm/i915: split PCH clock gating init (2011-05-13
On Tue, 17 May 2011 15:00:01 -0700, Keith Packard kei...@keithp.com wrote:
I've pushed four more patches to this branch for your merging pleasure.
And, one more which fixes non-eDP displays on Ironlake systems after the
Ivybridge merge. Sorry for not catching that in our testing
On Wed, 18 May 2011 20:15:05 +0200, Eric Leblond e...@regit.org wrote:
I confirm that it is working fine when enabling semaphore. Thanks a lot
for the workaround, it is a pleasure to have a real laptop again ;)
And, we'll keep trying to make it work without per-laptop
configuration...
--
On Sat, 21 May 2011 23:55:57 -0500, Matt Mackall m...@selenic.com wrote:
I've got a new Thinkpad x220 which won't wake up from suspend with
2.6.39, but works fine with 2.6.37.
I bisected it down to this cset:
On Sun, 22 May 2011 10:28:09 -0500, Matt Mackall m...@selenic.com wrote:
Appears to work, thanks.
Thanks for testing this.
Jesse and Chris: would be best to figure out what's going on here if
possible, otherwise we should consider submitting an FBC disable patch
for SNB to stable@
Matt:
This fixes a simple typo in the Ivybridge code -- an extra semicolon.
The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0:
drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge
(2011-05-18 15:14:39 -0700)
are available in the git repository at:
On Mon, 30 May 2011 12:48:26 +0200, Nicolas Kaiser ni...@nikai.net wrote:
if (mode-clock 2)
- return MODE_CLOCK_HIGH;
+ return MODE_CLOCK_LOW;
Seems obvious to me.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgplUHlaQ5pZw.pgp
On Fri, 3 Jun 2011 02:28:47 -0700, Joe Perches j...@perches.com wrote:
drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
Acked-by: Keith Packard kei...@keithp.com
Dave -- if you want to just merge this to your tree, that's fine with
me.
--
keith.pack...@intel.com
On Fri, 3 Jun 2011 21:09:39 +0800, Harry Wei jiaweiwei.xi...@gmail.com wrote:
(process:18294): gmime-CRITICAL **: g_mime_stream_filter_add: assertion
`GMIME_IS_FILTER (filter)' failed
From: Harry Wei harryxi...@gmail.com
When i compile kernel, it shows me two warnings
like below, so this
Mostly mode setting cleanups and fixes.
The following changes since commit 55922c9d1b84b89cb946c777fddccb3247e7df2c:
Linux 3.0-rc1 (2011-05-29 17:43:36 -0700)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
drm-intel-fixes
I'm trying to formalize the process for merging code into the drm/i915
driver. Here's a first draft, please send along your comments.
-keith
Right now, I'm merging patches destined for the 3.0 release
in a kernel.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
On Sun, 05 Jun 2011 16:23:43 +1000, Dave Airlie airl...@redhat.com wrote:
So when Linus is releasing rc4/5 you should really be cutting down stuff
going into your -next, and getting the tree ready for me to take. We can
probably add your tree direct to the -next git list as well so that we
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ melchior.fr...@gmail.com
wrote:
That's apparently the bug that I've submitted a patch for on 2011/5/31:
https://lkml.org/lkml/2011/5/31/393
I assume/hope it's still in someone's queue.
Yeah, we shouldn't need to call intel_enable_plane from
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Can you keep drm-intel-next fairly up to date with respect to the fixes
branch? I.e. keep it a superset of drm-intel-fixes for the most part?
Yes, I wanted to do that now, but -fixes is not a fast-forward from
I'll be away on vacation starting today until the 20th. Please work with
either Eric Anholt or Dave Airlie if there are critical issues in the
drm/i915 kernel driver.
--
keith.pack...@intel.com
pgp2GAjwRxlQS.pgp
Description: PGP signature
___
On Tue, 21 Jun 2011 16:21:33 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
Non-text part: multipart/mixed
Now, I have a Lenovo X201s, and if you need more information for
debugging purpose just let me know, otherwise just apply the patch
attached (on top of -rc4).
Given the number
On Tue, 21 Jun 2011 17:52:05 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
If you prefer that I open a bug on the kernel bugzilla to put all the
informations no problem.
I'm more interested in seeing how the dmesg output differs between the
working state (rc6=0) and the broken state
On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
On Tue, Jun 21, 2011 at 09:11:29AM -0700, Keith Packard wrote:
I'm more interested in seeing how the dmesg output differs between the
working state (rc6=0) and the broken state (rc6=1). Or is the machine
On Tue, 21 Jun 2011 20:47:57 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
Version: 6QET52WW (1.22 )
Release Date: 08/23/2010
Thanks. I'll see if I can't get an X201s upgraded to this version and
see if we can reproduce the problem you're having...
--
On Wed, 15 Jun 2011 13:32:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0defd42..a1a28fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -429,6 +429,9 @@
/resume forcewake lock fixes
Chris Wilson (1):
drm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge
Eric Anholt (1):
Revert drm/i915: Kill GTT mappings when moving from GTT domain
Keith Packard (1):
drm/i915: Call intel_enable_plane from i9xx_crtc_mode_set (again
A couple of forcewake fixes and and a patch to make page flip work on
IVB.
Sorry for the large diffstat; the IVB fix first splits out page flipping
into per-generation functions and then applies the IVB-specific version,
so the bulk of the change is just shuffling code around.
The following
which fixes these on my
system:
From 84a46e9ba3c077535c22a006c5da9988524a6b8b Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Wed, 29 Jun 2011 00:30:34 -0700
Subject: [PATCH] drm/i915: Hold struct_mutex during
i915_save_state/i915_restore_state
Lots of register access
(1):
drm/i915: Don't call describe_obj on NULL pointers
Chris Wilson (1):
drm/i915/overlay: Fix unpinning along init error paths
Jesse Barnes (2):
drm/i915: move IRQ function table init to i915_irq.c
drm/i915: apply HWSTAM writes to Ivy Bridge as well
Keith Packard (1
On Mon, 4 Jul 2011 13:27:51 +0100, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
Found this going over intel_bios.c and cross comparing it with the
Intel/IMG driver intel_bios.c
temp_mode = kzalloc(sizeof(*temp_mode), GFP_KERNEL);
This object is about 216 bytes long; would it be
On Tue, 12 Jul 2011 10:33:06 +0300, Pekka Enberg penb...@kernel.org wrote:
AFAICT, this problem is still there in 3.0-rc7. Keith, isn't it time
to revert commit a51f7a6 (drm/i915: enable rc6 by default) before
3.0 is out?
Yes. I'll put together a few tiny patches including this.
--
receiver capability bits on hotplug
drm/i915/dp: try to read receiver capabilities 3 times when detecting
drm/i915/dp: remove DPMS mode tracking from DP
drm/i915/dp: consolidate AUX retry code
drm/i915/dp: manage sink power state if possible
Keith Packard (2):
drm/i915
On Wed, 13 Jul 2011 19:22:14 +0200, Wolfram Sang w.s...@pengutronix.de wrote:
Is this one intentionally not in or did it slip through?
I thought I had replied to that -- it doesn't apply to either -fixes or
-next at this point. I can try to fix it, but I'd prefer it if you'd
figure out how
On Tue, 5 Jul 2011 09:55:34 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Alan Cox reported a missing check on the kmalloc return value for the
allocation of a temporary mode used for searching for the LVDS downlock
frequency. This allocation is roughly 200 bytes, a little too large to
invasive change.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Robse rob...@live.de
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 15 ++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
drm/i915: use pipe bpp in DP link bandwidth calculations
drm/i915: use pipe bpp when setting HDMI bpc
drm: bpp and depth changes require full mode sets
drm/i915: check for supported depth at fb init time
drm/i915: use pipe bpp in DP link bandwidth calculation
Keith
On Thu, 14 Jul 2011 09:50:07 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
The correct commit is 05bd42688dbc066d4e2689b6f73c0470601f788b, the one
you mentioned is Idling requires waiting for the ring to be empty.
We mentioned the 'Idling' fix as it may make RC6 work. Have you tried
On Thu, 14 Jul 2011 10:37:15 +0300, Pekka Enberg penb...@kernel.org wrote:
This if fixed in mainline as of commit
a94919eaddaa3fede1df8563ce4d761a75374645 (Revert drm/i915: enable
rc6 by default). Keith, it would have been nice to include a
'Reported-by' and/or a link to this discussion in
On Thu, 14 Jul 2011 19:00:26 +0200, Francesco Allertsen fallert...@gmail.com
wrote:
I have tried to boot with the latest git with the commit
05bd42688dbc066d4e2689b6f73c0470601f788b reverted (so I have the 'Idling
fix' and the rc6 enabled), but I have the same freeze.
Thanks.
--
/linux/kernel/git/keithp/linux-2.6.git
drm-intel-fixes
Chris Wilson (1):
drm/i915: Fix unfenced alignment on pre-G33 hardware
Keith Packard (1):
drm/i915: Add quirk to disable SSC on Lenovo U160 LVDS
drivers/gpu/drm/i915/i915_drv.h|5 ++-
drivers/gpu/drm/i915/i915_gem.c
i915_init_phys_hws.
I suspect we could remove the memset from intel_init_render_ring_buffer;
it seems entirely superfluous given the memset in i915_init_phys_hws.
From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Fri, 22 Jul 2011 10:44
On Sat, 23 Jul 2011 00:23:36 +0400, Kirill Smelkov k...@mns.spb.ru wrote:
What kind of a workaround are you talking about?
Just reverting the commit -- that makes your machine work, even if it's
wrong for other machines.
Sorry, to me it all looked like UMS is being ignored forever.
You're
On Sat, 23 Jul 2011 18:55:48 +0300 (EEST), Pekka Enberg penb...@kernel.org
wrote:
I know I sound like a broken record but I really wish you i915 devs were
little more eager to revert broken patches early rather than late. I mean,
this particular breakage was already bisected but nobody said
mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_irq.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm
On Mon, 25 Jul 2011 13:40:58 -0400, Andrew Lutomirski l...@mit.edu wrote:
Will test tonight.
Thanks.
It looks like there is a lot of hotplug activity when 'xset dpms force
off' gets run. (That's not a typo. I do mean off, not on.
Yup, that's what I've seen as well -- do a mode set to
to DRM_MODE_DPMS_ON, so the hotplug code would bail every
time. With that fixed, this patch should work for you *and* for others.
Care to give it a try?
From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Mon, 25 Jul 2011 22:37:51 -0700
Subject
Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dcc7ae6..45db810 100644
--- a/drivers
This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915
A was changed, any
display port outputs on pipe B would get disabled as
intel_disable_pch_ports would ensure that the mode setting operation
could occur on pipe A without interference from other outputs
connected to that pch port
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
If the connector is inserted or removed slowly, the hotplug line may
well change state before the data lines do. So, assume the user isn't
trying to fool us and give them 250ms to get the connector plugged or
unplugged.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
These three are simple cleanups to centralize all places where the
DPCD block was read from the device. Now
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter dan...@ffwll.ch wrote:
Two things I've noticed:
- Why not dev-mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter dan...@ffwll.ch wrote:
queue_delayed_work? Plays nicer with other workqueue-items.
Yeah, I'll change this.
--
keith.pack...@intel.com
pgpifulG3hqfz.pgp
Description: PGP signature
___
dri-devel
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 the lock shouldn't be held
around the call to the drm helper function. It queues some work that
also takes the mode config lock, which will break. So you can drop it
On Tue, 26 Jul 2011 13:02:35 +0100 (IST), Dave Airlie airl...@linux.ie wrote:
(and btw I know Keith has a lot of fixes into next merges, its hard to
balance the requirement about not merging with the fact his QA team need
to test merged trees and I want to pull what the QA team has tested).
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 Fri, 29 Jul 2011 13:55:35 +0100, Ben Brewer ben.bre...@codethink.co.uk
wrote:
I've added a global SSC (Spread Spectrum Clock) parameter to the i915
driver, since having SSC enabled breaks (distorts) VGA output on some
Core i5/i7 chips (see
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 18:01:39 -0400, Gene Heskett gene.hesk...@gmail.com wrote:
On Friday, July 29, 2011, Keith Packard wrote:
On Fri, 29 Jul 2011 13:55:35 +0100, Ben Brewer
ben.bre...@codethink.co.uk wrote:
I've added a global SSC (Spread Spectrum Clock) parameter to the i915
driver, since
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
activity to clear
drm: track CEA version number if present
drm/i915/hdmi: split infoframe setting from infoframe type code
drm/i915/hdmi: HDMI source product description infoframe support
drm/i915: allow cache sharing policy control
Keith Packard (14):
drm/i915: Skip
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 Fri, 5 Aug 2011 12:51:42 +0300, Pekka Enberg penb...@kernel.org wrote:
See the last email from Francesco. I don't know why you insist pushing
patches that are known to be fragile in the past without getting broad
Tested-by tags from people who have been affected in the past.
Yeah, we had
1 - 100 of 1027 matches
Mail list logo
