> -----Original Message----- > From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] > Sent: Monday, June 30, 2014 6:45 PM > To: Wang, Quanxian > Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Daniel Vetter > Subject: RE: [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable > for valleyview platform. > > On Thu, 26 Jun 2014, "Wang, Quanxian" <quanxian.wang@xxxxxxxxx> wrote: > >> -----Original Message----- > >> From: Jani Nikula [mailto:jani.nikula@xxxxxxxxxxxxxxx] > >> Sent: Tuesday, June 24, 2014 11:58 PM > >> To: Wang, Quanxian > >> Cc: intel-gfx@xxxxxxxxxxxxxxxxxxxxx; Daniel Vetter > >> Subject: RE: [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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
