On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote:
>> > On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> wrote:
>> >> On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
>> >>> 2010/9/20 Andy Walls <awalls@xxxxxxxxxxxxxxxx>:
>> >>> > On Mon, 2010-09-20 at 20:29 +0200, RafaÅ MiÅecki wrote:
>> >>> >> 2010/9/20 Andy Walls <awalls@xxxxxxxxxxxxxxxx>:
>
>> >> 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
>
>
From 0031a6b077a8f81ed680e2c1dc66bdde73dda72b Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexdeucher@xxxxxxxxx>
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@xxxxxxxxxxxxxxxx>
Signed-off-by: Alex Deucher <alexdeucher@xxxxxxxxx>
Cc: stable@xxxxxxxxxx
---
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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
