[PATCH] drm: Always show the probed connector status
Otherwise if the connector is left in an unknown status, we leave the
function without any trace leaving me quite confused as to where the
output went.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_crtc_helper.c | 28
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 8de333a..b5458fd 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -37,6 +37,20 @@
static bool drm_kms_helper_poll = true;
module_param_named(poll, drm_kms_helper_poll, bool, 0600);
+static const char *drm_status_to_string(int status)
+{
+ switch (status) {
+ case connector_status_disconnected:
+ return "disconnected";
+ case connector_status_connected:
+ return "connected";
+ case connector_status_unknown:
+ return "unknown";
+ default:
+ return "invalid";
+ }
+}
+
static void drm_mode_validate_flag(struct drm_connector *connector,
int flags)
{
@@ -107,9 +121,12 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
drm_kms_helper_poll_enable(dev);
}
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s], status=%s\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ drm_status_to_string(connector->status));
+
if (connector->status == connector_status_disconnected) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
- connector->base.id, drm_get_connector_name(connector));
drm_mode_connector_update_edid_property(connector, NULL);
goto prune;
}
@@ -885,10 +902,13 @@ static void output_poll_execute(struct work_struct *work)
continue;
connector->status = connector->funcs->detect(connector, false);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to
%d\n",
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s [%d] to
%s [%d]\n",
connector->base.id,
drm_get_connector_name(connector),
- old_status, connector->status);
+ drm_status_to_string(old_status),
+ old_status,
+ drm_status_to_string(connector->status),
+ connector->status);
if (old_status != connector->status)
changed = true;
}
--
1.7.2.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, that worked for me. I improved on the patch a bit below.
>
> Thanks,
> Jeff
>
>
> --- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0
> +0800
> +++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0
> +0800
> @@ -262,7 +262,10 @@
> if (general) {
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> - dev_priv->lvds_use_ssc = general->enable_ssc;
> +
> + /* force disable until we can parse this correctly */
> + dev_priv->lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
> + 0 : general->enable_ssc;
For some expressions, the ternary operator is more compact & readable.
For others (like this one imo) it doesn't really add anything, so I
prefer the if statement. In this case I think the if statement is more
readable since it communicates that we're overriding the default value
on certain generations (i.e. it's a standalone clause).
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 11:40:04 -0800, Linus Torvalds
wrote:
> On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap
> wrote:
> >
> > The only significant difference that I can see in the kernel message log
> > is this:
>
> Hmm. I suspect that difference should have gone away with commit
> 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
> never enabled"), but clearly that didn't fix your blank screen.
>
> Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
> ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
> you? It does for some people..
>
> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> we please just disable spread-spectrum entirely? Or perhaps only if we
> notice that it was enabled already? Or something?
It appeared to be the easiest fix for the machines I had to hand and was
confirmed by several people with identical machines. However, it
definitely caused a regression for working panels and therefore it will
be reverted.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT), Jeff Chua
wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, that worked for me. I improved on the patch a bit below.
>
> Thanks,
> Jeff
>
>
> --- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0
> +0800
> +++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0
> +0800
> @@ -262,7 +262,10 @@
> if (general) {
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> - dev_priv->lvds_use_ssc = general->enable_ssc;
> +
> + /* force disable until we can parse this correctly */
> + dev_priv->lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
> + 0 : general->enable_ssc;
This reveals another bug whereby we don't clear conflicting bits in
PCH_DREF_CONTROL set by the BIOS...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Linux 2.6.37-rc8 (no fb)
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes wrote: >> > Doesn't change anything here. Display stays blank. >> >> Sounds like your problem is separate from SSC then, more likely related >> to panel power or backlight control. ?Have you tried bisecting for the >> problem between 2.6.35 and 2.6.36? > > Nevermind, I just checked out the bug, looks like it is panel power > related. ?Can you try this patch? Tried. Does not work. > If it doesn't work, can you send me the output of intel_reg_dumper from > before you turn off the display and after you try to turn it back on? See the links below (sorry, they files are a bit large): Before running "xset dpms force standby": http://vin-soft.org/~raa/public/test/intel_gpu_dump-before After running "sleep 3" http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-suspend After running "xset dpms force on" http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-xset-on After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes wrote: >> After closing and opening the lid (displays backlight is back) >> >> ? http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid > > I need the intel_reg_dumper output, not intel_gpu_dump. :) > Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is the latest on http://xorg.freedesktop.org/archive/individual/app/, so I assumed you just mistyped the name. Is it in git only? ... Yeah, look like it is in git only, which I have problems to compile (I have a bit of obsoleted system).
2.6.37-rc8: Reported regressions 2.6.35 -> 2.6.36
[NOTE: This most likely is the last summary report of regressions introduced
between 2.6.35 and 2.6.36.]
This message contains a list of some post-2.6.35 regressions introduced before
2.6.36, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.35 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
2010-12-30 99 22 20
2010-12-19 98 28 23
2010-12-05 95 34 31
2010-11-19 92 38 34
2010-10-17 70 27 27
2010-10-10 56 16 15
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
--
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24752
Subject : Random crashes easily reproducible with make -j5 - intel i915
- kernel 2.6.36 on intel/nvidia hybrid graphics machine
Submitter : Giacomo
Date: 2010-12-10 8:57 (20 days old)
Message-ID :
References : http://marc.info/?l=linux-kernel&m=129197146619176&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24722
Subject : Disconnecting my USB mouse hangs the machine and issues
kernel warning
Submitter : Heinz Diehl
Date: 2010-12-12 12:42 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24392
Subject : AGP aperture disabled, worked in 2.6.35
Submitter : Stephen Kitt
Date: 2010-12-06 06:31 (24 days old)
First-Bad-Commit:
http://git.kernel.org/linus/http://git.kernel.org/linus/96576a9e1a0cdb8a43d3af5846be0948f52b4460
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24202
Subject : [830] drm:intel_prepare_page_flip, *ERROR* Prepared flip
multiple times
Submitter : mkkot
Date: 2010-12-02 14:10 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23812
Subject : HAL does not provide battery information on RHEL5 and CentOS-5
Submitter : Dag Wieers
Date: 2010-11-26 18:08 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22842
Subject : iwl3945 suddenly stops working
Submitter : Felipe Contreras
Date: 2010-11-14 11:14 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22782
Subject : 2.6.36: general protection fault during lockfs lockspace
removal
Submitter : nik at linuxbox.cz
Date: 2010-11-12 12:05 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22172
Subject : alsa-util.c: snd_pcm_avail_delay() returned strange values:
delay 0 is less than avail 32
Submitter : Tobias
Date: 2010-11-06 09:33 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22092
Subject : Kernel v2.6.36 trouble on USB disconnect
Submitter : Ketil Froyn
Date: 2010-10-29 8:05 (62 days old)
Message-ID : <>
References : http://marc.info/?l=linux-kernel&m=128833956503607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21652
Subject : several problems with intel graphics since 2.6.36
Submitter : Norbert Preining
Date: 2010-10-27 14:32 (64 days old)
Message-ID : <20101027143252.GA8676 at gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=128818998630241&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21402
Subject : [KVM] Noacpi Windows guest can not boot up on 32bit KVM host
Submitter : xudong
Date: 2010-10-29 03:01 (62 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20332
Subject : [LogFS] [2.6.36-rc7] Kernel BUG at lib/btree.c:465!
Submitter : Prasad Joshi
Date: 2010-10-12 18:56 (79 days old)
Message-ID :
References : http://marc.info/?l=linux-kernel&m=128690910501830&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20322
Subject : 2.6.36-rc7: inconsistent lock state: inconsistent
{IN-RECLAIM_FS-R} -> {RECLAIM_FS-ON-W} usage.
Submitter : Dave Jones
Date: 2010-10-11 20:10 (80 days old)
Message-ID : <20101011201007.GA29707 at redhat.com>
References : http://marc.info/?l=linux-kernel&m=128682782828453&w
Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote: > On Thu, Dec 30, 2010 at 00:13, Jesse Barnes > wrote: >>> After closing and opening the lid (displays backlight is back) >>> >>> ? http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid >> >> I need the intel_reg_dumper output, not intel_gpu_dump. :) >> > > Hmm, there is no intel_reg_dumper in intel-gpu-tools-1.0.2, which is > the latest on http://xorg.freedesktop.org/archive/individual/app/, > so I assumed you just mistyped the name. Is it in git only? ... > Yeah, look like it is in git only, which I have problems to compile > (I have a bit of obsoleted system). > Is there any other way to get at the dump? Because it looks like it is plainly impossible to build the tools. A lot of dependencies, all really hard to get at on Ubuntu Jaunty.
Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes wrote: > That's the easiest way; I think there are existing packages available > as well, but you may have to check Karmic or newer. Never mind. I'm lazy (that's not to say someone is too). I redid the test: Before running "xset dpms force standby": http://vin-soft.org/~raa/public/test/intel_reg_dumper-before After running "sleep 3" http://vin-soft.org/~raa/public/test/intel_reg_dumper-suspend After running "xset dpms force on; sleep 3" http://vin-soft.org/~raa/public/test/intel_reg_dumper-xset-on After closing and opening the lid (displays backlight is back) http://vin-soft.org/~raa/public/test/intel_reg_dumper-lid
Linux 2.6.37-rc8 (no fb)
On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
wrote:
> Randy, Jeff and Alex, does the below help at all? If so, it may be the
> minimal fix we want for 2.6.37.
Jesse,
Yes, that worked for me. I improved on the patch a bit below.
Thanks,
Jeff
--- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0 +0800
+++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0 +0800
@@ -262,7 +262,10 @@
if (general) {
dev_priv->int_tv_support = general->int_tv_support;
dev_priv->int_crt_support = general->int_crt_support;
- dev_priv->lvds_use_ssc = general->enable_ssc;
+
+ /* force disable until we can parse this correctly */
+ dev_priv->lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
+ 0 : general->enable_ssc;
if (dev_priv->lvds_use_ssc) {
if (IS_I85X(dev))
[PATCH] drm: Always show the probed connector status
Otherwise if the connector is left in an unknown status, we leave the
function without any trace leaving me quite confused as to where the
output went.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_crtc_helper.c | 28
1 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 8de333a..b5458fd 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -37,6 +37,20 @@
static bool drm_kms_helper_poll = true;
module_param_named(poll, drm_kms_helper_poll, bool, 0600);
+static const char *drm_status_to_string(int status)
+{
+ switch (status) {
+ case connector_status_disconnected:
+ return "disconnected";
+ case connector_status_connected:
+ return "connected";
+ case connector_status_unknown:
+ return "unknown";
+ default:
+ return "invalid";
+ }
+}
+
static void drm_mode_validate_flag(struct drm_connector *connector,
int flags)
{
@@ -107,9 +121,12 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
drm_kms_helper_poll_enable(dev);
}
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s], status=%s\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ drm_status_to_string(connector->status));
+
if (connector->status == connector_status_disconnected) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
- connector->base.id, drm_get_connector_name(connector));
drm_mode_connector_update_edid_property(connector, NULL);
goto prune;
}
@@ -885,10 +902,13 @@ static void output_poll_execute(struct work_struct *work)
continue;
connector->status = connector->funcs->detect(connector, false);
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to
%d\n",
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s [%d] to
%s [%d]\n",
connector->base.id,
drm_get_connector_name(connector),
- old_status, connector->status);
+ drm_status_to_string(old_status),
+ old_status,
+ drm_status_to_string(connector->status),
+ connector->status);
if (old_status != connector->status)
changed = true;
}
--
1.7.2.3
Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT)
Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, that worked for me. I improved on the patch a bit below.
>
> Thanks,
> Jeff
>
>
> --- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0
> +0800
> +++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0
> +0800
> @@ -262,7 +262,10 @@
> if (general) {
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> - dev_priv->lvds_use_ssc = general->enable_ssc;
> +
> + /* force disable until we can parse this correctly */
> + dev_priv->lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
> + 0 : general->enable_ssc;
For some expressions, the ternary operator is more compact & readable.
For others (like this one imo) it doesn't really add anything, so I
prefer the if statement. In this case I think the if statement is more
readable since it communicates that we're overriding the default value
on certain generations (i.e. it's a standalone clause).
--
Jesse Barnes, Intel Open Source Technology Center
Linux 2.6.37-rc8 (no fb)
On Wed, 29 Dec 2010 11:40:04 -0800, Linus Torvalds wrote:
> On Wed, Dec 29, 2010 at 10:21 AM, Randy Dunlap
> wrote:
> >
> > The only significant difference that I can see in the kernel message log
> > is this:
>
> Hmm. I suspect that difference should have gone away with commit
> 92971021c6328 (Revert "drm: Don't try and disable an encoder that was
> never enabled"), but clearly that didn't fix your blank screen.
>
> Does reverting commit 448f53a1ede54eb854d036abf54573281412d650
> ("drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks") fix it for
> you? It does for some people..
>
> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
> we please just disable spread-spectrum entirely? Or perhaps only if we
> notice that it was enabled already? Or something?
It appeared to be the easiest fix for the machines I had to hand and was
confirmed by several people with identical machines. However, it
definitely caused a regression for working panels and therefore it will
be reverted.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Linux 2.6.37-rc8 (no fb)
On Thu, 30 Dec 2010 10:49:33 +0800 (SGT), Jeff Chua wrote:
>
> On Thu, Dec 30, 2010 at 4:16 AM, Jesse Barnes
> wrote:
>
> > Randy, Jeff and Alex, does the below help at all? If so, it may be the
> > minimal fix we want for 2.6.37.
>
> Jesse,
>
> Yes, that worked for me. I improved on the patch a bit below.
>
> Thanks,
> Jeff
>
>
> --- a/drivers/gpu/drm/i915/intel_bios.c 2010-12-29 13:35:57.0
> +0800
> +++ a/drivers/gpu/drm/i915/intel_bios.c 2010-12-30 10:18:39.0
> +0800
> @@ -262,7 +262,10 @@
> if (general) {
> dev_priv->int_tv_support = general->int_tv_support;
> dev_priv->int_crt_support = general->int_crt_support;
> - dev_priv->lvds_use_ssc = general->enable_ssc;
> +
> + /* force disable until we can parse this correctly */
> + dev_priv->lvds_use_ssc = (IS_GEN5(dev) || IS_GEN6(dev)) ?
> + 0 : general->enable_ssc;
This reveals another bug whereby we don't clear conflicting bits in
PCH_DREF_CONTROL set by the BIOS...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
