Message-ID: <1285189645.14364.55.camel@morgan.silverblock.net>
Date:	Wed, 22 Sep 2010 17:07:25 -0400
From:	Andy Walls <awalls@...metrocast.net>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	Alex Deucher <alexdeucher@...il.com>,
	Rafał Miłecki <zajec5@...il.com>,
	Dave Airlie <airlied@...hat.com>,
	Greg Kroah-Hartman <greg@...ah.com>,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS
 polling

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists