| Summary: | [RADEON:KMS:RV530M:MUX] HDMI-A-1 Does not work after resume (But claims it does) | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Russ Dill <Russ.Dill> | ||||||||||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | medium | CC: | christopher.m.penalver | ||||||||||||||||
| Version: | unspecified | ||||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||||
| Whiteboard: | |||||||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Russ Dill
2011-01-11 22:23:19 UTC
Please attach your xorg log and dmesg output. Created attachment 41999 [details]
dmesg
I originally thought this had to do with being connected at powerup, but it really has to do with it breaking after powerup. The attached dmesg and xorg.log is from:
powerup laptop with no external displays connected
plug laptop into docking station. LVDS-1 turns off, HDMI-A-1 and VGA-1 turn on
suspend laptop
wake laptop, VGA-1 turns on, HDMI-A-1 does not
Created attachment 42000 [details] [review] Xorg.0.log Does the LVDS come on when you resume? X may be getting confused and enabling the wrong displays on resume (LVDS+VGA rather than VGA+HDMI) since all are attached. Can you manually reconfigure things using xrandr after resume? xrandr shows LVDS as being off and HDMI as being on. Manually fussing with xrandr doesn't change anything, but I can turn the LVDS display on and off. However, if I try to turn all three displays on at a time, X segfaults (or at least the last time I tried it did). (In reply to comment #5) > xrandr shows LVDS as being off and HDMI as being on. Manually fussing with > xrandr doesn't change anything, but I can turn the LVDS display on and off. > However, if I try to turn all three displays on at a time, X segfaults (or at > least the last time I tried it did). Can you attach the output of 'xrandr --verbose' before and after resume? Also, if you get a segfault, can you get a backtrace and attach it here? Created attachment 42508 [details]
xrandr --verbose (before suspend)
Created attachment 42509 [details]
xrandr --verbose (after resume)
The xorg crashing thing is no longer true, its been fixed at some point. gnome-display-properties still gets confused and thinks it successfully configured all three, but there is no crash. (and closing and re-opening gnome-display-properties changes it back to only showing two displays enabled. Does a dpms cycle help? xset dpms force off Does restarting X help? How about forcing a mode change? e.g., xrandr --output HDMI-0 --mode 1680x1050 > Does a dpms cycle help? > xset dpms force off Nope (but causes the VGA-0 monitor to flash off and on) > Does restarting X help? Nope > How about forcing a mode change? e.g., > xrandr --output HDMI-0 --mode 1680x1050 Nope Can you dump the following regs with avivotool (available here: http://cgit.freedesktop.org/~airlied/radeontool/) as root before and after suspend? avivotool regmatch <reg> Where <reg> = 0x7880 0x7884 0x7888 0x788c 0x7890 0x7894 0x7898 0x789c 0x78a0 0x78a4 0x78a8 0x78ac 0x78b0 0x78b4 0x78b8 0x78bc 0x78c0 0x78c4 0x78c8 0x78cc 0x78d0 0x78d4 0x78d8 0x78dc 0x78e0 0x7904 0x7908 0x790c 0x7910 0x7914 0x7918 0x791c Created attachment 42572 [details]
avivotool regmatch <0x7880..0x791c> (before suspend)
Created attachment 42573 [details]
avivotool regmatch <0x7880..0x791c> (after resume)
Both files are identical
So there is a DVI port on the dock and an hdmi port on the laptop. It's likely they share the same encoder and there may some gpio magic involved in switching between them. I don't see any router info in the vbios, so it's likely to be a system specific thing. Maybe some acpi method? When the hdmi port isn't working, does the DVI port work or vice versa? Just a few followups. It doesn't seem to be related to the docking station switching. The problem occurs even without the docking port. Additionally, if I plug an HDMI cable into the laptop while the docking station is plugged in, the monitor is not detected at all. Where-as after I resume and have a problem, the monitor is detected, it just doesn't get sync. So the docking station switching disables the port "more" than the resume problem. - radeon.modeset=0 displays the same problem - vista-x32 works correctly (In reply to comment #16) > Just a few followups. It doesn't seem to be related to the docking station > switching. The problem occurs even without the docking port. > > Additionally, if I plug an HDMI cable into the laptop while the docking station > is plugged in, the monitor is not detected at all. Where-as after I resume and > have a problem, the monitor is detected, it just doesn't get sync. So the > docking station switching disables the port "more" than the resume problem. This is consistent with the gpio controlled data and ddc routing that I suspect is happening. There's probably a small mux which routes the ddc/hdp lines (for detection and edid) and the data lines (for the actual video signal) between the HDMI port on the laptop and the DVI port on the docking station. When you dock, the acpi docking method probably calls some other method which switches the mux to the other connector. The same thing probably happens on undock. The question is, is this handled by an acpi method or some platform specific gpio/i2c setup. Newer radeon-based laptops that use a mux like this have a special entry in the vbios object table that describes the mux. Unfortunately, your system doesn't have this, so it's probably some system-specific configuration. When you suspend, the mux loses power and goes into some undefined state on resume the signals are not routed correctly since the mux state is wrong. Just some notes: Power: Maxim MAX1999 Quad-ouput main power supply controller Maxim MAX8774GTL+ main power supply controller Semtech SC470 synchronous buck controller Semtech SC488 complete DDR memory power supply Nat Semi LM393 dual comparators. Chipset: ATI IXP460 SB460 ATI XPRESS RX485 ATX X1600 Broadcom BCM5788 MKFBG Netlink gigabit Ethernet controller with phy ICS ICS951462AGLF Programmable system clock chip for ATI RS/RD690 - K8 based systems Cypress CY25819 spread spectrum clock generator Super IO: Nat Semi PC87541V-VPC (Seems to be PC87591) LPC Mobile Embedded Controller Nat Semi PC87383-VS Legacy reduced super I/O Video: TI TS3DV520 5-Channel differential 10:20 multiplexer switch for DVI/HDMI applications (Single pin SEL signal) (x2) California Micro Devices CM1213 4-channel low capacitance ESD protection arrays California Micro Devices CM2009 VGA port companion circuit Silicon Image Sil1930CMU TDMS ParallelLink uC: Atmel AT89C51ICS-VL 8-bit flash microcontroller with 2-wire interface Misc: TI SN74CBT3257 4-bit 1-of-2 FET multiplexer/demultiplexer (I2C?) Maxim MAX3892 10/100/1000 base-T ethernet LAN switch Global Mixed-mode Technology Inc G528 USB high-side switch Microchip 24LC08BI 8K I2C serial EEPROM Toshiba 7W125 dual bus buffer Audio: Realtek ALC833 Value 7.1+2 HD audio codec AKM AK4113VF 192kHz 24bit DIR with 6:1 selector Maxim 9710E 3W Mono/Steria BTL audio power amps Created attachment 43178 [details]
DSDT
Russ Dill, Ubuntu Natty Narwhal reached EOL on October 28, 2012. For more on this, please see https://wiki.ubuntu.com/Releases. If this is reproducible with a supported release, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal: ubuntu-bug xorg Also, please feel free to subscribe me to it. For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.