<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT] No HDMI hotplugging" href="https://bugs.freedesktop.org/show_bug.cgi?id=89008#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BYT] No HDMI hotplugging" href="https://bugs.freedesktop.org/show_bug.cgi?id=89008">bug 89008</a> from <a class="email" href="mailto:ville.syrjala@linux.intel.com" title="Ville Syrjala <ville.syrjala@linux.intel.com>"> Ville Syrjala</a> <pre>(In reply to Egbert Eich from <a href="show_bug.cgi?id=89008#c9">comment #9</a>) > (In reply to Jani Nikula from <a href="show_bug.cgi?id=89008#c8">comment #8</a>) > > Ville on #intel-gfx: > > > > 22:40 vsyrjala j4ni: hotplug needs disp2d well on byt. if there > > are > > no active display we turn off the power well. also > > most display regs are in the power well which > > explains > > the 0xffffffff > > Indeed, I was able to bisect this back to commit > 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1. > > This begs the question if the disp2d power wells need to be disabled quite > as aggressively: maybe there is only a subset needed for hotplug which can > stay enabled. > The same is true for the display interrupts: HPD may be one of them. > > I do understand that it is important to power down the chip as much as > possible whenever feasable for ultra mobile use cases. However a lot of > Baytrail chips are used in TCs or other desktop like devices which are > connected to the mains - at least my system with 8086:0f31 is. Sadly there's no sub-partitioning of the power well, so it's either all or nothing. Also we may even further runtime suspend the entire device. That means we should actually have the same problem on all platforms supporting runtime PM. I suppose the only thing that saves most other platforms is the default 10s delay on runtime susped we have (which we really should reduce to something like 1s). So at the moment i915.disable_power_well=0 is the only way to guarantee that HPD keeps working at all times, but that will keep all the power wells on (assuming the platform has any), as well as disable runtime PM of course. Anyway there are two solutions that have been considered: polling and GPIO interrupts Polling should be fairly easy to do I suppose, but it itself wastes power, and to minimize that you need to not poll too often which may still give you an uncomfortably long delay until the display lights up. Although maybe a long delay is better than an infinite delay. Just has to short enough by default so that most users wouldn't go yank out the cable again to blow away the dust and whatnot thinking it didn't work. The nice thing about polling is that it's a platform independent solution. The GPIO approach would involve changing the pin muxing depending on the state of the power well (or maybe leave them as GPIO pins all the time?). I can't recall if Imre actually tried this approach, but I do recall we discussed it a few time when he was adding the BYT power well stuff. The bad thing is that it's a very platform specific solution. I believe we should be able to do it on BYT/CHV, but probably not on other platforms. I guess one idea would be to implement both. Use GPIO when available to minimize power consumption (BYT/CHV are the low power platforms anyway), and fall back to polling otherwise. I seem to recall that some upcoming platforms might have a bit better support for HPD while otherwise powered down, but could be I just dreamed it. I don't think anyone is really opposed to solving this, just there are plenty of higher priority things to do. And if someone could come up with some great plan D that has no downsides that would be great ;)</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>