Date:	Wed, 22 Sep 2010 18:05:12 -0400
From:	Jon Smirl <jonsmirl@...il.com>
To:	Andy Walls <awalls@...metrocast.net>
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, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@...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@...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:

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@...il.com
--
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