On Wed, Jan 7, 2015 at 6:07 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Tue, Jan 6, 2015 at 10:21 PM, Robert Morell rmorell@nvidia.com wrote:
FWIW, I've seen that exact symptom on some monitors when the +5V pin on the DVI or HDMI cable from the GPU isn't enabled (or isn't providing enough current). Some monitors power the i2c/edid/DDC logic from that +5V either exclusively or when in the DPMS off state, and the i2c chip will just stop responding after a few cycles if not provided sufficient power.
That makes a ton of sense, especially the "when in DPMS off state" case.
I'll do the drm.debug=0xe thing, and maybe Daniel can make more sense of the details. Maybe the i2c driver ends up powering down too soon (or maybe it needs to power up a bit earlier)?
This is a bog-standard intel motherboard (DH87RL), but I actually needed to update the BIOS for it to get it to POST reliably with this monitor. I was blaming that on the odd 3840x2160@30Hz mode, but maybe it's related to the EDID being finicky wrt i2c power.
I'm assuming even the hdmi +5V line is under sw control at least for power management reasons. Maybe dpms off turns it off, and shouldn't? My monitor actually says "No HDMI (HML) Cable" when I do "xset dpms force off". Maybe that's normal, but maybe that's indicative of dpms turning things a bit *too* off?
Not sure whether that'd be the same voltage rails, but i915.disable_power_wells=0 disable all the runtime pm we do (which does kick in for dpms off and shut down the entire display block and a bunch more). Maybe we just need to detect that the chip dropped off the bus and retry after 50ms (to give the caps some time to charge). -Daniel