linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
@ 2010-09-20 12:59 Andy Walls
  2010-09-20 18:29 ` Rafał Miłecki
  2010-09-20 18:52 ` [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Greg KH
  0 siblings, 2 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-20 12:59 UTC (permalink / raw)
  To: linux-kernel; +Cc: dri-devel, Dave Airlie, Jon Smirl, Greg Kroah-Hartman

DRM KMS polling of connections providing errant EDID responses, or
polling of "connectors" that have chips responding on DDC I2C bus
address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
will create perpetual noise in dmesg and the system log every 10
seconds.  Currently the user has apparently little recourse to silence
these messages aside from replacing the offending cable, monitor, or
graphics adapter.  That recourse is impossible for an unused DVI-D
"connector" of an internal graphics processor on a motherboard that
provides no physical DVI-D connector.

This change allows the root user to disable (and re-enable) DRM KMS
connector polling on a per connector basis via sysfs, like so:

        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        [hotplug_detectable] connect disconnect
        
        # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        hotplug_detectable connect disconnect
        
        # echo " connect  hotplug_detectable " > \
        	/sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        [hotplug_detectable] [connect] disconnect
        
        # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        hotplug_detectable connect disconnect

with the enabled poll types for the connector denoted in brackets: [].
This allows the root user to silence DRM KMS log spam for locally known
uncorrectable conditions.

Signed-off-by Andy Walls <awalls@md.metrocast.net>

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 86118a7..8e0807d 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -318,11 +318,80 @@ static ssize_t select_subconnector_show(struct device *device,
 			drm_get_dvi_i_select_name((int)subconnector));
 }
 
+static const struct {
+	uint8_t mask;
+	const char *name;
+} polled_bit_names[] = {
+	{ DRM_CONNECTOR_POLL_HPD,        "hotplug_detectable" },
+	{ DRM_CONNECTOR_POLL_CONNECT,    "connect"            },
+	{ DRM_CONNECTOR_POLL_DISCONNECT, "disconnect"         },
+};
+
+/*
+ * Return the decoded contents of connector->polled, using the names of the
+ * all the bit masks.  Bits that are set, have their names enclosed in brackets.
+ */
+static ssize_t polled_show(struct device *dev, struct device_attribute *attr,
+			   char *buf)
+{
+	struct drm_connector *connector = to_drm_connector(dev);
+	char *tmp;
+	int i;
+
+	tmp = buf;
+	for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+		if (connector->polled & polled_bit_names[i].mask)
+			tmp += sprintf(tmp, "[%s] ", polled_bit_names[i].name);
+		else
+			tmp += sprintf(tmp, "%s ", polled_bit_names[i].name);
+	}
+
+	if (tmp != buf)
+		*(tmp - 1) = '\n';
+	return tmp - buf;
+}
+
+/*
+ * Change the state of connector->polled, given input bit-mask name-strings
+ * that are separated by space or newline.
+ */
+static ssize_t polled_store(struct device *dev, struct device_attribute *attr,
+			    const char *buf, size_t count)
+{
+	struct drm_connector *connector = to_drm_connector(dev);
+	const char *tmp;
+	int i;
+	uint8_t polled;
+
+	/* Polling of this connector will cease, if no match is made below */
+	polled = 0;
+
+	/* Incrementally split and parse the input */
+	while ((tmp = strsep((char **) &buf, " \n")) != NULL) {
+
+		/* Don't waste effort on multiple adjacent separators */
+		if (*tmp == '\0')
+			continue;
+
+		/* Check for a match with a connector poll type name */
+		for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+			if (!strncasecmp(tmp, polled_bit_names[i].name,
+					 strlen(polled_bit_names[i].name))) {
+				polled |= polled_bit_names[i].mask;
+				break;
+			}
+		}
+	}
+	connector->polled = polled;
+	return count;
+}
+
 static struct device_attribute connector_attrs[] = {
 	__ATTR_RO(status),
 	__ATTR_RO(enabled),
 	__ATTR_RO(dpms),
 	__ATTR_RO(modes),
+	__ATTR(polled, 0644, polled_show, polled_store),
 };
 
 /* These attributes are for both DVI-I connectors and all types of tv-out. */



