Re: [PATCH] drm/sysfs: Provide per connector control of DRM KMS polling

[Alex Deucher]

On Sun, Sep 26, 2010 at 2:12 PM, Andy Walls <awalls@xxxxxxxxxxxxxxxx> 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@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.
>> >>
>
>
>> 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@xxxxxxxxxxxxxxxx>
> Â Â Â ÂTested-by: Andy Walls <awalls@xxxxxxxxxxxxxxxx>
> Â Â Â ÂSigned-off-by: Alex Deucher <alexdeucher@xxxxxxxxx>
> Â Â Â ÂCc: stable@xxxxxxxxxx
>

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