[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: Monday, June 30, 2014 6:45 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.
> 
> On Thu, 26 Jun 2014, "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> >> -----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.
> 
> Huh, if you disconnect the sink device from branch device, SINK_COUNT is
> expected to be 0, and the result is expected to be disconnected, right?!
[Wang, Quanxian] No, I don't disconnect the sink device physically. Kernel will receive the dpms signal when branch device think monitor is in sleep status(The screen turns to black after a while). But it is still connected. Kernel still could get the DDC data by calling drm_probe_ddc and also kernel still could get EDID data. From DP protocol, SINK_COUNT is 0 and it doesn't show the real status of branch device at that time.
That is why I think SINK_COUNT isn't reliable. With this patch, when I press any key, monitor will turn to be active from sleep status. Without it, any action on key or mouse could not active monitor after its sleep.
> 
> BR,
> Jani.
> 
> 
> > 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],
> >
> >
> >
> 
> --
> Jani Nikula, Intel Open Source Technology Center