[Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.

[Wang, Quanxian]

> -----Original Message-----
> From: Jani Nikula [mailto:jani.nikula at linux.intel.com]
> Sent: Tuesday, June 24, 2014 11:58 PM
> To: Wang, Quanxian
> Cc: intel-gfx at lists.freedesktop.org; Daniel Vetter
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
> for valleyview platform.
> 
> >> Per DP spec we need to read the SINK_COUNT. Perhaps your problem is
> >> the hotplug irqs?
> > [Wang, Quanxian] Hi, Jani
> > The log event is about the transaction event instead of hotplug event. It is
> general since they will use I2c to read byte one by one. It will generate many
> transaction.
> >
> > But the root cause is really about hotplug(intel_hpd_irq_handler). When
> we switch to console, there will be a hotplug event happens after a while.
> After that, the system will continually get the hotplug event to switch sink
> device on and off periodly.  With DisplayPort 1.2 spec, '' This bit is used for
> either monitor hotplug/unplug or for notification of a sink event.", I am not
> sure if it is notification of  a sink event or real hotplug event. We have no
> code to identify the difference between hotplug/unplug  and notification of
> a sink event. I check display port spec and also not found how to identify
> them differently.
> >
> > Question is:
> > In function intel_dp_detect_dpcd, before checking SINK_COUNT, we will
> use intel_dp_get_dpcd to get the dpcd. Could we think there is an active sink
> device attached to branch device if dpcd content is not null.
> > According to the display port spec, only sink device has dpcd, if we get one,
> there must be a sink device attached to branch device or source device. Right?
> 
> No. From your logs, the DPCD has bit 0 set in address 5h, which means
> downstream port present, which is only allowed in branch devices.
[Wang, Quanxian] Ok. Currently I have some founds.  

Sink device attached to branch device will be idle without operation after a while. And kernel will
get the 'fake dpms off' event and called intel_encoder_dpms to disable the connector and dp link will be disabled(See the 1st line of log list below, intel_encoder_dpms will be called with DPMS off). At that time, kernel thought connector had no any sink device attached when SINK_COUNT return 0. Status will be changed from connected to disconnected. Encoder will be deleted after that. Whatever for console terminal or other apps which depends on connector will not work. In this case, The system is in black status even if you press any key or others. From ssh terminal, we could find kernel gets hpd event continually, however at that time, encoder is deleted, connector is not be restored. Always get '[CRTC:6] [NOFB ]'.

So SINK_COUNT is not the only way to check the alive status for connector. If we got one or more, we can confirm that connector is alive. However if we get 0, we should not say connector is not alive. We should try another way to make sure if it is alive. 

I have tried with DDC checking if SINK_COUNT is 0. It works for DP with branch device. But if disconnect the sink device from Branch device, it will not work.
So I *plan*: 
1) when we get SINK_COUNT to be 0, don't return disconnected. We will continue to check DDC.
2) or firstly check OUI to make sure if there is branch device, if there is, then check DDC if SINK_COUNT is 0.

Any suggestion for this process?

[ 1334.170715] [drm:intel_encoder_dpms], mode:3
[ 1334.170721] [drm:intel_crtc_update_dpms],
[ 1334.170726] [drm:i9xx_crtc_disable],
[ 1334.170730] [drm:intel_disable_dp],
[ 1334.170735] [drm:intel_dp_aux_native_write],
[ 1334.170741] [drm:intel_dp_aux_native_write], retry 0
[ 1334.201477] [drm:intel_post_disable_dp],
[ 1334.201483] [drm:intel_dp_link_down],
[ 1334.253549] [drm:g4x_wait_for_vblank], vblank wait timed out
[ 1334.256743] [drm:valleyview_update_wm], Setting FIFO watermarks - A: plane=2, cursor=2, B: plane=2, cursor=2, SR: plane=0, cursor=0
[ 1334.256761] [drm:check_encoder_state], [ENCODER:10:DAC-10]
[ 1334.256769] [drm:check_encoder_state], [ENCODER:11:TMDS-11]
[ 1334.256777] [drm:check_encoder_state], [ENCODER:15:TMDS-15]
[ 1334.256784] [drm:check_crtc_state], [CRTC:3]
[ 1334.256791] [drm:check_crtc_state], [CRTC:6]
[ 1340.097288] [drm:valleyview_irq_handler], hotplug event happens 0x20020000 & 0x007e08c0???
[ 1340.097311] [drm:intel_hpd_irq_handler], Received HPD interrupt on PIN 4 - cnt: 0
[ 1340.097417] [drm:i915_hotplug_work_func], running encoder hotplug functions
[ 1340.097436] [drm:i915_hotplug_work_func], Connector HDMI-A-1 (pin 4) received hotplug event.
[ 1340.097450] [drm:i915_hotplug_work_func], Connector DP-1 (pin 4) received hotplug event.
[ 1340.097464] [drm:intel_hdmi_detect], [CONNECTOR:12:HDMI-A-1]
[ 1340.104895] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus dpb
[ 1340.104913] [drm:intel_dp_detect], [CONNECTOR:16:DP-1]
[ 1340.104925] [drm:intel_dp_detect_dpcd], Get dpcd
[ 1340.105757] [drm:intel_dp_aux_native_read], aux_ch read and got 15 bytes
[ 1340.105772] [drm:intel_dp_aux_native_read_retry], expected 15, and get 15
[ 1340.105785] [drm:intel_dp_get_dpcd], DPCD: 11 0a 82 01 01 15 01 81 00 01 04 01 0f 00 00
[ 1340.106330] [drm:intel_dp_aux_native_read], aux_ch read and got 16 bytes
[ 1340.106345] [drm:intel_dp_aux_native_read_retry], expected 16, and get 16
[ 1340.106355] [drm:intel_dp_detect_dpcd], Check dpcd
[ 1340.106365] [drm:intel_dp_detect_dpcd], get aux_native reg
[ 1340.106772] [drm:intel_dp_aux_native_read], aux_ch read and got 1 bytes
[ 1340.106786] [drm:intel_dp_aux_native_read_retry], expected 1, and get 1
[ 1340.106798] [drm:intel_dp_detect_dpcd], Check SINK_COUNT reg:0x0, 0
[ 1340.106814] [drm:intel_hpd_irq_event], [CONNECTOR:16:DP-1] status updated from connected to disconnected
[ 1340.108038] [drm:drm_fb_helper_hotplug_event],