On Mon, Sep 14, 2015 at 02:44:01PM +0530, Jindal, Sonika wrote: > > > On 9/14/2015 2:12 PM, Daniel Vetter wrote: > >On Fri, Sep 11, 2015 at 05:56:47PM +0000, Rodrigo Vivi wrote: > >>Thanks > >> > >>Reviewed-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > >> > >> > >>On Fri, Sep 11, 2015 at 4:38 AM Sonika Jindal <sonika.jindal@xxxxxxxxx> > >>wrote: > >> > >>>The Bspec is very clear that Live status must be checked about before > >>>trying to read EDID over DDC channel. This patch makes sure that HDMI > >>>EDID is read only when live status is up. > >>> > >>>The live status doesn't seem to perform very consistent across various > >>>platforms when tested with different monitors. The reason behind that is > >>>some monitors are late to provide right voltage to set live_status up. > >>>So, after getting the interrupt, for a small duration, live status reg > >>>fluctuates, and then settles down showing the correct staus. > >>> > >>>This is explained here in, in a rough way: > >>>HPD line ________________ > >>> |\ T1 = Monitor Hotplug causing IRQ > >>> | \______________________________________ > >>> | | > >>> | | > >>> | | T2 = Live status is stable > >>> | | _____________________________________ > >>> | | /| > >>>Live status _____________|_|/ | > >>> | | | > >>> | | | > >>> | | | > >>> T0 T1 T2 > >>> > >>>(Between T1 and T2 Live status fluctuates or can be even low, depending on > >>> the monitor) > >>> > >>>After several experiments, we have concluded that a max delay > >>>of 30ms is enough to allow the live status to settle down with > >>>most of the monitors. This total delay of 30ms has been split into > >>>a resolution of 3 retries of 10ms each, for the better cases. > >>> > >>>This delay is kept at 30ms, keeping in consideration that, HDCP compliance > >>>expect the HPD handler to respond a plug out in 100ms, by disabling port. > >>> > >>>v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions > >>>to check digital port status. Adding a separate function to get bxt live > >>>status (Daniel) > >>>v3: Using intel_encoder->hpd_pin to check the live status (Siva) > >>>Moving the live status read to intel_hdmi_probe and passing parameter > >>>to read/not to read the edid. (me) > >>>v4: > >>>* Added live status check for all platforms using > >>>intel_digital_port_connected. > >>>* Rebased on top of Jani's DP cleanup series > >>>* Some monitors take time in setting the live status. So retry for few > >>>times if this is a connect HPD > >>>v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob > >>> which was missed. > >>>v6: Drop the (!detect_edid && !live_status check) check because for DDI > >>>ports which are enumerated as hdmi as well as DP, we don't have a > >>>mechanism to differentiate between DP and hdmi inside the encoder's > >>>hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well > >>>as hdmi which leads to issues during unplug because of the above check. > >>>v7: Make intel_digital_port_connected global in this patch, some > >>>reformatting of while loop, adding a print when live status is not > >>>up. (Rodrigo) > >>> > >>>Signed-off-by: Shashank Sharma <shashank.sharma@xxxxxxxxx> > >>>Signed-off-by: Sonika Jindal <sonika.jindal@xxxxxxxxx> > > > >Since this is tricky stuff and other patches in this series are blocked > >until we have a clearer picture can you please rebase this to be the first > >patch on top of -nightly so that I can pull it in directly? > > > >I tried to do that but proved a bit too messy. > >-Daniel > > > Hmm, since rebasing this will require these changes (check for live status) > to go in detect and then later when we reach a conclusion on > hot_plug hook, we would need to move it to that function. > I think lets wait for the conclusion on the placement of that function. > What do you suggest? I think given how tricky this patch here is with testing it's preferably to get it int as soon as possible. Yes that means shuffling things around twice. But since the structure of how we'll handle hpd isn't clear yet at all there's a really high chance that you need to rework this patch anyway. So I don't expect doing this rebase right now will be more work. And it will give us better testing coverage, which is always good to have. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
