On Mon, 23 Jun 2014, "Wang, Quanxian" <quanxian.w...@intel.com> wrote: >> -----Original Message----- >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> Sent: Tuesday, June 17, 2014 11:38 PM >> To: Wang, Quanxian >> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable >> for valleyview platform. >> >> On Tue, 17 Jun 2014, "Wang, Quanxian" <quanxian.w...@intel.com> wrote: >> > File dmesg_normal_20140617.log will contain dmesg log when boot the >> > machine and start weston. (Previous is overwrite, but it is enough for >> graphics boot message) File dmesg_error_20140617.log contains dmesg log >> after Weston exit when it found no connector available. >> > >> > I disable log for hotplug event from valleyview_irq_handler. There are so >> many. Maybe you can find some private debug log. Don't need to care that. >> >> 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. BR, Jani. > >> >> BR, >> Jani. >> >> >> >> > >> > Thanks >> > >> > Regards >> > >> > Quanxian Wang >> > >> > >> >> -----Original Message----- >> >> From: Wang, Quanxian >> >> Sent: Tuesday, June 17, 2014 10:14 AM >> >> To: 'Jani Nikula' >> >> Cc: intel-gfx@lists.freedesktop.org; Daniel Vetter >> >> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not >> >> reliable for valleyview platform. >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >> > Sent: Monday, June 16, 2014 4:18 PM >> >> > To: Wang, Quanxian; Daniel Vetter >> >> > Cc: intel-gfx@lists.freedesktop.org >> >> > Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not >> >> > reliable for valleyview platform. >> >> > >> >> > On Mon, 16 Jun 2014, "Wang, Quanxian" <quanxian.w...@intel.com> >> >> wrote: >> >> > >> -----Original Message----- >> >> > >> From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >> > >> Sent: Friday, June 13, 2014 5:12 PM >> >> > >> To: Daniel Vetter; Wang, Quanxian >> >> > >> Cc: intel-gfx@lists.freedesktop.org >> >> > >> Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is >> >> > >> not reliable for valleyview platform. >> >> > >> >> >> > >> On Fri, 13 Jun 2014, Daniel Vetter <dan...@ffwll.ch> wrote: >> >> > >> > On Fri, Jun 13, 2014 at 02:52:04PM +0800, Quanxian Wang wrote: >> >> > >> >> DP connector will be disconnected after chvt to another >> >> > >> >> console for >> >> > >> >> 10 minutes or more on valleyview platform VTC1010. >> >> > >> > >> >> > >> > This needs _much_ more detail, really. >> >> > >> > >> >> > >> > Also it smells like we work around a sink issue, which means >> >> > >> > the correct quirk is to use some sink id (like OUI), _not_ the >> platform. >> >> > >> > Since this way you break all DP1.1+ stuff on vlv and if >> >> > >> > someone puts this panel onto a different platform it still doesn't >> work. >> >> > >> >> >> > >> Furthermore you should end up in this code path *only* if you >> >> > >> have a DP branch device. This shouldn't happen for eDP or native >> >> > >> DP displays. Please confirm what kind of setup you're >> >> > >> experiencing issues >> >> > with. >> >> > >> >> >> > >> Frankly I wouldn't be surpised if we do have issues with branch >> >> > >> devices, but this is not the fix. >> >> > > [Wang, Quanxian] Any idea how to do it? Currently in VTC1010 >> >> > > device, we use native DP to connect HDMI monitor.(DP2HDMI) This >> >> > > case will >> >> > happen. >> >> > >> >> > So it's an active adapter? >> >> [Wang, Quanxian] yes. >> >> > >> >> > Please send full dmesg from early booth with drm.debug=0xe module >> >> > parameter set, exhibiting the problem. >> >> [Wang, Quanxian] I will send the dmesg log soon. If open >> >> drm.debug=0xe, irq log will overwrite all the dmesg output. I will >> >> have some change to get the complete log for you. Just wait for a while. >> >> >> >> After checking with hardware spec, I have some comment for registers >> >> of Display Port In i915_reg.h, I found we use PCB_DP_x(address >> >> 0xe4100+??, control, data...) to do the communication and check what the >> SINK_COUNT. >> >> (I found it was defined in Ivybridge spec 2012) The process focus on >> >> South Display Engine to do the communication. >> >> But in valleyview spec(2014), I don't find 0xe4110, and only >> >> 0x64100+xxx for north display engine are available. (DPx_AUX_CH_CTL >> >> series defined in >> >> i915_reg.h) >> >> >> >> Question: Is the something changed for that after valleyview or >> >> haswell(2013-2014)? >> >> >> >> Thanks >> >> > >> >> > BR, >> >> > Jani. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >> > >> >> >> > >> BR, >> >> > >> Jani. >> >> > >> >> >> > >> >> >> > >> > >> >> > >> > Or I completely don't understand this at all. >> >> > >> > >> >> > >> > Also, such a patch needs a full spec quote or a w/a citation >> >> > >> > or something solid if it's a more generic issue. >> >> > >> > -Daniel >> >> > >> >> >> >> > >> >> Signed-off-by: Quanxian Wang <quanxian.w...@intel.com> >> >> > >> >> --- >> >> > >> >> drivers/gpu/drm/i915/intel_dp.c | 4 +++- >> >> > >> >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> > >> >> >> >> > >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> >> > >> >> b/drivers/gpu/drm/i915/intel_dp.c index 2688f6d..0d127a5 >> >> > >> >> 100644 >> >> > >> >> --- a/drivers/gpu/drm/i915/intel_dp.c >> >> > >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> >> > >> >> @@ -2942,6 +2942,7 @@ intel_dp_check_link_status(struct >> >> > >> >> intel_dp >> >> > >> >> *intel_dp) static enum drm_connector_status >> >> > >> >> intel_dp_detect_dpcd(struct intel_dp *intel_dp) { >> >> > >> >> + struct drm_device *dev = intel_dp_to_dev(intel_dp); >> >> > >> >> uint8_t *dpcd = intel_dp->dpcd; >> >> > >> >> uint8_t type; >> >> > >> >> >> >> > >> >> @@ -2953,7 +2954,8 @@ intel_dp_detect_dpcd(struct intel_dp >> >> > *intel_dp) >> >> > >> >> return connector_status_connected; >> >> > >> >> >> >> > >> >> /* If we're HPD-aware, SINK_COUNT changes dynamically */ >> >> > >> >> - if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 && >> >> > >> >> + if (!IS_VALLEYVIEW(dev) && >> >> > >> >> + intel_dp->dpcd[DP_DPCD_REV] >= 0x11 && >> >> > >> >> intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) { >> >> > >> >> uint8_t reg; >> >> > >> >> if (!intel_dp_aux_native_read_retry(intel_dp, >> >> > >> DP_SINK_COUNT, >> >> > >> >> -- >> >> > >> >> 1.8.1.2 >> >> > >> >> >> >> > >> >> _______________________________________________ >> >> > >> >> Intel-gfx mailing list >> >> > >> >> Intel-gfx@lists.freedesktop.org >> >> > >> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> > >> > >> >> > >> > -- >> >> > >> > Daniel Vetter >> >> > >> > Software Engineer, Intel Corporation >> >> > >> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch >> >> > >> > _______________________________________________ >> >> > >> > Intel-gfx mailing list >> >> > >> > Intel-gfx@lists.freedesktop.org >> >> > >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> > >> >> >> > >> -- >> >> > >> Jani Nikula, Intel Open Source Technology Center >> >> > >> >> > -- >> >> > Jani Nikula, Intel Open Source Technology Center >> >> -- >> Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