^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 12:59 [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Andy Walls
@ 2010-09-20 18:29 ` Rafał Miłecki
  2010-09-20 23:02   ` Andy Walls
  2010-09-20 18:52 ` [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Greg KH
  1 sibling, 1 reply; 24+ messages in thread
From: Rafał Miłecki @ 2010-09-20 18:29 UTC (permalink / raw)
  To: Andy Walls
  Cc: linux-kernel, Dave Airlie, Jon Smirl, dri-devel,
	Greg Kroah-Hartman

2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> DRM KMS polling of connections providing errant EDID responses, or
> polling of "connectors" that have chips responding on DDC I2C bus
> address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
> will create perpetual noise in dmesg and the system log every 10
> seconds.  Currently the user has apparently little recourse to silence
> these messages aside from replacing the offending cable, monitor, or
> graphics adapter.  That recourse is impossible for an unused DVI-D
> "connector" of an internal graphics processor on a motherboard that
> provides no physical DVI-D connector.
>
> This change allows the root user to disable (and re-enable) DRM KMS
> connector polling on a per connector basis via sysfs, like so:

Huh, I didn't imagine solution of this issue that way. AFAIR previous
thread, something else was suggested, it was about storing the fact
that user already received warning/info about error.

Why I don't really like proposed solution?
1) You need to be root
2) Need to know and play with some "magic" sysfs file.

I thing it would be much better and user-friendly to display such an
error just once per display. How this could be implemented?

1) Add field like "warned" to connector struct, default to 0
2) if (warning_to_be_printed && !connector->warned) { printk();
connector->warned = 1
3) if (connector_disconnected) { connector->warned = 0; }

This was you will get just one warning per connected display. Of
course after disconnecting it we have to clear "warned", as user may
connect another "broken" display, then we should print warning again.

What do think about this solution?

-- 
Rafał

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 12:59 [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Andy Walls
  2010-09-20 18:29 ` Rafał Miłecki
@ 2010-09-20 18:52 ` Greg KH
  2010-09-20 21:11   ` Andy Walls
  1 sibling, 1 reply; 24+ messages in thread
From: Greg KH @ 2010-09-20 18:52 UTC (permalink / raw)
  To: Andy Walls; +Cc: linux-kernel, dri-devel, Dave Airlie, Jon Smirl

On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
> DRM KMS polling of connections providing errant EDID responses, or
> polling of "connectors" that have chips responding on DDC I2C bus
> address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
> will create perpetual noise in dmesg and the system log every 10
> seconds.  Currently the user has apparently little recourse to silence
> these messages aside from replacing the offending cable, monitor, or
> graphics adapter.  That recourse is impossible for an unused DVI-D
> "connector" of an internal graphics processor on a motherboard that
> provides no physical DVI-D connector.
> 
> This change allows the root user to disable (and re-enable) DRM KMS
> connector polling on a per connector basis via sysfs, like so:
> 
>         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
>         [hotplug_detectable] connect disconnect
>         
>         # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
>         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
>         hotplug_detectable connect disconnect
>         
>         # echo " connect  hotplug_detectable " > \
>         	/sys/class/drm/card0/card0-DVI-D-1/polled
>         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
>         [hotplug_detectable] [connect] disconnect
>         
>         # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
>         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
>         hotplug_detectable connect disconnect
> 
> with the enabled poll types for the connector denoted in brackets: [].
> This allows the root user to silence DRM KMS log spam for locally known
> uncorrectable conditions.
> 
> Signed-off-by Andy Walls <awalls@md.metrocast.net>

You are adding a sysfs file, yet you forgot to add a file in
Documentation/ABI.  Please fix that and resend the patch.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 18:52 ` [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Greg KH
@ 2010-09-20 21:11   ` Andy Walls
  2010-09-22  9:44     ` Florian Mickler
  0 siblings, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-20 21:11 UTC (permalink / raw)
  To: Greg KH; +Cc: linux-kernel, dri-devel, Dave Airlie, Jon Smirl

On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
> On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
 
> > This change allows the root user to disable (and re-enable) DRM KMS
> > connector polling on a per connector basis via sysfs, like so:
> > 
> >         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
> >         [hotplug_detectable] connect disconnect

> You are adding a sysfs file, yet you forgot to add a file in
> Documentation/ABI.  Please fix that and resend the patch.

Oops, process failure, sorry.
Will do.

Regards,
Andy


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 18:29 ` Rafał Miłecki
@ 2010-09-20 23:02   ` Andy Walls
  2010-09-21  4:26     ` Alex Deucher
                       ` (3 more replies)
  0 siblings, 4 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-20 23:02 UTC (permalink / raw)
  To: Rafał Miłecki
  Cc: linux-kernel, Dave Airlie, Jon Smirl, dri-devel,
	Greg Kroah-Hartman

On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> > DRM KMS polling of connections providing errant EDID responses, or
> > polling of "connectors" that have chips responding on DDC I2C bus
> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
> > will create perpetual noise in dmesg and the system log every 10
> > seconds.  Currently the user has apparently little recourse to silence
> > these messages aside from replacing the offending cable, monitor, or
> > graphics adapter.  That recourse is impossible for an unused DVI-D
> > "connector" of an internal graphics processor on a motherboard that
> > provides no physical DVI-D connector.
> >
> > This change allows the root user to disable (and re-enable) DRM KMS
> > connector polling on a per connector basis via sysfs, like so:
> 
> Huh, I didn't imagine solution of this issue that way.

The problems with my initial patch, and related approaches, were:

1. They didn't get rid of all the spam in the logs, just the most
verbose portion of it.

2. They didn't deal with the root cause of the log spam and all the
related, but unneeded, I/O and processing that was still occurring.



>  AFAIR previous
> thread, something else was suggested, it was about storing the fact
> that user already received warning/info about error.

Yes, that was the discussion.

I went with this patch because:

1. It deals with the root cause: unneeded DRM KMS connector polling

2. It eliminates all my DRM KMS connector polling related log spam, not
just the hex dump.

3. The existing sysfs structure was already exposing 'struct
drm_connector' members to user-space at per connector granularity


The real root cause of the polling spew is that the radeon module, based
on the best information it has (BIOS connector tables, I2C bus probes,
etc.), makes a decision on if a connector should be polled and how it
should be polled.

Given incorrect BIOS tables, and strange I2C setups, the radeon module
is bound to make the wrong decision about polling in some cases.  This
change is a way for the human to step in a correct things, when the
radeon driver gets it wrong.

In my case, along with the log spam, there are also a lot of unneeded
I2C transactions going on.


BTW, I found that Chris Wilson recently committed a change to inhibit
all drm connector polling globally for a different reason:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

That commit message shows a case where the driver decides polling needs
to happen, but the human knows differently and manual control over
connector polling mitigates the problem.





> Why I don't really like proposed solution?
> 1) You need to be root

Yes, for both sysfs and module parameters.

I view video hardware configuration (montiors, cables, graphics cards)
and control of what gets logged into files as system administrative
issues.  I'd assume that needing root privileges to turn on and off
device auto detection would be the norm.  I imagined that root would set
up any DRM KMS connector polling fixes once in an init script and be
done with it.  Is there any other use-case you had in mind?

If there's some set-uid or group privilege method or utilities that's in
common use (xrandr?) for manual control of drm/kms parameters, that you
think would be better, just point me in that direction and I'll try to
work something out.

However, trying to code automatic control of when to disable DRM KMS
connector polling, by some heuristic or algorithm in radeon or drm, is
likely doomed to failure for corner cases or for someone's policy
preferences.  I'd rather not attempt that.


> 2) Need to know and play with some "magic" sysfs file.

I strongly dislike ever using sysfs myself.  However, I'll spare us all
my rantings^Wreasons. ;)

My problem with KMS was with the documentation I could find.  The
"userland interfaces" section in Documentation/Docbook/drm.tmpl is
essentially empty.  DRM design documents at freedesktop.org (which
actually look closer to requirements documents) are the most detailed
documents I could find, but they don't really cover KMS.  Maybe I'm just
looking in the wrong places.

Is there a KMS or DRM_MODESET API document?  Maybe I could propose a new
ioctl(), if there isn't already one that will be usable for controlling
DRM KMS polling.



> I thing it would be much better and user-friendly to display such an
> error just once per display. How this could be implemented?
> 
> 1) Add field like "warned" to connector struct, default to 0
> 2) if (warning_to_be_printed && !connector->warned) { printk();
> connector->warned = 1
> 3) if (connector_disconnected) { connector->warned = 0; }
> 
> This was you will get just one warning per connected display. Of
> course after disconnecting it we have to clear "warned", as user may
> connect another "broken" display, then we should print warning again.
> 
> What do think about this solution?

I followed most of the function calls back and looked at he return
values and error messages that can get emitted under various
circumstances.  The amount of effort and complexity for trying to
supress all the error messages due to the 10 second poll just wasn't
worth it, when supressing the polling was so much easier.  For
supressing error messages, I decided there was too much state to track
and that any policy I hard-coded would be wrong for someone.

>From inside the code, it is difficult to decide what message about
errors induced from the external environment are important to the user
and what aren't.  It's too dependent on the external context and what
action the user would like to take under various conditions.


Thanks for your comments.  Sorry for the long reply.

Regards,
Andy


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 23:02   ` Andy Walls
@ 2010-09-21  4:26     ` Alex Deucher
  2010-09-21 17:30       ` Andy Walls
  2010-09-22  3:20     ` [PATCH v2 0/2] " Andy Walls
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 24+ messages in thread
From: Alex Deucher @ 2010-09-21  4:26 UTC (permalink / raw)
  To: Andy Walls
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	linux-kernel, dri-devel, Jon Smirl

2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> > DRM KMS polling of connections providing errant EDID responses, or
>> > polling of "connectors" that have chips responding on DDC I2C bus
>> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
>> > will create perpetual noise in dmesg and the system log every 10
>> > seconds.  Currently the user has apparently little recourse to silence
>> > these messages aside from replacing the offending cable, monitor, or
>> > graphics adapter.  That recourse is impossible for an unused DVI-D
>> > "connector" of an internal graphics processor on a motherboard that
>> > provides no physical DVI-D connector.
>> >
>> > This change allows the root user to disable (and re-enable) DRM KMS
>> > connector polling on a per connector basis via sysfs, like so:
>>
>> Huh, I didn't imagine solution of this issue that way.
>
> The problems with my initial patch, and related approaches, were:
>
> 1. They didn't get rid of all the spam in the logs, just the most
> verbose portion of it.
>
> 2. They didn't deal with the root cause of the log spam and all the
> related, but unneeded, I/O and processing that was still occurring.
>
>
>
>>  AFAIR previous
>> thread, something else was suggested, it was about storing the fact
>> that user already received warning/info about error.
>
> Yes, that was the discussion.
>
> I went with this patch because:
>
> 1. It deals with the root cause: unneeded DRM KMS connector polling
>
> 2. It eliminates all my DRM KMS connector polling related log spam, not
> just the hex dump.
>
> 3. The existing sysfs structure was already exposing 'struct
> drm_connector' members to user-space at per connector granularity
>
>
> The real root cause of the polling spew is that the radeon module, based
> on the best information it has (BIOS connector tables, I2C bus probes,
> etc.), makes a decision on if a connector should be polled and how it
> should be polled.
>
> Given incorrect BIOS tables, and strange I2C setups, the radeon module
> is bound to make the wrong decision about polling in some cases.  This
> change is a way for the human to step in a correct things, when the
> radeon driver gets it wrong.
>

I'd rather fix the bug for real rather than providing users with an
out so that the bug never gets reported.  What's the actual problem
you have?  Do you just want to turn polling off for an unused
connecter, or does the board have a bug in the connector table?  If
it's a bug, we can add a quirk so that it's properly handled.  What
physical connectors does the board have what does the driver report in
dmesg?

Alex

> In my case, along with the log spam, there are also a lot of unneeded
> I2C transactions going on.
>
>
> BTW, I found that Chris Wilson recently committed a change to inhibit
> all drm connector polling globally for a different reason:
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
>
> That commit message shows a case where the driver decides polling needs
> to happen, but the human knows differently and manual control over
> connector polling mitigates the problem.
>
>
>
>
>
>> Why I don't really like proposed solution?
>> 1) You need to be root
>
> Yes, for both sysfs and module parameters.
>
> I view video hardware configuration (montiors, cables, graphics cards)
> and control of what gets logged into files as system administrative
> issues.  I'd assume that needing root privileges to turn on and off
> device auto detection would be the norm.  I imagined that root would set
> up any DRM KMS connector polling fixes once in an init script and be
> done with it.  Is there any other use-case you had in mind?
>
> If there's some set-uid or group privilege method or utilities that's in
> common use (xrandr?) for manual control of drm/kms parameters, that you
> think would be better, just point me in that direction and I'll try to
> work something out.
>
> However, trying to code automatic control of when to disable DRM KMS
> connector polling, by some heuristic or algorithm in radeon or drm, is
> likely doomed to failure for corner cases or for someone's policy
> preferences.  I'd rather not attempt that.
>
>
>> 2) Need to know and play with some "magic" sysfs file.
>
> I strongly dislike ever using sysfs myself.  However, I'll spare us all
> my rantings^Wreasons. ;)
>
> My problem with KMS was with the documentation I could find.  The
> "userland interfaces" section in Documentation/Docbook/drm.tmpl is
> essentially empty.  DRM design documents at freedesktop.org (which
> actually look closer to requirements documents) are the most detailed
> documents I could find, but they don't really cover KMS.  Maybe I'm just
> looking in the wrong places.
>
> Is there a KMS or DRM_MODESET API document?  Maybe I could propose a new
> ioctl(), if there isn't already one that will be usable for controlling
> DRM KMS polling.
>
>
>
>> I thing it would be much better and user-friendly to display such an
>> error just once per display. How this could be implemented?
>>
>> 1) Add field like "warned" to connector struct, default to 0
>> 2) if (warning_to_be_printed && !connector->warned) { printk();
>> connector->warned = 1
>> 3) if (connector_disconnected) { connector->warned = 0; }
>>
>> This was you will get just one warning per connected display. Of
>> course after disconnecting it we have to clear "warned", as user may
>> connect another "broken" display, then we should print warning again.
>>
>> What do think about this solution?
>
> I followed most of the function calls back and looked at he return
> values and error messages that can get emitted under various
> circumstances.  The amount of effort and complexity for trying to
> supress all the error messages due to the 10 second poll just wasn't
> worth it, when supressing the polling was so much easier.  For
> supressing error messages, I decided there was too much state to track
> and that any policy I hard-coded would be wrong for someone.
>
> >From inside the code, it is difficult to decide what message about
> errors induced from the external environment are important to the user
> and what aren't.  It's too dependent on the external context and what
> action the user would like to take under various conditions.
>
>
> Thanks for your comments.  Sorry for the long reply.
>
> Regards,
> Andy
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-21  4:26     ` Alex Deucher
@ 2010-09-21 17:30       ` Andy Walls
  2010-09-22  5:30         ` Alex Deucher
  0 siblings, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-21 17:30 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	linux-kernel, dri-devel, Jon Smirl

On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> >> > DRM KMS polling of connections providing errant EDID responses, or
> >> > polling of "connectors" that have chips responding on DDC I2C bus
> >> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
> >> > will create perpetual noise in dmesg and the system log every 10
> >> > seconds.  Currently the user has apparently little recourse to silence
> >> > these messages aside from replacing the offending cable, monitor, or
> >> > graphics adapter.  That recourse is impossible for an unused DVI-D
> >> > "connector" of an internal graphics processor on a motherboard that
> >> > provides no physical DVI-D connector.
> >> >
> >> > This change allows the root user to disable (and re-enable) DRM KMS
> >> > connector polling on a per connector basis via sysfs, like so:
> >>
> >> Huh, I didn't imagine solution of this issue that way.
> >
> > The problems with my initial patch, and related approaches, were:
> >
> > 1. They didn't get rid of all the spam in the logs, just the most
> > verbose portion of it.
> >
> > 2. They didn't deal with the root cause of the log spam and all the
> > related, but unneeded, I/O and processing that was still occurring.
> >
> >
> >
> >>  AFAIR previous
> >> thread, something else was suggested, it was about storing the fact
> >> that user already received warning/info about error.
> >
> > Yes, that was the discussion.
> >
> > I went with this patch because:
> >
> > 1. It deals with the root cause: unneeded DRM KMS connector polling
> >
> > 2. It eliminates all my DRM KMS connector polling related log spam, not
> > just the hex dump.
> >
> > 3. The existing sysfs structure was already exposing 'struct
> > drm_connector' members to user-space at per connector granularity
> >
> >
> > The real root cause of the polling spew is that the radeon module, based
> > on the best information it has (BIOS connector tables, I2C bus probes,
> > etc.), makes a decision on if a connector should be polled and how it
> > should be polled.
> >
> > Given incorrect BIOS tables, and strange I2C setups, the radeon module
> > is bound to make the wrong decision about polling in some cases.  This
> > change is a way for the human to step in a correct things, when the
> > radeon driver gets it wrong.
> >
> 
> I'd rather fix the bug for real rather than providing users with an
> out so that the bug never gets reported.

There is already "an out" on it's way upstream:

http://lkml.org/lkml/2010/9/6/375
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9

I noticed it after I submitted this patch.  If I'm reading it right, the
module parameter fix is very coarse: it applies to all drm adapters and
connectors in the system.

>   What's the actual problem
> you have?

The actual problem I have is that the radeon driver reports three
connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only
one physical connector (VGA).  Polling of the HDMI appears to be
inhibited by the radeon module code.  Polling of the (non-existent?)
DVI-D interface yields a lot of log messages and useless I2C
transactions.

My precise gripe is with this code path

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_connectors.c;h=ecc1a8fafbfd3eb3c12c0c4d45b4b091a1bee03b;hb=refs/heads/drm-fixes#l772

which is being polled every 10 seconds.  It is bad for me because this
function is noisy:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l136

and this (insane?) loop multiplies the noise by a factor of 4:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l264


In a different user's operational context, all that noise may be
beneficial.


The real problem to me is that the radeon and drm modules have a single,
standard way of dealing with EDID errors.  However, EDID errors can
happen due to a number of different causes, some of which are external
(i.e. in the LCD or CRT monitor).  Given that, there really is no "right
thing" the drivers can do without input from the user on what the policy
should be when a bad EDID is detected.




>   Do you just want to turn polling off for an unused
> connecter,

Yes, that's what I would use my proposed patch for.

(If a solution that avoids sysfs is required, I can work up a patch
using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with
a patch for some utility like xrandr.)


In a larger sense it's about user policy for error reporting by the drm
and radeon drivers, and error response by both the drivers and the user.

In the face of EDID errors, a user may want to take the following
actions:

	ignore the errors
	supress the errors
	continue to monitor the errors for a time
	replace cables
	replace graphics adapter
	replace monitor
	report a bug

All of those end user actions are possible right now, except the one to
supress the errors (and the I2C transactions associated with them).

A monitor, cable, and graphics adapter set that is currently
experiencing EDID errors, may be otherwise working just fine. 

"Because we want to ensure people report bugs," does not seem like a
good reason to prevent a user from turning off bogus error messages, for
an otherwise working monitor that is providing broken EDID data.  What
is the resolution of a bug report for a monitor providing bad EDID data
going to look like?


>  or does the board have a bug in the connector table?

I have not dug into the BIOS connector table bits and bytes to verify,
but I'm assuming the connector table is incorrect.


>   If
> it's a bug, we can add a quirk so that it's properly handled.

I don't see how a quirk table is going to cover the situations different
from mine, that also provide bad EDID data in the code path I pointed
out.  I know how one can add quirks for a connected DVI-D monitor that
provides bad EDID data or none at all.

The radeon module already has a connector_table module parameter for
quirks.  That module option provides some hard-coded connector tables.
I had considered adding more to that, but it seemed like a band-aid.
Also, IIRC, the connector_table parameter currently applies globally to
all radeon graphics adapters in the system, so it doesn't scale to
multiple radeon adapters in the system.



>   What
> physical connectors does the board have what does the driver report in
> dmesg?

The board only has a physical VGA connector.  The graphics adapter is an
IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
PCI IDs on the graphics adapter:

01:05.0 VGA compatible controller [0300]:
	ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller])
	Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]


