[Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.
Wang, Quanxian
quanxian.wang at intel.com
Tue Jun 17 08:24:30 CEST 2014
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.
Thanks
Regards
Quanxian Wang
> -----Original Message-----
> From: Wang, Quanxian
> Sent: Tuesday, June 17, 2014 10:14 AM
> To: 'Jani Nikula'
> 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.
>
>
>
> > -----Original Message-----
> > From: Jani Nikula [mailto:jani.nikula at linux.intel.com]
> > Sent: Monday, June 16, 2014 4:18 PM
> > To: Wang, Quanxian; Daniel Vetter
> > Cc: intel-gfx at 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.wang at intel.com>
> wrote:
> > >> -----Original Message-----
> > >> From: Jani Nikula [mailto:jani.nikula at linux.intel.com]
> > >> Sent: Friday, June 13, 2014 5:12 PM
> > >> To: Daniel Vetter; Wang, Quanxian
> > >> Cc: intel-gfx at 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 <daniel at 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.wang at 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 at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_error_20140617.log
Type: application/octet-stream
Size: 52368 bytes
Desc: dmesg_error_20140617.log
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140617/0575661b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg_normal_20140617.log
Type: application/octet-stream
Size: 85514 bytes
Desc: dmesg_normal_20140617.log
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140617/0575661b/attachment-0001.obj>
More information about the Intel-gfx
mailing list