[Bug 89008] [BYT] No HDMI hotplugging

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=89008

--- Comment #14 from Egbert Eich <eich at pdx.freedesktop.org> ---
(In reply to Ville Syrjala from comment #10)
> 
> 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

Right. I was in a rush and therefore reading the code wrong: the power domains 
are just a software concept to group the different subsystems onto the power
wells which is platform dependent.
It looks like the display2d power well on vlv is actually affecting all
subsystems. 

> 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).Therefore I was under the impression that HPD was not affected by runtime PM on these platforms. (On the other hand I didn't experiement with HPD too much on these).

Well, on other platforms you have a lot of subsystems 'always on'. On HSW and
BDW the display2d power well powers fewer subsystems.

> 
> 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.

Ok, this is still better than not having no HPD at all after disconnecting all
displays. For my use case no HPD would be unacceptible.

It looks a bit like a design flaw that you cannot power down the display part
without affecting HPD. On DVI/HDMI as well as on DP HPD signaling is done on
line that's separate to all other signaling lines on the PHY. It should be
possible power this subsystem separately.

> 
> 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.

Polling is still used as fallback with 10 sec interval in case of problems (HPD
storm) or if IRQ signalling is not supported by the chip. However signalling is
preferrable.

> 
> 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.

Frankly, I don't care about powering down the display engines at all.
The systems I care about are no phones nor tablets running on a skimpy little
battery. In the use cases I care about the displays need to go on when
connected.
I would be happy to get by without any runtime PM stuff in favor of yet more
complicated handling of HPD and wait with saving the planet from gobla warming
until the Intel hardware designer have come up with a less flawed HPD PM
solution.
> 
> 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 ;)

Currently the kernels I have to support don't support runtime PM, yet.
Eventually they will, though.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20150219/c20c68fa/attachment.html>