Below is the dmesg output from the unmodified drm and radeon modules
which includes samples of drm module log spam for the first 30 seconds
or so after boot.

Regards,
Andy

Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010
[snip!]
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0xFE7F0000
[drm] register mmio size: 65536
ATOM BIOS: ATI
[drm] GPU reset succeed (RBBM_STATUS=0x10000140)
[drm] radeon: VRAM 128M
[drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF
[drm] radeon: GTT 512M
[drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF
  alloc irq_desc for 28 on node 0
  alloc kstat_irqs on node 0
radeon 0000:01:05.0: irq 28 for MSI/MSI-X
[drm] radeon: using MSI.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 963036 kiB.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: 1 quad pipes, 1 z pipes initialized.
[drm] radeon: cp idle (0x10000C03)
[drm] Loading RS690/RS740 Microcode
platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin
[drm] radeon: ring at 0x0000000080000000
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA
[drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D
[drm]   HPD2
[drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
[drm]   Encoders:
[drm]     DFP2: INTERNAL_DDI
[drm] Connector 2:
[drm]   HDMI-A
[drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
[drm]   Encoders:
[drm]     DFP3: INTERNAL_LVTM1
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm] fb mappable at 0xD8040000
[drm] vram apper at 0xD8000000
[drm] size 4325376
[drm] fb depth is 24
[drm]    pitch is 5632
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 170x48
fb0: radeondrmfb frame buffer device
registered panic notifier
[drm] Initialized radeon 2.0.0 20080528 for 0000:01:05.0 on minor 0
dracut: Starting plymouth daemon
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[snip]
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[snip]
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID

[snip]

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
eth0: no IPv6 routers present
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[snip]
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 7f 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 3f 00 00 00 00 00 00 00 00 00 00 00 00  ...?............
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 7f 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f  ...............?

[drm:drm_edid_is_valid] *ERROR* Raw EDID:
<3>01 00 03 00 00 00 00 00 00 00 00 00 00 03 0f 00  ................
<3>00 00 00 00 00 01 00 00 0f 00 00 00 00 00 00 00  ................
<3>00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01  ................
<3>00 0f 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
<3>00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03  ................
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

radeon 0000:01:05.0: DVI-D-1: EDID invalid.
[drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID



^ permalink raw reply	[flat|nested] 24+ messages in thread

* [PATCH v2 0/2] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 23:02   ` Andy Walls
  2010-09-21  4:26     ` Alex Deucher
@ 2010-09-22  3:20     ` Andy Walls
  2010-09-22  3:20     ` [PATCH v2 1/2] " Andy Walls
  2010-09-22  3:20     ` [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry Andy Walls
  3 siblings, 0 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-22  3:20 UTC (permalink / raw)
  To: linux-kernel
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	dri-devel, Jon Smirl

Per Greg's request, here is a resend of my previous patch to add sysfs
entries to allow manual override of DRM KMS connector polling actions,
with accompanying documentation.

Only documentation has been added.
No code has changed from the previous patch submission.

diffstat:

Documentation/ABI/testing/sysfs-drm |  208 ++++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/drm_sysfs.c         |   69 +++++++++++
 2 files changed, 277 insertions(+)

Regards,
Andy 


^ permalink raw reply	[flat|nested] 24+ messages in thread

* [PATCH v2 1/2] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 23:02   ` Andy Walls
  2010-09-21  4:26     ` Alex Deucher
  2010-09-22  3:20     ` [PATCH v2 0/2] " Andy Walls
@ 2010-09-22  3:20     ` Andy Walls
  2010-09-22  3:20     ` [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry Andy Walls
  3 siblings, 0 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-22  3:20 UTC (permalink / raw)
  To: linux-kernel
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	dri-devel, Jon Smirl

DRM KMS polling of connections providing errant EDID responses, or
polling of "connectors" that have chips responding on DDC I2C bus
address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
will create perpetual noise in dmesg and the system log every 10
seconds.  Currently the user has apparently little recourse to silence
these messages aside from replacing the offending cable, monitor, or
graphics adapter.  That recourse is impossible for an unused DVI-D
"connector" of an internal graphics processor on a motherboard that
provides no physical DVI-D connector.

This change allows the root user to disable (and re-enable) DRM KMS
connector polling on a per connector basis via sysfs, like so:

        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        [hotplug_detectable] connect disconnect
        
        # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        hotplug_detectable connect disconnect
        
        # echo " connect  hotplug_detectable " > \
                /sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        [hotplug_detectable] [connect] disconnect
        
        # echo > /sys/class/drm/card0/card0-DVI-D-1/polled
        # cat /sys/class/drm/card0/card0-DVI-D-1/polled
        hotplug_detectable connect disconnect

with the enabled poll types for the connector denoted in brackets: [].
This allows the root user to silence DRM KMS log spam for locally known
uncorrectable conditions.

Signed-off-by Andy Walls <awalls@md.metrocast.net>

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 86118a7..8e0807d 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -318,11 +318,80 @@ static ssize_t select_subconnector_show(struct device *device,
                        drm_get_dvi_i_select_name((int)subconnector));
 }
 
+static const struct {
+       uint8_t mask;
+       const char *name;
+} polled_bit_names[] = {
+       { DRM_CONNECTOR_POLL_HPD,        "hotplug_detectable" },
+       { DRM_CONNECTOR_POLL_CONNECT,    "connect"            },
+       { DRM_CONNECTOR_POLL_DISCONNECT, "disconnect"         },
+};
+
+/*
+ * Return the decoded contents of connector->polled, using the names of the
+ * all the bit masks.  Bits that are set, have their names enclosed in brackets.
+ */
+static ssize_t polled_show(struct device *dev, struct device_attribute *attr,
+                          char *buf)
+{
+       struct drm_connector *connector = to_drm_connector(dev);
+       char *tmp;
+       int i;
+
+       tmp = buf;
+       for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+               if (connector->polled & polled_bit_names[i].mask)
+                       tmp += sprintf(tmp, "[%s] ", polled_bit_names[i].name);
+               else
+                       tmp += sprintf(tmp, "%s ", polled_bit_names[i].name);
+       }
+
+       if (tmp != buf)
+               *(tmp - 1) = '\n';
+       return tmp - buf;
+}
+
+/*
+ * Change the state of connector->polled, given input bit-mask name-strings
+ * that are separated by space or newline.
+ */
+static ssize_t polled_store(struct device *dev, struct device_attribute *attr,
+                           const char *buf, size_t count)
+{
+       struct drm_connector *connector = to_drm_connector(dev);
+       const char *tmp;
+       int i;
+       uint8_t polled;
+
+       /* Polling of this connector will cease, if no match is made below */
+       polled = 0;
+
+       /* Incrementally split and parse the input */
+       while ((tmp = strsep((char **) &buf, " \n")) != NULL) {
+
+               /* Don't waste effort on multiple adjacent separators */
+               if (*tmp == '\0')
+                       continue;
+
+               /* Check for a match with a connector poll type name */
+               for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) {
+                       if (!strncasecmp(tmp, polled_bit_names[i].name,
+                                        strlen(polled_bit_names[i].name))) {
+                               polled |= polled_bit_names[i].mask;
+                               break;
+                       }
+               }
+       }
+       connector->polled = polled;
+       return count;
+}
+
 static struct device_attribute connector_attrs[] = {
        __ATTR_RO(status),
        __ATTR_RO(enabled),
        __ATTR_RO(dpms),
        __ATTR_RO(modes),
+       __ATTR(polled, 0644, polled_show, polled_store),
 };
 
 /* These attributes are for both DVI-I connectors and all types of tv-out. */





^ permalink raw reply related	[flat|nested] 24+ messages in thread

* [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry
  2010-09-20 23:02   ` Andy Walls
                       ` (2 preceding siblings ...)
  2010-09-22  3:20     ` [PATCH v2 1/2] " Andy Walls
@ 2010-09-22  3:20     ` Andy Walls
  2010-09-22 15:06       ` Greg KH
  3 siblings, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-22  3:20 UTC (permalink / raw)
  To: linux-kernel
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	dri-devel, Jon Smirl

This is the initial addition of documentation for the drm module's sysfs
entries.  It provides a drm sysfs entries overview, and a detailed
description of the new drm per output connector "polled" entry in sysfs.

Signed-of-by: Andy Walls <awalls@md.metrocast.net>

diff --git a/Documentation/ABI/testing/sysfs-drm b/Documentation/ABI/testing/sysfs-drm
new file mode 100644
index 0000000..18a017a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-drm
@@ -0,0 +1,208 @@
+Direct Rendering Infrastructure (DRI) Direct Rendering Manager (drm) module
+and Translation Table Manager (ttm) module sysfs entries
+
+Example class view showing a single graphics adapter with three output
+connectors, a special control device node for the graphics adapter, and the
+Translation Table Manager (ttm) graphics memory manager virtual device:
+
+    /sys/class/drm/
+    ├── card0               -> ../../devices/<...>/drm/card0
+    ├── card0-DVI-D-1       -> ../../devices/<...>/drm/card0/card0-DVI-D-1
+    ├── card0-HDMI Type A-1 -> ../../devices/<...>/drm/card0/card0-HDMI Type A-1
+    ├── card0-VGA-1         -> ../../devices/<...>/drm/card0/card0-VGA-1
+    ├── controlD64          -> ../../devices/<...>/drm/controlD64
+    ├── ttm                 -> ../../devices/virtual/drm/ttm
+    └── version
+
+    6 directories, 1 file
+
+
+Corresponding DRI device nodes for the example graphics adapter, with
+additional ACL properties on card0 granting rw perms to the X/console user:
+
+    crw-rw----+ 1 root video 226,  0 2010-09-21 20:52 /dev/dri/card0
+    crw-rw-rw-. 1 root video 226, 64 2010-09-21 20:51 /dev/dri/controlD64
+
+
+Example physical device view for a single graphics adapter with three output
+connectors and a special control device node for the graphics adapter:
+
+    /sys/devices/<...>/drm
+    ├── card0
+    │   ├── card0-DVI-D-1
+    │   │   ├── device -> ../../card0
+    │   │   ├── dpms
+    │   │   ├── edid
+    │   │   ├── enabled
+    │   │   ├── modes
+    │   │   ├── polled
+    │   │   ├── power
+    │   │   │   ├── control
+    │   │   │   ├── runtime_active_time
+    │   │   │   ├── runtime_status
+    │   │   │   ├── runtime_suspended_time
+    │   │   │   ├── wakeup
+    │   │   │   └── wakeup_count
+    │   │   ├── status
+    │   │   ├── subsystem -> ../../../../../../../class/drm
+    │   │   └── uevent
+    │   ├── card0-HDMI Type A-1
+    │   │   ├── device -> ../../card0
+    │   │   ├── dpms
+    │   │   ├── edid
+    │   │   ├── enabled
+    │   │   ├── modes
+    │   │   ├── polled
+    │   │   ├── power
+    │   │   │   ├── control
+    │   │   │   ├── runtime_active_time
+    │   │   │   ├── runtime_status
+    │   │   │   ├── runtime_suspended_time
+    │   │   │   ├── wakeup
+    │   │   │   └── wakeup_count
+    │   │   ├── status
+    │   │   ├── subsystem -> ../../../../../../../class/drm
+    │   │   └── uevent
+    │   ├── card0-VGA-1
+    │   │   ├── device -> ../../card0
+    │   │   ├── dpms
+    │   │   ├── edid
+    │   │   ├── enabled
+    │   │   ├── modes
+    │   │   ├── polled
+    │   │   ├── power
+    │   │   │   ├── control
+    │   │   │   ├── runtime_active_time
+    │   │   │   ├── runtime_status
+    │   │   │   ├── runtime_suspended_time
+    │   │   │   ├── wakeup
+    │   │   │   └── wakeup_count
+    │   │   ├── status
+    │   │   ├── subsystem -> ../../../../../../../class/drm
+    │   │   └── uevent
+    │   ├── dev
+    │   ├── device -> ../../../0000:01:05.0
+    │   ├── power
+    │   │   ├── control
+    │   │   ├── runtime_active_time
+    │   │   ├── runtime_status
+    │   │   ├── runtime_suspended_time
+    │   │   ├── wakeup
+    │   │   └── wakeup_count
+    │   ├── subsystem -> ../../../../../../class/drm
+    │   └── uevent
+    └── controlD64
+        ├── dev
+        ├── device -> ../../../0000:01:05.0
+        ├── power
+        │   ├── control
+        │   ├── runtime_active_time
+        │   ├── runtime_status
+        │   ├── runtime_suspended_time
+        │   ├── wakeup
+        │   └── wakeup_count
+        ├── subsystem -> ../../../../../../class/drm
+        └── uevent
+
+    20 directories, 55 files
+
+
+Example virtual device view view showing the Translation Table Manager (ttm)
+graphics memory manager virtual device:
+
+    /sys/devices/virtual/drm
+    └── ttm
+        ├── buffer_objects
+        │   └── bo_count
+        ├── memory_accounting
+        │   ├── kernel
+        │   │   ├── available_memory
+        │   │   ├── emergency_memory
+        │   │   ├── swap_limit
+        │   │   ├── used_memory
+        │   │   └── zone_memory
+        │   └── pool
+        │       ├── pool_allocation_size
+        │       ├── pool_max_size
+        │       └── pool_small_allocation
+        ├── power
+        │   ├── control
+        │   ├── runtime_active_time
+        │   ├── runtime_status
+        │   ├── runtime_suspended_time
+        │   ├── wakeup
+        │   └── wakeup_count
+        ├── subsystem -> ../../../../class/drm
+        └── uevent
+
+    7 directories, 16 files
+
+
+
+Where:		/sys/devices/<...>/drm/cardN/cardN-C-M/polled
+		For N a decimal system graphics adapter number: 0, 1, 2, ...
+		For C a connector type name (including spaces) from the set:
+			Unknown
+			VGA
+			DVI-I
+			DVI-D
+			DVI-A
+			Composite
+			SVIDEO
+			LVDS
+			Component
+			9-pin DIN
+			DisplayPort
+			HDMI Type A
+			HDMI Type B
+			TV
+			Embedded DisplayPort
+		For M a decimal connector number for connectors of that type
+			over all the graphics adapters in the system: 1, 2, ...
+Date:		22 September 2010
+KernelVersion:	2.6.37
+Contact:	Andy Walls <awalls@md.metrocast.net>
+Description:
+		Manual control over DRM Kernel Mode Set (KMS) output connector
+		hotplug/connect/disconnect polling criteria.  The graphics
+		adapter drm driver (e.g. radeon, i915, nouveau) will detect
+		the available connectors on a graphics adapter and set polling
+		criteria flags for the connector to specify for what events the
+		0.1 Hz DRM KMS poll of the connector should look.
+
+		A read of the contents of this entry will show what flags are
+		available, with the names of flags that are set for the
+		connector enclosed in brackets:
+
+			# cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled
+			[hotplug_detectable] connect disconnect
+
+		A write of flags names to this entry, will clear the current
+		flag settings and set the poll criteria flags for that
+		connector to those specified names:
+
+			# echo " disconnect  connect " > \
+				/sys/devices/.../drm/card0/card0-DVI-D-1/polled
+			# cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled
+			hotplug_detectable [connect] [disconnect]
+
+			# echo > /sys/devices/.../drm/card0/card0-DVI-D-1/polled
+			# cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled
+			hotplug_detectable connect disconnect
+
+		The flags have the following meanings in drm_crtc_helper.c:
+
+			hotplug_detectable:
+			   always attempt to detect connection status upon poll
+			   don't automatically set up another poll of connector
+
+			connect:
+			   attempt to detect "connect" events
+			   automatically set up another poll of connector
+
+			disconnect:
+			   attempt to detect "disconnect" events
+			   automatically set up another poll of connector
+
+		Clearing all three flags will disable any detection actions
+		being taken for that connector during the 0.1 Hz poll.






^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-21 17:30       ` Andy Walls
@ 2010-09-22  5:30         ` Alex Deucher
  2010-09-22 12:31           ` Andy Walls
  2010-09-22 13:33           ` Jon Smirl
  0 siblings, 2 replies; 24+ messages in thread
From: Alex Deucher @ 2010-09-22  5:30 UTC (permalink / raw)
  To: Andy Walls
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	linux-kernel, dri-devel, Jon Smirl

On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> >> > DRM KMS polling of connections providing errant EDID responses, or
>> >> > polling of "connectors" that have chips responding on DDC I2C bus
>> >> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
>> >> > will create perpetual noise in dmesg and the system log every 10
>> >> > seconds.  Currently the user has apparently little recourse to silence
>> >> > these messages aside from replacing the offending cable, monitor, or
>> >> > graphics adapter.  That recourse is impossible for an unused DVI-D
>> >> > "connector" of an internal graphics processor on a motherboard that
>> >> > provides no physical DVI-D connector.
>> >> >
>> >> > This change allows the root user to disable (and re-enable) DRM KMS
>> >> > connector polling on a per connector basis via sysfs, like so:
>> >>
>> >> Huh, I didn't imagine solution of this issue that way.
>> >
>> > The problems with my initial patch, and related approaches, were:
>> >
>> > 1. They didn't get rid of all the spam in the logs, just the most
>> > verbose portion of it.
>> >
>> > 2. They didn't deal with the root cause of the log spam and all the
>> > related, but unneeded, I/O and processing that was still occurring.
>> >
>> >
>> >
>> >>  AFAIR previous
>> >> thread, something else was suggested, it was about storing the fact
>> >> that user already received warning/info about error.
>> >
>> > Yes, that was the discussion.
>> >
>> > I went with this patch because:
>> >
>> > 1. It deals with the root cause: unneeded DRM KMS connector polling
>> >
>> > 2. It eliminates all my DRM KMS connector polling related log spam, not
>> > just the hex dump.
>> >
>> > 3. The existing sysfs structure was already exposing 'struct
>> > drm_connector' members to user-space at per connector granularity
>> >
>> >
>> > The real root cause of the polling spew is that the radeon module, based
>> > on the best information it has (BIOS connector tables, I2C bus probes,
>> > etc.), makes a decision on if a connector should be polled and how it
>> > should be polled.
>> >
>> > Given incorrect BIOS tables, and strange I2C setups, the radeon module
>> > is bound to make the wrong decision about polling in some cases.  This
>> > change is a way for the human to step in a correct things, when the
>> > radeon driver gets it wrong.
>> >
>>
>> I'd rather fix the bug for real rather than providing users with an
>> out so that the bug never gets reported.
>
> There is already "an out" on it's way upstream:
>
> http://lkml.org/lkml/2010/9/6/375
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
>
> I noticed it after I submitted this patch.  If I'm reading it right, the
> module parameter fix is very coarse: it applies to all drm adapters and
> connectors in the system.
>
>>   What's the actual problem
>> you have?
>
> The actual problem I have is that the radeon driver reports three
> connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only
> one physical connector (VGA).  Polling of the HDMI appears to be
> inhibited by the radeon module code.  Polling of the (non-existent?)
> DVI-D interface yields a lot of log messages and useless I2C
> transactions.
>
> My precise gripe is with this code path
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_connectors.c;h=ecc1a8fafbfd3eb3c12c0c4d45b4b091a1bee03b;hb=refs/heads/drm-fixes#l772
>
> which is being polled every 10 seconds.  It is bad for me because this
> function is noisy:
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l136
>
> and this (insane?) loop multiplies the noise by a factor of 4:
>
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l264
>
>
> In a different user's operational context, all that noise may be
> beneficial.
>
>
> The real problem to me is that the radeon and drm modules have a single,
> standard way of dealing with EDID errors.  However, EDID errors can
> happen due to a number of different causes, some of which are external
> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
> thing" the drivers can do without input from the user on what the policy
> should be when a bad EDID is detected.
>
>
>
>
>>   Do you just want to turn polling off for an unused
>> connecter,
>
> Yes, that's what I would use my proposed patch for.
>
> (If a solution that avoids sysfs is required, I can work up a patch
> using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with
> a patch for some utility like xrandr.)
>
>
> In a larger sense it's about user policy for error reporting by the drm
> and radeon drivers, and error response by both the drivers and the user.
>
> In the face of EDID errors, a user may want to take the following
> actions:
>
>        ignore the errors
>        supress the errors
>        continue to monitor the errors for a time
>        replace cables
>        replace graphics adapter
>        replace monitor
>        report a bug
>
> All of those end user actions are possible right now, except the one to
> supress the errors (and the I2C transactions associated with them).
>
> A monitor, cable, and graphics adapter set that is currently
> experiencing EDID errors, may be otherwise working just fine.
>
> "Because we want to ensure people report bugs," does not seem like a
> good reason to prevent a user from turning off bogus error messages, for
> an otherwise working monitor that is providing broken EDID data.  What
> is the resolution of a bug report for a monitor providing bad EDID data
> going to look like?

I wasn't talking about the broken EDID messages, I was talking about
the bogus connector table entries on your board.  Those should be
properly quirked in the driver in which case, which would avoid the
problem all together in your case.

>
>
>>  or does the board have a bug in the connector table?
>
> I have not dug into the BIOS connector table bits and bytes to verify,
> but I'm assuming the connector table is incorrect.
>

It appears to be incorrect.  If you send me a copy of the vbios, I can
easily add a quirk. I suspect your board oem may offer several boards
with different output configurations and neglected to update the table
in some configurations.

>
>>   If
>> it's a bug, we can add a quirk so that it's properly handled.
>
> I don't see how a quirk table is going to cover the situations different
> from mine, that also provide bad EDID data in the code path I pointed
> out.  I know how one can add quirks for a connected DVI-D monitor that
> provides bad EDID data or none at all.
>
> The radeon module already has a connector_table module parameter for
> quirks.  That module option provides some hard-coded connector tables.
> I had considered adding more to that, but it seemed like a band-aid.
> Also, IIRC, the connector_table parameter currently applies globally to
> all radeon graphics adapters in the system, so it doesn't scale to
> multiple radeon adapters in the system.
>

It's best to just add a quirk for your board.  The connector_table
option is just an override for r1xx-r3xx mac and sun cards that do not
have useable vbios tables.  It's not really directly applicable to
atom-based systems like yours.

>
>
>>   What
>> physical connectors does the board have what does the driver report in
>> dmesg?
>
> The board only has a physical VGA connector.  The graphics adapter is an
> IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
> PCI IDs on the graphics adapter:
>
> 01:05.0 VGA compatible controller [0300]:
>        ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller])
>        Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
>
>
> Below is the dmesg output from the unmodified drm and radeon modules
> which includes samples of drm module log spam for the first 30 seconds
> or so after boot.
>
> Regards,
> Andy
>
> Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010
> [snip!]
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [drm] radeon: Initializing kernel modesetting.
> [drm] register mmio base: 0xFE7F0000
> [drm] register mmio size: 65536
> ATOM BIOS: ATI
> [drm] GPU reset succeed (RBBM_STATUS=0x10000140)
> [drm] radeon: VRAM 128M
> [drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF
> [drm] radeon: GTT 512M
> [drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF
>  alloc irq_desc for 28 on node 0
>  alloc kstat_irqs on node 0
> radeon 0000:01:05.0: irq 28 for MSI/MSI-X
> [drm] radeon: using MSI.
> [drm] radeon: irq initialized.
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 128bits DDR
> [TTM] Zone  kernel: Available graphics memory: 963036 kiB.
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] radeon: 1 quad pipes, 1 z pipes initialized.
> [drm] radeon: cp idle (0x10000C03)
> [drm] Loading RS690/RS740 Microcode
> platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin
> [drm] radeon: ring at 0x0000000080000000
> [drm] ring test succeeded in 1 usecs
> [drm] radeon: ib pool ready.
> [drm] ib test succeeded in 0 usecs
> [drm] Radeon Display Connectors
> [drm] Connector 0:
> [drm]   VGA
> [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
> [drm]   Encoders:
> [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> [drm] Connector 1:
> [drm]   DVI-D
> [drm]   HPD2
> [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
> [drm]   Encoders:
> [drm]     DFP2: INTERNAL_DDI
> [drm] Connector 2:
> [drm]   HDMI-A
> [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
> [drm]   Encoders:
> [drm]     DFP3: INTERNAL_LVTM1

FWIW, it's actually the HDMI connector that is generating the errors
due to the lack of a hpd pin assignment.


> [drm:drm_edid_is_valid] *ERROR* Raw EDID:
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>

Alex

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-20 21:11   ` Andy Walls
@ 2010-09-22  9:44     ` Florian Mickler
  2010-09-22 12:49       ` Andy Walls
  0 siblings, 1 reply; 24+ messages in thread
From: Florian Mickler @ 2010-09-22  9:44 UTC (permalink / raw)
  To: Andy Walls
  Cc: Greg KH, linux-kernel, dri-devel, Dave Airlie, Jon Smirl,
	Rafał Miłecki, Alex Deucher, Chris Wilson

[cc'd chris wilson]

Hi Andy!

On Mon, 20 Sep 2010 19:02:30 -0400
Andy Walls <awalls@md.metrocast.net> wrote:

> BTW, I found that Chris Wilson recently committed a change to inhibit
> all drm connector polling globally for a different reason:
> 
> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
> 
> That commit message shows a case where the driver decides polling needs
> to happen, but the human knows differently and manual control over
> connector polling mitigates the problem.


On Mon, 20 Sep 2010 17:11:48 -0400
Andy Walls <awalls@md.metrocast.net> wrote:

> On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
> > On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
>  
> > > This change allows the root user to disable (and re-enable) DRM KMS
> > > connector polling on a per connector basis via sysfs, like so:
> > > 
> > >         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
> > >         [hotplug_detectable] connect disconnect
> 
> > You are adding a sysfs file, yet you forgot to add a file in
> > Documentation/ABI.  Please fix that and resend the patch.
> 
> Oops, process failure, sorry.
> Will do.
> 
> Regards,
> Andy
> 

I thought sysfs files should be one thing per file... so, maybe
card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1
content would be easier to manipulate and parse? 

I have to defer to the drm maintainers for the usecases. But how is
having a monitor with a broken edid handled right now? While the output
is connected and used, it probably just stops polling?

cheers,
Flo





^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22  5:30         ` Alex Deucher
@ 2010-09-22 12:31           ` Andy Walls
  2010-09-22 20:16             ` Andy Walls
  2010-09-22 13:33           ` Jon Smirl
  1 sibling, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-22 12:31 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	linux-kernel, dri-devel, Jon Smirl

On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:
> On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:

> > In a larger sense it's about user policy for error reporting by the drm
> > and radeon drivers, and error response by both the drivers and the user.
> >
> > In the face of EDID errors, a user may want to take the following
> > actions:
> >
> >        ignore the errors
> >        supress the errors
> >        continue to monitor the errors for a time
> >        replace cables
> >        replace graphics adapter
> >        replace monitor
> >        report a bug
> >
> > All of those end user actions are possible right now, except the one to
> > supress the errors (and the I2C transactions associated with them).
> >
> > A monitor, cable, and graphics adapter set that is currently
> > experiencing EDID errors, may be otherwise working just fine.
> >
> > "Because we want to ensure people report bugs," does not seem like a
> > good reason to prevent a user from turning off bogus error messages, for
> > an otherwise working monitor that is providing broken EDID data.  What
> > is the resolution of a bug report for a monitor providing bad EDID data
> > going to look like?
> 
> I wasn't talking about the broken EDID messages, I was talking about
> the bogus connector table entries on your board.  Those should be
> properly quirked in the driver in which case, which would avoid the
> problem all together in your case.

The problem with in-kernel quirk databases are

- you'll always end up lagging behind what's being fielded,

- the number of stale entries will grow over the years,

- the scope of the fix for a single quirk entry for the total installed
    user base is small; each quirk table entry itself has little value

- quirks for working around unreliable attributes still need a 
    reliable system identification method (no big deal for PCI)

- fixing by quirk is a reactionary mode for kernel developers
    (it's also job security, so sysadmins are stuck coming back for
     help)

- it increases time to resolve problems for end users.

I don't think it's a good to plan to continually react to manufacturers
that have cycle times of 6 months to a year.  Quirk tables should be a
solution of last resort, when there's nothing else that can be done,
IMO.  


I understood.  A quirk database solves the immediate problem for me and
for owners of that MSI motherboard.

My current problem also highlights undesirable behavior that will occur
with broken EDIDs.  This undesirable behavior will likely resurface in
another bug report.


> >>  or does the board have a bug in the connector table?
> >
> > I have not dug into the BIOS connector table bits and bytes to verify,
> > but I'm assuming the connector table is incorrect.
> >
> 
> It appears to be incorrect.  If you send me a copy of the vbios, I can
> easily add a quirk. I suspect your board oem may offer several boards
> with different output configurations and neglected to update the table
> in some configurations.

Do you have a pointer to a set of steps to follow for extracting that
vbios information?




> >>   What
> >> physical connectors does the board have what does the driver report in
> >> dmesg?
> >
> > The board only has a physical VGA connector.  The graphics adapter is an
> > IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
> > PCI IDs on the graphics adapter:
> >
> > 01:05.0 VGA compatible controller [0300]:
> >        ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller])
> >        Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
> >
> >
> > Below is the dmesg output from the unmodified drm and radeon modules
> > which includes samples of drm module log spam for the first 30 seconds
> > or so after boot.

> > [drm] Radeon Display Connectors
> > [drm] Connector 0:
> > [drm]   VGA
> > [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
> > [drm]   Encoders:
> > [drm]     CRT1: INTERNAL_KLDSCP_DAC1
> > [drm] Connector 1:
> > [drm]   DVI-D
> > [drm]   HPD2
> > [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
> > [drm]   Encoders:
> > [drm]     DFP2: INTERNAL_DDI
> > [drm] Connector 2:
> > [drm]   HDMI-A
> > [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
> > [drm]   Encoders:
> > [drm]     DFP3: INTERNAL_LVTM1
> 
> FWIW, it's actually the HDMI connector that is generating the errors
> due to the lack of a hpd pin assignment.

Are you sure?  My /var/log/messages spam insists it is DVI-D-1 (hex
dumps omitted):

Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID


Regards,
Andy



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22  9:44     ` Florian Mickler
@ 2010-09-22 12:49       ` Andy Walls
  0 siblings, 0 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-22 12:49 UTC (permalink / raw)
  To: Florian Mickler
  Cc: Greg KH, linux-kernel, dri-devel, Dave Airlie, Jon Smirl,
	Rafał Miłecki, Alex Deucher, Chris Wilson

On Wed, 2010-09-22 at 11:44 +0200, Florian Mickler wrote:
> [cc'd chris wilson]

Oops.  Thanks!

> Hi Andy!
> 
> On Mon, 20 Sep 2010 19:02:30 -0400
> Andy Walls <awalls@md.metrocast.net> wrote:
> 
> > BTW, I found that Chris Wilson recently committed a change to inhibit
> > all drm connector polling globally for a different reason:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
> > 
> > That commit message shows a case where the driver decides polling needs
> > to happen, but the human knows differently and manual control over
> > connector polling mitigates the problem.
> 
> 
> On Mon, 20 Sep 2010 17:11:48 -0400
> Andy Walls <awalls@md.metrocast.net> wrote:
> 
> > On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
> > > On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
> >  
> > > > This change allows the root user to disable (and re-enable) DRM KMS
> > > > connector polling on a per connector basis via sysfs, like so:
> > > > 
> > > >         # cat /sys/class/drm/card0/card0-DVI-D-1/polled
> > > >         [hotplug_detectable] connect disconnect
> > 
> > > You are adding a sysfs file, yet you forgot to add a file in
> > > Documentation/ABI.  Please fix that and resend the patch.
> > 
> > Oops, process failure, sorry.
> > Will do.
> > 
> > Regards,
> > Andy
> > 
> 
> I thought sysfs files should be one thing per file... so, maybe
> card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1
> content would be easier to manipulate and parse? 

If precedent matters, the sysfs nodes for setting

	the IO scheduler
	the active trigger function on an LED
	the active IR remote control protocols

all use the same sort of paradigm as I did.

The IO scheduler and LED trigger ones allow the user to set 1 of N
choices.  The IR protocol one allows the user to set M of N choices.
They all uses brackets to differentiate [set] vs unset.


> I have to defer to the drm maintainers for the usecases. But how is
> having a monitor with a broken edid handled right now? While the output
> is connected and used, it probably just stops polling?

Not from what I can see.  I could very well be wrong on that, so please
someone double check me.

This error message sequence, and from what I saw in the code, indicates
to me that the gripe for a constantly bad EDID will never end:

Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID:
Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid.
Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID

This time around we 

	"probed a monitor but no|invalid EDID"

so lets do it again later, and maybe we'll get a different result.

That's legitimate to do once or twice because of transient conditions:
one may get a bad EDID due to monitor power on/off or cable
connect/disconnect.

To keep doing it for persistent error conditions, when the user fully
understands the source of the error and has assessed the impact as
inconsequential, is annoying.

By now, I guess everyone can tell at least I'm annoyed by it. :) 

Regards,
Andy



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22  5:30         ` Alex Deucher
  2010-09-22 12:31           ` Andy Walls
@ 2010-09-22 13:33           ` Jon Smirl
  2010-09-22 21:07             ` Andy Walls
  1 sibling, 1 reply; 24+ messages in thread
From: Jon Smirl @ 2010-09-22 13:33 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Andy Walls, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>>> >> > DRM KMS polling of connections providing errant EDID responses, or
>>> >> > polling of "connectors" that have chips responding on DDC I2C bus
>>> >> > address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM,
>>> >> > will create perpetual noise in dmesg and the system log every 10
>>> >> > seconds.  Currently the user has apparently little recourse to silence
>>> >> > these messages aside from replacing the offending cable, monitor, or
>>> >> > graphics adapter.  That recourse is impossible for an unused DVI-D
>>> >> > "connector" of an internal graphics processor on a motherboard that
>>> >> > provides no physical DVI-D connector.
>>> >> >
>>> >> > This change allows the root user to disable (and re-enable) DRM KMS
>>> >> > connector polling on a per connector basis via sysfs, like so:
>>> >>
>>> >> Huh, I didn't imagine solution of this issue that way.
>>> >
>>> > The problems with my initial patch, and related approaches, were:
>>> >
>>> > 1. They didn't get rid of all the spam in the logs, just the most
>>> > verbose portion of it.
>>> >
>>> > 2. They didn't deal with the root cause of the log spam and all the
>>> > related, but unneeded, I/O and processing that was still occurring.
>>> >
>>> >
>>> >
>>> >>  AFAIR previous
>>> >> thread, something else was suggested, it was about storing the fact
>>> >> that user already received warning/info about error.
>>> >
>>> > Yes, that was the discussion.
>>> >
>>> > I went with this patch because:
>>> >
>>> > 1. It deals with the root cause: unneeded DRM KMS connector polling
>>> >
>>> > 2. It eliminates all my DRM KMS connector polling related log spam, not
>>> > just the hex dump.
>>> >
>>> > 3. The existing sysfs structure was already exposing 'struct
>>> > drm_connector' members to user-space at per connector granularity
>>> >
>>> >
>>> > The real root cause of the polling spew is that the radeon module, based
>>> > on the best information it has (BIOS connector tables, I2C bus probes,
>>> > etc.), makes a decision on if a connector should be polled and how it
>>> > should be polled.
>>> >
>>> > Given incorrect BIOS tables, and strange I2C setups, the radeon module
>>> > is bound to make the wrong decision about polling in some cases.  This
>>> > change is a way for the human to step in a correct things, when the
>>> > radeon driver gets it wrong.
>>> >
>>>
>>> I'd rather fix the bug for real rather than providing users with an
>>> out so that the bug never gets reported.
>>
>> There is already "an out" on it's way upstream:
>>
>> http://lkml.org/lkml/2010/9/6/375
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58f637bb96d5a0ae0919b9998b891d1ba7e47c9
>>
>> I noticed it after I submitted this patch.  If I'm reading it right, the
>> module parameter fix is very coarse: it applies to all drm adapters and
>> connectors in the system.
>>
>>>   What's the actual problem
>>> you have?
>>
>> The actual problem I have is that the radeon driver reports three
>> connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only
>> one physical connector (VGA).  Polling of the HDMI appears to be
>> inhibited by the radeon module code.  Polling of the (non-existent?)
>> DVI-D interface yields a lot of log messages and useless I2C
>> transactions.
>>
>> My precise gripe is with this code path
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/radeon/radeon_connectors.c;h=ecc1a8fafbfd3eb3c12c0c4d45b4b091a1bee03b;hb=refs/heads/drm-fixes#l772
>>
>> which is being polled every 10 seconds.  It is bad for me because this
>> function is noisy:
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l136
>>
>> and this (insane?) loop multiplies the noise by a factor of 4:
>>
>> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_edid.c;h=96e96310822513bfd9c984054a913eac7b5acc50;hb=refs/heads/drm-fixes#l264
>>
>>
>> In a different user's operational context, all that noise may be
>> beneficial.
>>
>>
>> The real problem to me is that the radeon and drm modules have a single,
>> standard way of dealing with EDID errors.  However, EDID errors can
>> happen due to a number of different causes, some of which are external
>> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
>> thing" the drivers can do without input from the user on what the policy
>> should be when a bad EDID is detected.

Andy, this sure looks like a broken VBIOS to me. First thing would be
to update your VBIOS if possible to get a correct table for your
hardware. Second would be to add a quirk in the kernel.

There are lots of cases where the kernel does odd things when the BIOS
feeds it bad information. Do we really want hundreds of switches in
sysfs allowing adjustments for broken BIOS features? We already have
the quirk scheme for addressing this.

A simpler solution for reducing the log spam would be to only report
the error once, instead of every 10 seconds. The driver could remember
it has made the error report and then log another message later if the
error was cleared.


>>>   Do you just want to turn polling off for an unused
>>> connecter,
>>
>> Yes, that's what I would use my proposed patch for.
>>
>> (If a solution that avoids sysfs is required, I can work up a patch
>> using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with
>> a patch for some utility like xrandr.)
>>
>>
>> In a larger sense it's about user policy for error reporting by the drm
>> and radeon drivers, and error response by both the drivers and the user.
>>
>> In the face of EDID errors, a user may want to take the following
>> actions:
>>
>>        ignore the errors
>>        supress the errors
>>        continue to monitor the errors for a time
>>        replace cables
>>        replace graphics adapter
>>        replace monitor
>>        report a bug
>>
>> All of those end user actions are possible right now, except the one to
>> supress the errors (and the I2C transactions associated with them).
>>
>> A monitor, cable, and graphics adapter set that is currently
>> experiencing EDID errors, may be otherwise working just fine.
>>
>> "Because we want to ensure people report bugs," does not seem like a
>> good reason to prevent a user from turning off bogus error messages, for
>> an otherwise working monitor that is providing broken EDID data.  What
>> is the resolution of a bug report for a monitor providing bad EDID data
>> going to look like?
>
> I wasn't talking about the broken EDID messages, I was talking about
> the bogus connector table entries on your board.  Those should be
> properly quirked in the driver in which case, which would avoid the
> problem all together in your case.
>
>>
>>
>>>  or does the board have a bug in the connector table?
>>
>> I have not dug into the BIOS connector table bits and bytes to verify,
>> but I'm assuming the connector table is incorrect.
>>
>
> It appears to be incorrect.  If you send me a copy of the vbios, I can
> easily add a quirk. I suspect your board oem may offer several boards
> with different output configurations and neglected to update the table
> in some configurations.
>
>>
>>>   If
>>> it's a bug, we can add a quirk so that it's properly handled.
>>
>> I don't see how a quirk table is going to cover the situations different
>> from mine, that also provide bad EDID data in the code path I pointed
>> out.  I know how one can add quirks for a connected DVI-D monitor that
>> provides bad EDID data or none at all.
>>
>> The radeon module already has a connector_table module parameter for
>> quirks.  That module option provides some hard-coded connector tables.
>> I had considered adding more to that, but it seemed like a band-aid.
>> Also, IIRC, the connector_table parameter currently applies globally to
>> all radeon graphics adapters in the system, so it doesn't scale to
>> multiple radeon adapters in the system.
>>
>
> It's best to just add a quirk for your board.  The connector_table
> option is just an override for r1xx-r3xx mac and sun cards that do not
> have useable vbios tables.  It's not really directly applicable to
> atom-based systems like yours.
>
>>
>>
>>>   What
>>> physical connectors does the board have what does the driver report in
>>> dmesg?
>>
>> The board only has a physical VGA connector.  The graphics adapter is an
>> IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302).  Here are the
>> PCI IDs on the graphics adapter:
>>
>> 01:05.0 VGA compatible controller [0300]:
>>        ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller])
>>        Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
>>
>>
>> Below is the dmesg output from the unmodified drm and radeon modules
>> which includes samples of drm module log spam for the first 30 seconds
>> or so after boot.
>>
>> Regards,
>> Andy
>>
>> Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010
>> [snip!]
>> [drm] Initialized drm 1.1.0 20060810
>> [drm] radeon defaulting to kernel modesetting.
>> [drm] radeon kernel modesetting enabled.
>> radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>> [drm] radeon: Initializing kernel modesetting.
>> [drm] register mmio base: 0xFE7F0000
>> [drm] register mmio size: 65536
>> ATOM BIOS: ATI
>> [drm] GPU reset succeed (RBBM_STATUS=0x10000140)
>> [drm] radeon: VRAM 128M
>> [drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF
>> [drm] radeon: GTT 512M
>> [drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF
>>  alloc irq_desc for 28 on node 0
>>  alloc kstat_irqs on node 0
>> radeon 0000:01:05.0: irq 28 for MSI/MSI-X
>> [drm] radeon: using MSI.
>> [drm] radeon: irq initialized.
>> [drm] Detected VRAM RAM=128M, BAR=128M
>> [drm] RAM width 128bits DDR
>> [TTM] Zone  kernel: Available graphics memory: 963036 kiB.
>> [drm] radeon: 128M of VRAM memory ready
>> [drm] radeon: 512M of GTT memory ready.
>> [drm] GART: num cpu pages 131072, num gpu pages 131072
>> [drm] radeon: 1 quad pipes, 1 z pipes initialized.
>> [drm] radeon: cp idle (0x10000C03)
>> [drm] Loading RS690/RS740 Microcode
>> platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin
>> [drm] radeon: ring at 0x0000000080000000
>> [drm] ring test succeeded in 1 usecs
>> [drm] radeon: ib pool ready.
>> [drm] ib test succeeded in 0 usecs
>> [drm] Radeon Display Connectors
>> [drm] Connector 0:
>> [drm]   VGA
>> [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
>> [drm]   Encoders:
>> [drm]     CRT1: INTERNAL_KLDSCP_DAC1
>> [drm] Connector 1:
>> [drm]   DVI-D
>> [drm]   HPD2
>> [drm]   DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c
>> [drm]   Encoders:
>> [drm]     DFP2: INTERNAL_DDI
>> [drm] Connector 2:
>> [drm]   HDMI-A
>> [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c
>> [drm]   Encoders:
>> [drm]     DFP3: INTERNAL_LVTM1
>
> FWIW, it's actually the HDMI connector that is generating the errors
> due to the lack of a hpd pin assignment.
>
>
>> [drm:drm_edid_is_valid] *ERROR* Raw EDID:
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>>
>
> Alex
>



-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry
  2010-09-22  3:20     ` [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry Andy Walls
@ 2010-09-22 15:06       ` Greg KH
  2010-09-22 16:36         ` Andy Walls
  0 siblings, 1 reply; 24+ messages in thread
From: Greg KH @ 2010-09-22 15:06 UTC (permalink / raw)
  To: Andy Walls
  Cc: linux-kernel, Rafał Miłecki, Dave Airlie, dri-devel,
	Jon Smirl

On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> +Where:		/sys/devices/<...>/drm/cardN/cardN-C-M/polled
> +		For N a decimal system graphics adapter number: 0, 1, 2, ...
> +		For C a connector type name (including spaces) from the set:

Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
your way to make it hard for people?

> +			Unknown
> +			VGA
> +			DVI-I
> +			DVI-D
> +			DVI-A
> +			Composite
> +			SVIDEO
> +			LVDS
> +			Component
> +			9-pin DIN
> +			DisplayPort
> +			HDMI Type A
> +			HDMI Type B
> +			TV
> +			Embedded DisplayPort

You could always just use a '_' instead of a space for those that need
it.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry
  2010-09-22 15:06       ` Greg KH
@ 2010-09-22 16:36         ` Andy Walls
  2010-09-22 19:23           ` Greg KH
  0 siblings, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-22 16:36 UTC (permalink / raw)
  To: Greg KH
  Cc: linux-kernel, Rafał Miłecki, Dave Airlie, dri-devel,
	Jon Smirl

On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
> On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> > +Where:		/sys/devices/<...>/drm/cardN/cardN-C-M/polled
> > +		For N a decimal system graphics adapter number: 0, 1, 2, ...
> > +		For C a connector type name (including spaces) from the set:
> 
> Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
> your way to make it hard for people?

Not my fault.
It was like that when I got here.


$ ls -d /sys/devices/pci0000\:00/0000\:00\:01.0/0000\:01\:05.0/drm//card0/card0*
/sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-DVI-D-1
/sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-HDMI Type A-1
/sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-VGA-1

I only added one entry, "polled", in those existing directories.

BTW, Jon Smirl, IBM Corp, and you have Copyright credit in the
drm_sysfs.c file that creates those directories with spaces.  ;)


I'll also gripe that PCI's colons are pretty annoying on the command
line too, since they have to be escaped as well.


> > +			HDMI Type A
> > +			HDMI Type B
> > +			TV
> > +			Embedded DisplayPort
> 
> You could always just use a '_' instead of a space for those that need
> it.

A trivial patch here would do that:

http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drivers/gpu/drm/drm_crtc.c;h=37e0b4fa482a810afc9eded6fda136a90bcc5cc0;hb=refs/heads/drm-fixes#l146

but I have no idea what that might break.

Regards,
Andy



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry
  2010-09-22 16:36         ` Andy Walls
@ 2010-09-22 19:23           ` Greg KH
  0 siblings, 0 replies; 24+ messages in thread
From: Greg KH @ 2010-09-22 19:23 UTC (permalink / raw)
  To: Andy Walls
  Cc: linux-kernel, Rafał Miłecki, Dave Airlie, dri-devel,
	Jon Smirl

On Wed, Sep 22, 2010 at 12:36:06PM -0400, Andy Walls wrote:
> On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
> > On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
> > > +Where:		/sys/devices/<...>/drm/cardN/cardN-C-M/polled
> > > +		For N a decimal system graphics adapter number: 0, 1, 2, ...
> > > +		For C a connector type name (including spaces) from the set:
> > 
> > Spaces?  Really?  Yeah, I know it will work just fine, but why go out of
> > your way to make it hard for people?
> 
> Not my fault.
> It was like that when I got here.

Ah, ok, sorry about that, I didn't realize it.  No objection from me
then, thanks for the documentation.

greg k-h

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22 12:31           ` Andy Walls
@ 2010-09-22 20:16             ` Andy Walls
  0 siblings, 0 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-22 20:16 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Rafał Miłecki, Dave Airlie, Greg Kroah-Hartman,
	linux-kernel, dri-devel, Jon Smirl

On Wed, 2010-09-22 at 08:31 -0400, Andy Walls wrote:
> On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:

> > It appears to be incorrect.  If you send me a copy of the vbios, I can
> > easily add a quirk. I suspect your board oem may offer several boards
> > with different output configurations and neglected to update the table
> > in some configurations.
> 
> Do you have a pointer to a set of steps to follow for extracting that
> vbios information?

Never mind, I figured it out.

# echo 1 > /sys/class/drm/card0/device/rom
# dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
# echo 0 > /sys/class/drm/card0/device/rom

I will send it via private email.

Regards,
Andy



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22 13:33           ` Jon Smirl
@ 2010-09-22 21:07             ` Andy Walls
  2010-09-22 22:05               ` Jon Smirl
  2010-09-24 19:12               ` Alex Deucher
  0 siblings, 2 replies; 24+ messages in thread
From: Andy Walls @ 2010-09-22 21:07 UTC (permalink / raw)
  To: Jon Smirl
  Cc: Alex Deucher, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
> >>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
> >>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:

> >> The real problem to me is that the radeon and drm modules have a single,
> >> standard way of dealing with EDID errors.  However, EDID errors can
> >> happen due to a number of different causes, some of which are external
> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
> >> thing" the drivers can do without input from the user on what the policy
> >> should be when a bad EDID is detected.
> 
> Andy, this sure looks like a broken VBIOS to me.

Well sure.

But that problem causes other problems in error handling code paths to
surface.  It also brings to light that there are some cases that are
undecidable, or not worth the effort, for the error handling code paths
on what the proper action should be.


>  First thing would be
> to update your VBIOS if possible to get a correct table for your
> hardware.

Um, no.

I will not risk taking an operational machine down due to flash write
failure, however small the probability, due to the high impact.
The reward of shutting up kernel error messages, is not worth the risk.


>  Second would be to add a quirk in the kernel.

I have expressed my thoughts on quirks in a previous post.


> There are lots of cases where the kernel does odd things when the BIOS
> feeds it bad information. Do we really want hundreds of switches in
> sysfs allowing adjustments for broken BIOS features?

I see very little downside in giving the user more control over his
system.  A thousand knobs and switches are worth it for the user, for
the one switch that is there when the user needs it to solve a problem.

To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver
to dump the ROM.  That would have consumed a lot of time.  Luckily for
me, there was a switch to turn on the ROM and dump it:

	# echo 1 > /sys/class/drm/card0/device/rom
	# dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
	# echo 0 > /sys/class/drm/card0/device/rom

I never used it before and will likely never use it again.  But when I
had a problem I needed to solve, its availability made the solution
simple and efficient.  Time to accomplish tasks is my scarcest resource;
time efficiency is very important to me.


The only downside to hundreds of switches and control knobs I can really
think of is possibly complexity for the end user.  But it turns out,
that ignoring the available controls, or ignoring large subsets of the
available controls, is how people are going to deal with that
complexity.  Heck, I ignore most of sysfs almost all the time.  I also
ignore almost every module option available.  My system runs fine
without me caring about a majority of the existing switches.


BTW, we already have thousands of switches and controls for kernel
internals in linux without sysfs and ioctl()'s:

$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} \; | grep '^parm:' | wc -l
3387

Why do we have that many?  They are low cost in complexity, as they can
easily be ignored.  They are high value in utility, as they give the
user control over his system to deal with unusual circumstances.

</rant>




>  We already have
> the quirk scheme for addressing this.
> 
> A simpler solution for reducing the log spam would be to only report
> the error once, instead of every 10 seconds. The driver could remember
> it has made the error report and then log another message later if the
> error was cleared.

My sysfs implementation was only 69 changed lines in one file:

	drivers/gpu/drm/drm_sysfs.c         |   69 +++++++++++

I doubt a solution to add logic to the error paths, to try and divine
all the sources of EDID errors by saving state and applying rules to
take the correct action, is going to be less change than that.  I know
more than one file will have to change.

Regards,
Andy


^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22 21:07             ` Andy Walls
@ 2010-09-22 22:05               ` Jon Smirl
  2010-09-24 19:12               ` Alex Deucher
  1 sibling, 0 replies; 24+ messages in thread
From: Jon Smirl @ 2010-09-22 22:05 UTC (permalink / raw)
  To: Andy Walls
  Cc: Alex Deucher, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
>> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>> >>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>
>> >> The real problem to me is that the radeon and drm modules have a single,
>> >> standard way of dealing with EDID errors.  However, EDID errors can
>> >> happen due to a number of different causes, some of which are external
>> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
>> >> thing" the drivers can do without input from the user on what the policy
>> >> should be when a bad EDID is detected.
>>
>> Andy, this sure looks like a broken VBIOS to me.
>
> Well sure.
>
> But that problem causes other problems in error handling code paths to
> surface.  It also brings to light that there are some cases that are
> undecidable, or not worth the effort, for the error handling code paths
> on what the proper action should be.
>
>
>>  First thing would be
>> to update your VBIOS if possible to get a correct table for your
>> hardware.
>
> Um, no.
>
> I will not risk taking an operational machine down due to flash write
> failure, however small the probability, due to the high impact.
> The reward of shutting up kernel error messages, is not worth the risk.
>
>
>>  Second would be to add a quirk in the kernel.
>
> I have expressed my thoughts on quirks in a previous post.
>
>
>> There are lots of cases where the kernel does odd things when the BIOS
>> feeds it bad information. Do we really want hundreds of switches in
>> sysfs allowing adjustments for broken BIOS features?
>
> I see very little downside in giving the user more control over his
> system.  A thousand knobs and switches are worth it for the user, for
> the one switch that is there when the user needs it to solve a problem.
>
> To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver
> to dump the ROM.  That would have consumed a lot of time.  Luckily for
> me, there was a switch to turn on the ROM and dump it:

The ROM is turned off by default due to a provision in the PCI spec
that allows the address space of it to be reused after boot. A few old
PCI devices make use of this feature. If you turn the ROM on in those
machines they will crash.

>
>        # echo 1 > /sys/class/drm/card0/device/rom
>        # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
>        # echo 0 > /sys/class/drm/card0/device/rom
>
> I never used it before and will likely never use it again.  But when I
> had a problem I needed to solve, its availability made the solution
> simple and efficient.  Time to accomplish tasks is my scarcest resource;
> time efficiency is very important to me.
>
>
> The only downside to hundreds of switches and control knobs I can really
> think of is possibly complexity for the end user.  But it turns out,
> that ignoring the available controls, or ignoring large subsets of the
> available controls, is how people are going to deal with that
> complexity.  Heck, I ignore most of sysfs almost all the time.  I also
> ignore almost every module option available.  My system runs fine
> without me caring about a majority of the existing switches.
>
>
> BTW, we already have thousands of switches and controls for kernel
> internals in linux without sysfs and ioctl()'s:
>
> $ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} \; | grep '^parm:' | wc -l
> 3387
>
> Why do we have that many?  They are low cost in complexity, as they can
> easily be ignored.  They are high value in utility, as they give the
> user control over his system to deal with unusual circumstances.
>
> </rant>
>
>
>
>
>>  We already have
>> the quirk scheme for addressing this.
>>
>> A simpler solution for reducing the log spam would be to only report
>> the error once, instead of every 10 seconds. The driver could remember
>> it has made the error report and then log another message later if the
>> error was cleared.
>
> My sysfs implementation was only 69 changed lines in one file:
>
>        drivers/gpu/drm/drm_sysfs.c         |   69 +++++++++++
>
> I doubt a solution to add logic to the error paths, to try and divine
> all the sources of EDID errors by saving state and applying rules to
> take the correct action, is going to be less change than that.  I know
> more than one file will have to change.
>
> Regards,
> Andy
>
>



-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-22 21:07             ` Andy Walls
  2010-09-22 22:05               ` Jon Smirl
@ 2010-09-24 19:12               ` Alex Deucher
  2010-09-26 18:12                 ` Andy Walls
  1 sibling, 1 reply; 24+ messages in thread
From: Alex Deucher @ 2010-09-24 19:12 UTC (permalink / raw)
  To: Andy Walls
  Cc: Jon Smirl, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

[-- Attachment #1: Type: text/plain, Size: 4744 bytes --]

On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
>> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>> >>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>
>> >> The real problem to me is that the radeon and drm modules have a single,
>> >> standard way of dealing with EDID errors.  However, EDID errors can
>> >> happen due to a number of different causes, some of which are external
>> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
>> >> thing" the drivers can do without input from the user on what the policy
>> >> should be when a bad EDID is detected.
>>
>> Andy, this sure looks like a broken VBIOS to me.
>
> Well sure.
>
> But that problem causes other problems in error handling code paths to
> surface.  It also brings to light that there are some cases that are
> undecidable, or not worth the effort, for the error handling code paths
> on what the proper action should be.
>
>
>>  First thing would be
>> to update your VBIOS if possible to get a correct table for your
>> hardware.
>
> Um, no.
>
> I will not risk taking an operational machine down due to flash write
> failure, however small the probability, due to the high impact.
> The reward of shutting up kernel error messages, is not worth the risk.
>
>
>>  Second would be to add a quirk in the kernel.
>
> I have expressed my thoughts on quirks in a previous post.
>
>
>> There are lots of cases where the kernel does odd things when the BIOS
>> feeds it bad information. Do we really want hundreds of switches in
>> sysfs allowing adjustments for broken BIOS features?
>
> I see very little downside in giving the user more control over his
> system.  A thousand knobs and switches are worth it for the user, for
> the one switch that is there when the user needs it to solve a problem.
>
> To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver
> to dump the ROM.  That would have consumed a lot of time.  Luckily for
> me, there was a switch to turn on the ROM and dump it:
>
>        # echo 1 > /sys/class/drm/card0/device/rom
>        # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin
>        # echo 0 > /sys/class/drm/card0/device/rom
>
> I never used it before and will likely never use it again.  But when I
> had a problem I needed to solve, its availability made the solution
> simple and efficient.  Time to accomplish tasks is my scarcest resource;
> time efficiency is very important to me.
>


The attached patch should fix up your board.  Let me know if it works for you.

Thanks,

Alex


>
> The only downside to hundreds of switches and control knobs I can really
> think of is possibly complexity for the end user.  But it turns out,
> that ignoring the available controls, or ignoring large subsets of the
> available controls, is how people are going to deal with that
> complexity.  Heck, I ignore most of sysfs almost all the time.  I also
> ignore almost every module option available.  My system runs fine
> without me caring about a majority of the existing switches.
>
>
> BTW, we already have thousands of switches and controls for kernel
> internals in linux without sysfs and ioctl()'s:
>
> $ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} \; | grep '^parm:' | wc -l
> 3387
>
> Why do we have that many?  They are low cost in complexity, as they can
> easily be ignored.  They are high value in utility, as they give the
> user control over his system to deal with unusual circumstances.
>
> </rant>
>
>
>
>
>>  We already have
>> the quirk scheme for addressing this.
>>
>> A simpler solution for reducing the log spam would be to only report
>> the error once, instead of every 10 seconds. The driver could remember
>> it has made the error report and then log another message later if the
>> error was cleared.
>
> My sysfs implementation was only 69 changed lines in one file:
>
>        drivers/gpu/drm/drm_sysfs.c         |   69 +++++++++++
>
> I doubt a solution to add logic to the error paths, to try and divine
> all the sources of EDID errors by saving state and applying rules to
> take the correct action, is going to be less change than that.  I know
> more than one file will have to change.
>
> Regards,
> Andy
>
>

[-- Attachment #2: 0001-drm-radeon-kms-add-quirk-for-MSI-K9A2GM-motherboard.patch --]
[-- Type: text/x-patch, Size: 1343 bytes --]

From 0031a6b077a8f81ed680e2c1dc66bdde73dda72b Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexdeucher@gmail.com>
Date: Fri, 24 Sep 2010 15:08:44 -0400
Subject: [PATCH] drm/radeon/kms: add quirk for MSI K9A2GM motherboard

Board has no digital connectors

Reported-by: Andy Walls <awalls@md.metrocast.net>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
---
 drivers/gpu/drm/radeon/radeon_atombios.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index ebae14c..68932ba 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -317,6 +317,15 @@ static bool radeon_atom_apply_quirks(struct drm_device *dev,
 			*connector_type = DRM_MODE_CONNECTOR_DVID;
 	}
 
+	/* MSI K9A2GM V2/V3 board has no HDMI or DVI */
+	if ((dev->pdev->device == 0x796e) &&
+	    (dev->pdev->subsystem_vendor == 0x1462) &&
+	    (dev->pdev->subsystem_device == 0x7302)) {
+		if ((supported_device == ATOM_DEVICE_DFP2_SUPPORT) ||
+		    (supported_device == ATOM_DEVICE_DFP3_SUPPORT))
+			return false;
+	}
+
 	/* a-bit f-i90hd - ciaranm on #radeonhd - this board has no DVI */
 	if ((dev->pdev->device == 0x7941) &&
 	    (dev->pdev->subsystem_vendor == 0x147b) &&
-- 
1.7.1.1


^ permalink raw reply related	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-24 19:12               ` Alex Deucher
@ 2010-09-26 18:12                 ` Andy Walls
  2010-09-27 15:45                   ` Alex Deucher
  0 siblings, 1 reply; 24+ messages in thread
From: Andy Walls @ 2010-09-26 18:12 UTC (permalink / raw)
  To: Alex Deucher
  Cc: Jon Smirl, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

On Fri, 2010-09-24 at 15:12 -0400, Alex Deucher wrote:
> On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> > On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
> >> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
> >> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> >> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
> >> >>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> >> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
> >> >>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
> >
> >> >> The real problem to me is that the radeon and drm modules have a single,
> >> >> standard way of dealing with EDID errors.  However, EDID errors can
> >> >> happen due to a number of different causes, some of which are external
> >> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
> >> >> thing" the drivers can do without input from the user on what the policy
> >> >> should be when a bad EDID is detected.
> >>


> The attached patch should fix up your board.  Let me know if it works for you.

That patch suppresses the setup of the HDMI and DVI connectors that
don't exist, so the log spam from polling for EDID's is gone for me.

        [PATCH] drm/radeon/kms: add quirk for MSI K9A2GM motherboard
        
        Board has no digital connectors
        
        Reported-by: Andy Walls <awalls@md.metrocast.net>
        Tested-by: Andy Walls <awalls@md.metrocast.net>
        Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
        Cc: stable@kernel.org


Yes it works for me, but it's what I'd call a "point solution".  There
are still these which appear to be the exact same symptoms (perpetual
EDID log spam) just for different hardware setups:

        https://bugs.freedesktop.org/show_bug.cgi?id=27708
        https://partner-bugzilla.redhat.com/show_bug.cgi?id=610362
        

Here was a broader solution for a particular class of machines (Laptops
with i915 chips with an LVDS with a broken EDID) exhibiting those same
symptoms:

        https://patchwork.kernel.org/patch/83556/

Picking these bugs off one or two at a time, as users report the same
symptoms over an over again, is really a waste of users' time.  Users
wait while their report is queued, a custom kernel patch developed, and
a kernel patch makes it through their distro to them.


On a different subject, with your patch applied, I'm now seeing a new
error message in my log that I have not seen before:

	failed to evaluate ATIF got AE_BAD_PARAMETER

Here's the dmesg from drm:

        [drm] Initialized drm 1.1.0 20060810
        [drm] radeon defaulting to kernel modesetting.
        [drm] radeon kernel modesetting enabled.
        radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
        [drm] initializing kernel modesetting (RS740 0x1002:0x796E).
        [drm] register mmio base: 0xFE7F0000
        [drm] register mmio size: 65536
        ATOM BIOS: ATI
        radeon 0000:01:05.0: VRAM: 128M 0x78000000 - 0x7FFFFFFF (128M used)
        radeon 0000:01:05.0: GTT: 512M 0x80000000 - 0x9FFFFFFF
        [drm] radeon: irq initialized.
        [drm] Detected VRAM RAM=128M, BAR=128M
        [drm] RAM width 128bits DDR
        [TTM] Zone  kernel: Available graphics memory: 963022 kiB.
        [TTM] Initializing pool allocator.
        [drm] radeon: 128M of VRAM memory ready
        [drm] radeon: 512M of GTT memory ready.
        [drm] GART: num cpu pages 131072, num gpu pages 131072
        [drm] radeon: 1 quad pipes, 1 z pipes initialized.
        [drm] Loading RS690/RS740 Microcode
        [drm] radeon: ring at 0x0000000080000000
        [drm] ring test succeeded in 1 usecs
        [drm] radeon: ib pool ready.
        [drm] ib test succeeded in 0 usecs
        [drm] Enabling audio support
        failed to evaluate ATIF got AE_BAD_PARAMETER
        [drm] Default TV standard: NTSC
        [drm] Radeon Display Connectors
        [drm] Connector 0:
        [drm]   VGA
        [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
        [drm]   Encoders:
        [drm]     CRT1: INTERNAL_KLDSCP_DAC1
        [drm] fb mappable at 0xD8040000
        [drm] vram apper at 0xD8000000
        [drm] size 4325376
        [drm] fb depth is 24
        [drm]    pitch is 5632
        fbcon: radeondrmfb (fb0) is primary device
        Console: switching to colour frame buffer device 170x48
        fb0: radeondrmfb frame buffer device
        drm: registered panic notifier
        Slow work thread pool: Starting up
        Slow work thread pool: Ready
        [drm] Initialized radeon 2.6.0 20080528 for 0000:01:05.0 on minor 0


By inspection of the code, it looks like the handle being passed into
radeon_atif_call() by radeon_acpi_init() may be bad.  I'm not sure why
that would be though.

I won't have time until Thursday to run it down any further.

Regards,
Andy

> Thanks,
> 
> Alex



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling
  2010-09-26 18:12                 ` Andy Walls
@ 2010-09-27 15:45                   ` Alex Deucher
  0 siblings, 0 replies; 24+ messages in thread
From: Alex Deucher @ 2010-09-27 15:45 UTC (permalink / raw)
  To: Andy Walls
  Cc: Jon Smirl, Rafał Miłecki, Dave Airlie,
	Greg Kroah-Hartman, linux-kernel, dri-devel

On Sun, Sep 26, 2010 at 2:12 PM, Andy Walls <awalls@md.metrocast.net> wrote:
> On Fri, 2010-09-24 at 15:12 -0400, Alex Deucher wrote:
>> On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> > On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
>> >> On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher <alexdeucher@gmail.com> wrote:
>> >> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@md.metrocast.net> wrote:
>> >> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >> >>> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> >> >>> > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
>> >> >>> >> 2010/9/20 Andy Walls <awalls@md.metrocast.net>:
>> >
>> >> >> The real problem to me is that the radeon and drm modules have a single,
>> >> >> standard way of dealing with EDID errors.  However, EDID errors can
>> >> >> happen due to a number of different causes, some of which are external
>> >> >> (i.e. in the LCD or CRT monitor).  Given that, there really is no "right
>> >> >> thing" the drivers can do without input from the user on what the policy
>> >> >> should be when a bad EDID is detected.
>> >>
>
>
>> The attached patch should fix up your board.  Let me know if it works for you.
>
> That patch suppresses the setup of the HDMI and DVI connectors that
> don't exist, so the log spam from polling for EDID's is gone for me.
>
>        [PATCH] drm/radeon/kms: add quirk for MSI K9A2GM motherboard
>
>        Board has no digital connectors
>
>        Reported-by: Andy Walls <awalls@md.metrocast.net>
>        Tested-by: Andy Walls <awalls@md.metrocast.net>
>        Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
>        Cc: stable@kernel.org
>

Thanks,  I've sent this to Dave.

>
> Yes it works for me, but it's what I'd call a "point solution".  There
> are still these which appear to be the exact same symptoms (perpetual
> EDID log spam) just for different hardware setups:
>
>        https://bugs.freedesktop.org/show_bug.cgi?id=27708
>        https://partner-bugzilla.redhat.com/show_bug.cgi?id=610362
>
>
> Here was a broader solution for a particular class of machines (Laptops
> with i915 chips with an LVDS with a broken EDID) exhibiting those same
> symptoms:
>
>        https://patchwork.kernel.org/patch/83556/
>
> Picking these bugs off one or two at a time, as users report the same
> symptoms over an over again, is really a waste of users' time.  Users
> wait while their report is queued, a custom kernel patch developed, and
> a kernel patch makes it through their distro to them.
>

These are two different issues.  The board needs a quirk to fix up the
bogus connectors regardless of the edid crap.  As to what to do about
the edid stuff, I'd personally prefer we just silence most of the
warnings or at least just warn once.  I think we are a bit too
pedantic about edid errors in general.  I think a good rule of thumb
would be to drop an edid if it doesn't have a valid header, but use it
if it's valid, but has something like a bad checksum or extension
block problems.

>
> On a different subject, with your patch applied, I'm now seeing a new
> error message in my log that I have not seen before:
>
>        failed to evaluate ATIF got AE_BAD_PARAMETER
>
> Here's the dmesg from drm:
>
>        [drm] Initialized drm 1.1.0 20060810
>        [drm] radeon defaulting to kernel modesetting.
>        [drm] radeon kernel modesetting enabled.
>        radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>        [drm] initializing kernel modesetting (RS740 0x1002:0x796E).
>        [drm] register mmio base: 0xFE7F0000
>        [drm] register mmio size: 65536
>        ATOM BIOS: ATI
>        radeon 0000:01:05.0: VRAM: 128M 0x78000000 - 0x7FFFFFFF (128M used)
>        radeon 0000:01:05.0: GTT: 512M 0x80000000 - 0x9FFFFFFF
>        [drm] radeon: irq initialized.
>        [drm] Detected VRAM RAM=128M, BAR=128M
>        [drm] RAM width 128bits DDR
>        [TTM] Zone  kernel: Available graphics memory: 963022 kiB.
>        [TTM] Initializing pool allocator.
>        [drm] radeon: 128M of VRAM memory ready
>        [drm] radeon: 512M of GTT memory ready.
>        [drm] GART: num cpu pages 131072, num gpu pages 131072
>        [drm] radeon: 1 quad pipes, 1 z pipes initialized.
>        [drm] Loading RS690/RS740 Microcode
>        [drm] radeon: ring at 0x0000000080000000
>        [drm] ring test succeeded in 1 usecs
>        [drm] radeon: ib pool ready.
>        [drm] ib test succeeded in 0 usecs
>        [drm] Enabling audio support
>        failed to evaluate ATIF got AE_BAD_PARAMETER
>        [drm] Default TV standard: NTSC
>        [drm] Radeon Display Connectors
>        [drm] Connector 0:
>        [drm]   VGA
>        [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c
>        [drm]   Encoders:
>        [drm]     CRT1: INTERNAL_KLDSCP_DAC1
>        [drm] fb mappable at 0xD8040000
>        [drm] vram apper at 0xD8000000
>        [drm] size 4325376
>        [drm] fb depth is 24
>        [drm]    pitch is 5632
>        fbcon: radeondrmfb (fb0) is primary device
>        Console: switching to colour frame buffer device 170x48
>        fb0: radeondrmfb frame buffer device
>        drm: registered panic notifier
>        Slow work thread pool: Starting up
>        Slow work thread pool: Ready
>        [drm] Initialized radeon 2.6.0 20080528 for 0000:01:05.0 on minor 0
>
>
> By inspection of the code, it looks like the handle being passed into
> radeon_atif_call() by radeon_acpi_init() may be bad.  I'm not sure why
> that would be though.
>
> I won't have time until Thursday to run it down any further.

Does your board actually have the ATIF method?  I think your board is
probably too old.  Newer kernels should only warn when the method is
present and there's an error.  The method really only exists on newer
laptops as far as I know.

Alex

>
> Regards,
> Andy
>
>> Thanks,
>>
>> Alex
>
>
>

^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2010-09-27 15:45 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-20 12:59 [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Andy Walls
2010-09-20 18:29 ` Rafał Miłecki
2010-09-20 23:02   ` Andy Walls
2010-09-21  4:26     ` Alex Deucher
2010-09-21 17:30       ` Andy Walls
2010-09-22  5:30         ` Alex Deucher
2010-09-22 12:31           ` Andy Walls
2010-09-22 20:16             ` Andy Walls
2010-09-22 13:33           ` Jon Smirl
2010-09-22 21:07             ` Andy Walls
2010-09-22 22:05               ` Jon Smirl
2010-09-24 19:12               ` Alex Deucher
2010-09-26 18:12                 ` Andy Walls
2010-09-27 15:45                   ` Alex Deucher
2010-09-22  3:20     ` [PATCH v2 0/2] " Andy Walls
2010-09-22  3:20     ` [PATCH v2 1/2] " Andy Walls
2010-09-22  3:20     ` [PATCH v2 2/2] Doc/ABI: sysfs-drm initial document; "polled" entry Andy Walls
2010-09-22 15:06       ` Greg KH
2010-09-22 16:36         ` Andy Walls
2010-09-22 19:23           ` Greg KH
2010-09-20 18:52 ` [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling Greg KH
2010-09-20 21:11   ` Andy Walls
2010-09-22  9:44     ` Florian Mickler
2010-09-22 12:49       ` Andy Walls

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).