On Fri, Dec 04, 2009 at 06:14:24PM -0500, Alex Deucher wrote: > On Fri, Dec 4, 2009 at 5:58 PM, Luc Verhaegen <l...@skynet.be> wrote: > > On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote: > >> This set of patches adds interrupt driven HPD (Hot Plug Detect) > >> support to r1xx-r7xx radeons. Assuming the HPD pin is wired up > >> correctly, the driver will generate uevents for digital monitor > >> connect and disconnect and will retrain DP monitors automatically. > >> The pin sense functionality can also be used to differentiate between > >> multiple monitors connected to the same encoder or sharing a ddc line, > >> however, that has not been hooked up yet. > >> > >> Alex > > > > Wasn't HPD evil for some reason a few years back? I remember you, > > bridgie and davey throwing tons of crap at radeonhd for using HPD, and > > here you are hooking it up to the same r5xx hardware, even though you > > seem to prefer to name the hooks rs600. > > > > What is so different now then? > > Nothing is different. You wanted to use them directly for monitor > detection, but prior to r6xx, they shouldn't be used as the sole means > of detecting if a monitor is connected or not since they were not > always wired up properly by the oems. That's why radeonhd won't fail > to start up for some people and then you'd make them run conntest and > sort out the hpd routing. As I said back then, you shouldn't use the > hpd pins directly for detection on pre-r6xx cards. The drm doesn't > use them directly for monitor detection, it still uses the edid, as I > advised you back then. The drm uses them to generate interrupts on > hpd connect/disconnect events. The drm then issues a uevent that > userspace can listen for and act on. Other than displayport (which is > r6xx+ only), it doesn't matter if the hpd routing is correct or not > since all we use it for is to generate an interrupt that something has > changed. Userspace can then use the event to probe the connectors, or > whatever. > > Alex
HPD was not tested for one reason and one reason only, no information on this DDWG required feature was made available by the relevant atombios tables. Add a lack of load detection (because monitors are not required to provide load on the lines, or because the output simply didn't implement detection for it (LVTMA)), and that ddc isn't always reliable either (not all monitors use the 5V the connector provides to still provide DDC), and that both of those are much more involved and timeconsuming, then it should be clear that HPD, when available, is massively important information. Even on r500 it is vastly more reliable than the other means. Now, the hardware implements it, atombios ignores it, but HPD correctness was actually not that bad. There are 14 entries in the quirks table where either the hpd lines get swapped compared to the default (8) or are disabled (6, although i guess that some of these could've gotten swapped too) for r500. While i do not pretend that this is a complete and definitive result; when you compare that with how long the r5xx was sold commercially and how many vastly different boards were made; then that's pretty bloody good default. And guess what, connector info for newer cards, even though their atombios tables did list HPD pins, and everything was supposed to be tested soo well, is not always correct either. But as long as you stick to your case religiously, then we are certain that all that crap was thrown justifiedly, even though connection detection always had to be some algorithm combining all available information, an algorithm that at most takes up a hundred or so lines. On the other hand, a hundred lines or so is a lot when an r500 was going to be implemented in 1000-1500 lines originally. Luc Verhaegen. ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
