From: Eric Anholt <eric@anholt.net>
To: Andrew Lutomirski <luto@mit.edu>, intel-gfx@lists.freedesktop.org
Subject: Re: Fixing the hotplug storm bugs once and for all?
Date: Mon, 26 Jul 2010 10:41:41 -0700 [thread overview]
Message-ID: <87fwz63zu2.fsf@pollan.anholt.net> (raw)
In-Reply-To: <AANLkTin=WN_z5_STvkfG4KkD2wuJa=uFsXYxdL0MvnHZ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2258 bytes --]
On Sun, 25 Jul 2010 15:29:25 -0400, Andrew Lutomirski <luto@mit.edu> wrote:
> For well over a year now, I (and apparently lots of other people) have
> had to run patched kernels to avoid crippling hotplug storms.
>
> As far as I can tell, on my laptop, enabling DPC_HOTPLUG_INT_EN is
> safe, but setting either DPB_... or DPD_... (or both) will cause
> intermittent hotplug interrupt storms. (Turning off all three DP
> hotplug bits also makes the laptop stable but prevents the DP port
> from working.)
>
> My laptop is a Lenovo X200s with VGA and LVDS on the laptop itself and
> DP on the docking port. If I boot w/o the docking port, I have:
>
>
> General definitions block:
> CRT DDC GMBUS addr: 0x02
> Use ACPI DPMS CRT power states: no
> Skip CRT detect at boot: no
> Use DPMS on AIM devices: yes
> Boot display type: 0x0000
> TV data block present: yes
> Child device info:
> Device type: 1009 (TV)
> Signature:
> AIM offset: 0
> DVO port: 0x05
> Child device info:
> Device type: 1022 (LFP)
> Signature:
> AIM offset: 52048
> DVO port: 0x04
> Child device info:
> Device type: 68c6 (DisplayPort)
> Signature:
> AIM offset: 61152
> DVO port: 0x08
>
> Maybe it's time we started reading that part of VBIOS to detect which
> outputs really exist. (If that's unsafe, we could add a DMI list.)
>
> Any thoughts? It would be nice if 2.6.36 could work without patches.
We had patches to not probe outputs unless they were in child dev tables
for a while. The issue with reading child dev tables is that some
BIOSes would give you different child dev results depending on whether
you were docked or not, so you wouldn't get your DP probed unless you
booted docked.
Now, I'm sure there's a way to detect dock events, and if we then
reprobed and reconfigured hotplug and output->detect() probing based on
child devs, we should get no hotplug storms, reduced boot time, and
lower power consumption. Everyone would be happy, right?
[-- Attachment #1.2: Type: application/pgp-signature, Size: 197 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2010-07-26 17:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-25 19:29 Fixing the hotplug storm bugs once and for all? Andrew Lutomirski
2010-07-26 17:41 ` Eric Anholt [this message]
2010-07-26 18:06 ` Andrew Lutomirski
2010-07-26 18:45 ` Eric Anholt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fwz63zu2.fsf@pollan.anholt.net \
--to=eric@anholt.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=luto@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.