On Wed, 15 Jun 2011 13:32:56 -0700, Jesse Barnes
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 @@ static int
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 @@
On Tue, 21 Jun 2011 20:47:57 +0200, Francesco Allertsen 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...
--
keith.packard at intel.com
On Tue, 21 Jun 2011 18:42:09 +0200, Francesco Allertsen 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 17:52:05 +0200, Francesco Allertsen 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 (rc6=1). Or is the
On Tue, 21 Jun 2011 16:21:33 +0200, Francesco Allertsen 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 of X201s machines
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...
--
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.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
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 Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes
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
-next and I thought I
On Mon, 6 Jun 2011 19:20:06 +0200, Melchior FRANZ
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
i9xx_crtc_mode_set
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
On Sun, 05 Jun 2011 16:23:43 +1000, Dave Airlie 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
> can get the
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
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
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
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
Here's another handful of fixes that I had merged to
drm-intel-next. Once these are merged, I'll move drm-intel-fixes and
start putting stuff there for 3.0.
The following changes since commit 9e3c256d7d56a12a324945ce8e6347f93fa0:
drm/i915: initialize gen6 rps work queue on Sandy Bridge
On Fri, 3 Jun 2011 21:09:39 +0800, Harry Wei
wrote:
(process:18294): gmime-CRITICAL **: g_mime_stream_filter_add: assertion
`GMIME_IS_FILTER (filter)' failed
> From: Harry Wei
> When i compile kernel, it shows me two warnings
> like below, so this patch can fix them.
This fix is already
On Fri, 3 Jun 2011 02:28:47 -0700, Joe Perches wrote:
> drivers/gpu/drm/i915/i915_gem_tiling.c|4 ++--
Acked-by: Keith Packard
Dave -- if you want to just merge this to your tree, that's fine with
me.
--
keith.packard at intel.com
-- next part --
A
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
On Mon, 30 May 2011 12:48:26 +0200, Nicolas Kaiser wrote:
> if (mode->clock < 2)
> - return MODE_CLOCK_HIGH;
> + return MODE_CLOCK_LOW;
Seems obvious to me.
Reviewed-by: Keith Packard
--
keith.packard at intel.com
-
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
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 Wed, 25 May 2011 12:56:56 +0300, Dan Carpenter wrote:
> The extra semicolon was not intended.
>
> Signed-off-by: Dan Carpenter
Merged to drm-intel-next.
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type:
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 Sun, 22 May 2011 10:28:09 -0500, Matt Mackall 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: sounds like your
On Sat, 21 May 2011 23:55:57 -0500, Matt Mackall 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 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:
On Wed, 18 May 2011 20:15:05 +0200, Eric Leblond 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...
--
keith.packard
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 Tue, 17 May 2011 15:00:01 -0700, Keith Packard 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...
The following c
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
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
drm/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 |
/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
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
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files changed, 20
Signed-off-by: Keith Packard
---
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
+++ b/drivers/gpu
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
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
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
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
On Tue, 3 May 2011 14:08:58 -0700, Jesse Barnes
wrote:
> Fixed version below.
Reviewed-by: Keith Packard
(assuming that the GLX protocol specification gets updated to match :-)
--
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
N
On Tue, 3 May 2011 12:21:24 -0700, Jesse Barnes
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 needs to be
fixed to
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
On Thu, 28 Apr 2011 13:27:19 -0700, Jesse Barnes
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
> proto version bump.
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 Mon, 25 Apr 2011 16:52:58 -0700, Jesse Barnes
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', predefine some obvious
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes
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
> probably not
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
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 CRTC? To my mind,
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',
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
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, 11 Apr 2011 18:31:21 +0100, Chris Wilson
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.packard at intel.com
-- next part --
A non-text attachment was
On Mon, 11 Apr 2011 15:23:17 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> 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 drm_fb_helper_restore path as restoring
the
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
On Mon, 4 Apr 2011 18:09:55 -0700, Linus Torvalds 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 is obviously wrong, we're
On Tue, 5 Apr 2011 01:38:31 +0100 (IST), Dave Airlie
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 this sequence.
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 Fri, 11 Mar 2011 02:23:08 +0100 (CET), "Indan Zupancic"
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 'clean
;
The reason 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
Reviewed-by: Jesse Barnes
--
keith.packard at intel.com
--
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 Thu, 3 Feb 2011 17:11:14 -0800, Linus Torvalds 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 anything on or off in the
On Thu, 3 Feb 2011 16:30:56 -0800, Linus Torvalds wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie wrote:
> >
> > If we are setting a mode on a connector it automatically will end up
> > in a DPMS on state,
> > so this seemed correct from what I can see.
>
> The more I look at that
In drm_crtc_helper_set_config, instead of always forcing all outputs
to DRM_MODE_DPMS_ON, only set them if the CRTC is actually getting a
mode set, as any mode set will turn all outputs on.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_crtc_helper.c | 12 ++--
1 files changed
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
On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski 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 done?
--
On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski 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 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
On Wed, 08 Dec 2010 17:08:04 +, Chris Wilson
wrote:
> On Wed, 8 Dec 2010 17:34:24 +0100, Florian Mickler
> wrote:
> > Does that mean that the kernel regression will not be
> > fixed/worked-around for old userspace?
>
> I think there is some confusion in that I believe there is more than
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 Sun, 5 Dec 2010 13:27:43 +0100, Florian Mickler
wrote:
> On Fri, 26 Nov 2010 10:45:59 -0800
> Keith Packard wrote:
>
> > In order to correctly report monitor connected status changes, the
> > previous monitor status must be recorded in the connector->status
&g
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
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
---
drivers/gpu/drm/drm_crtc_helper.c |7 ---
1 files changed, 4 insertions(+), 3 deleti
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
---
drivers/gpu/drm/drm_crtc_helper.c |7
On Fri, 26 Nov 2010 11:45:38 +0300, Dan Carpenter 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
git://people.freedesktop.org/~keithp/linux-2.6
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 Thu, 25 Nov 2010 11:10:58 -0500, Nick Bowler
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 doesn't
> >
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
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files changed, 3
901 - 1000 of 1027 matches
Mail list logo
