dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: airlied@linux.ie, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, swati2.sharma@intel.com,
	Kai-Heng Feng <kai.heng.feng@canonical.com>,
	dri-devel@lists.freedesktop.org, rodrigo.vivi@intel.com
Subject: Re: [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed
Date: Tue, 14 Jan 2020 16:55:41 +0200	[thread overview]
Message-ID: <20200114145541.GW13686@intel.com> (raw)
In-Reply-To: <87ftgiku03.fsf@intel.com>

On Tue, Jan 14, 2020 at 04:11:40PM +0200, Jani Nikula wrote:
> On Mon, 06 Jan 2020, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> > Hi Jani,
> >
> >> On Dec 24, 2019, at 16:42, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> >> 
> >> On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port
> >> becomes useless and never responds to cable hotplugging:
> >> [    3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
> >> [    3.031945] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
> >> 
> >> Seems like the lspcon chip on the system in question only gets powered
> >> after the cable is plugged.
> >> 
> >> So let's call lspcon_init() dynamically to properly initialize the
> >> lspcon chip and make HDMI port work.
> >
> > Do you have any further suggestion for this patch?
> 
> Sorry for taking so long. Comments inline.
> 
> >
> > Kai-Heng
> >
> >> 
> >> Closes: https://gitlab.freedesktop.org/drm/intel/issues/203
> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >> ---
> >> v3:
> >> - Make sure it's handled under long HPD case.
> >> 
> >> v2: 
> >> - Move lspcon_init() inside of intel_dp_hpd_pulse().
> >> 
> >> drivers/gpu/drm/i915/display/intel_dp.c | 8 +++++++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> >> index fe31bbfd6c62..a72c9c041c60 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> @@ -6573,6 +6573,7 @@ enum irqreturn
> >> intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> >> {
> >> 	struct intel_dp *intel_dp = &intel_dig_port->dp;
> >> +	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> >> 
> >> 	if (long_hpd && intel_dig_port->base.type == INTEL_OUTPUT_EDP) {
> >> 		/*
> >> @@ -6593,7 +6594,12 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
> >> 		      long_hpd ? "long" : "short");
> >> 
> >> 	if (long_hpd) {
> >> -		intel_dp->reset_link_params = true;
> >> +		if (intel_dig_port->base.type == INTEL_OUTPUT_DDI &&
> >> +		    HAS_LSPCON(dev_priv) && !intel_dig_port->lspcon.active)
> >> +			lspcon_init(intel_dig_port);
> >> +		else
> >> +			intel_dp->reset_link_params = true;
> >> +
> 
> Hmm, I think this will try to init lspcon on ports that do not have
> lspcon. Also, why wouldn't we reset the params?
> 
> I think this boils down to just adding the following lines:
> 
> 	if (intel_bios_is_lspcon_present(dev_priv, intel_dig_port->base.port) &&
>             !intel_dig_port->lspcon.active)
> 		lspcon_init(intel_dig_port);
> 
> 
> Ville?

This won't work right. Eg. intel_infoframe_init() assumes that lspcon
init happens during driver load. We should probably change that to just
trust the VBT and simply move the lspcon probe (if we even need one)
into dp_detect() instead of sprinkling it around in several places.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

      reply	other threads:[~2020-01-14 14:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-24  8:42 [PATCH v3] drm/i915: Re-init lspcon after HPD if lspcon probe failed Kai-Heng Feng
2020-01-06  8:35 ` Kai-Heng Feng
2020-01-14 14:11   ` Jani Nikula
2020-01-14 14:55     ` Ville Syrjälä [this message]

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=20200114145541.GW13686@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=swati2.sharma@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).