Hi Ander&Sivakumar, Dave&I had a short discussion about reprobing DP (and MST) state on resume. I think this is something we've missed in our dp hpd handling rework thus far. And at least for SST we need to take it into account since it would be a regression. Currently it's done through ->detect callback from drm_helper_hpd_irq_event called from i915_drm_resume. Also irc logs below. Thanks, Daniel <airlied> danvet: so probing on resume, it seems a bit inconsistent, is the kernel driver meant to be doing it? <airlied> I think since we stopped vt switching we've stopped doing it, which is making mst docking kinda suck <danvet> mst was after stopping vt-switching I thought <danvet> but yeah we should reprobe <danvet> and we do (at least occasionally if it's not broken again) <airlied> well people are just noticing it more with mst <danvet> but not for mst iirc <danvet> mst just restores and hopes I think <airlied> but when you suspend in the dock, and move the laptop, and resume things don't work unless you xrandr <airlied> and vice-versa <danvet> I looked into it for 5 minutes when tedtso complained an ran ;-) <airlied> well reproving should bring up/tear down any mst <danvet> hm, xrandr shouldn't be enough to fix it, we need a real hpd to redo the mst stuff I thought ... <airlied> so I don't think mst is special here <danvet> we reprobe through probe helpers <robclark> janesma, Pali, bleh sorry.. yeah, looks like it needs a stdbool.h.. not sure why I didn't hit that compile error.. sorry about that.. <danvet> all mst stuff is done directly from hpd since it needs to know long vs. short <danvet> so it misses out <airlied> if we probe a DP port and the device is gone, MST will get torn down <airlied> danvet: not so <airlied> unless someone else has been hacking the driver * xxmitsu (~mike@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) has joined #dri-devel <danvet> oh, the completely gone case * danvet looks <airlied> oh maybe we don't handle that properly <airlied> oh you might be right, I wonder where we should hook that in <danvet> drm_helper_hpd_irq_event in i915_drm_resume should get this right for non-mst <danvet> well non-DP maybe, anderco and rtshiva are reworking this <danvet> but it's not merged yet <airlied> I'm guessing detect should not if a port was in mst <airlied> and is now disconnected <danvet> ok, skeleton is there but not all <airlied> intel_dp_detect <danvet> drm_dp_mst_topology_mgr_resume should probably check the entire hierarchy, not just a simple dpcd write <danvet> and if anything changes, we need to generate the uevent somewhere <danvet> so might be better to re-run the entire dp_detect pile <danvet> tricky part is that we need to lie about long vs. short <danvet> it should be treated like a long hpd if anything changed, short otherwise <danvet> well we have mgr->cbs->hotplug in the mst manager already <danvet> so should reuse that hook <danvet> airlied, I guess just fix up drm_dp_mst_topology_mgr_resume to do rescan the entire hierarchy <danvet> calling ->hotplug if anything changed <danvet> and only returning true if the sink isn't mst any more <danvet> along the lines of what intel_dp_probe_mst does <danvet> it's not going to be all that simple ;-) <danvet> at least if you care about stuff like laptopt connected to dock -> screen <danvet> s/r <airlied> doesn't sounds like fun, I'll stick on my list of things to be scared off <danvet> then laptop only connected to dock <danvet> airlied, done the same <airlied> well the use case is laptop in dock, suspend, resume with laptop plugged into a monitor <danvet> but the fun part is that anderco/rtshiva want to rework this <danvet> and if they do they'll also break sst dp ;-) <danvet> so I think I have some victims <danvet> airlied, yeah that's step one <airlied> I'd prefer to get the fixes in before redesigning the tower <danvet> but that already has all the complexity on the driver side <danvet> only thing missing is the code in the mst helper to rescan the entire tree and call ->hot_plug if needed <danvet> problem is that current dp hpd handling is a mess already <danvet> it's hard to fix anything in there atm <danvet> so fixing this properly is needed anyway <danvet> it's just that I've forgotten about the resume case for plain DP myself ;-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
