All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Quanxian" <quanxian.wang@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform.
Date: Mon, 23 Jun 2014 10:37:24 +0000	[thread overview]
Message-ID: <50C7F552BA2A744D84D95119645BEABD0EC4CD1F@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <87ionzy2a9.fsf@intel.com>



> -----Original Message-----
> From: Jani Nikula [mailto:jani.nikula@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.wang@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?

> 
> 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.nikula@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.wang@intel.com>
> >> wrote:
> >> > >> -----Original Message-----
> >> > >> From: Jani Nikula [mailto:jani.nikula@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 <daniel@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@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

  reply	other threads:[~2014-06-23 10:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13  6:52 [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable for valleyview platform Quanxian Wang
2014-06-13  6:55 ` Chris Wilson
2014-06-16  1:54   ` Wang, Quanxian
2014-06-13  7:16 ` Daniel Vetter
2014-06-13  9:12   ` Jani Nikula
2014-06-16  1:57     ` Wang, Quanxian
2014-06-16  8:18       ` Jani Nikula
2014-06-17  2:14         ` Wang, Quanxian
2014-06-17 15:12           ` Jani Nikula
2014-06-18  3:14             ` Wang, Quanxian
2014-06-18 10:45               ` Jani Nikula
2014-06-17  6:24         ` Wang, Quanxian
2014-06-17 15:38           ` Jani Nikula
2014-06-23 10:37             ` Wang, Quanxian [this message]
2014-06-24 15:58               ` Jani Nikula
2014-06-26  5:39                 ` Wang, Quanxian
2014-06-30 10:45                   ` Jani Nikula
2014-07-01  2:03                     ` Wang, Quanxian
2014-06-24 21:27               ` Dave Airlie
2014-06-13  9:23   ` Wang, Quanxian
2014-06-13 10:17     ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50C7F552BA2A744D84D95119645BEABD0EC4CD1F@SHSMSX101.ccr.corp.intel.com \
    --to=quanxian.wang@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.