intel-gfx.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: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 09/10] drm/i915: Iterate all child devs in intel_bios_is_port_present()
Date: Mon, 13 Feb 2023 18:47:18 +0200	[thread overview]
Message-ID: <Y+pplr7tFJL0Fvzn@intel.com> (raw)
In-Reply-To: <878rh1v7pt.fsf@intel.com>

On Mon, Feb 13, 2023 at 06:41:18PM +0200, Jani Nikula wrote:
> On Mon, 13 Feb 2023, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Mon, Feb 13, 2023 at 06:08:50PM +0200, Jani Nikula wrote:
> >> On Wed, 08 Feb 2023, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> >> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> >
> >> > Instead of consulting vbt.ports[] lets just go through the
> >> > whole child device list to check whether a specific port
> >> > was declared by the VBT or not.
> >> 
> >> Might want to mention that this does not impact the dupe checking even
> >> if we look at display_devices instead of vbt.ports[].
> >
> > Hmm, except for the !is_port_valid() check.
> 
> D'oh!
> 
> > Should we
> > maybe do that here too, or should we just think about 
> > fully exorcising invalid ports from the child device list?
> 
> Maybe the first step that fits in this series is just including the
> check here too?
> 
> Otherwise, I'm divided. I kind of always wanted the VBT parsing part to
> be just that, parsing what's in the VBT, and only include checks/filters
> that ensure it's internally consistent. And the consumers of the data
> would cross check against platforms etc.
> 
> But I guess the VBT data itself has been filled with platform specific
> details, so *shrug*. I could be persuaded either way.
> 
> I guess there could be a separate filtering step. I'd hate to add
> filtering to parse_general_definitions().

Yeah, parse->filter->consume might be the right option eventually.

I've been also pondering about deleting the child device from
the list if we fail to probe it (eg. in the case of these 
phantom eDPs). But haven't yet really thought through the
implications of keep vs. delete.

> 
> BR,
> Jani.
> 
> 
> >
> >> 
> >> >
> >> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_bios.c | 11 ++++++++++-
> >> >  1 file changed, 10 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > index efe33af2259b..1af175b48ae6 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > @@ -3398,10 +3398,19 @@ bool intel_bios_is_lvds_present(struct drm_i915_private *i915, u8 *i2c_pin)
> >> >   */
> >> >  bool intel_bios_is_port_present(struct drm_i915_private *i915, enum port port)
> >> >  {
> >> > +	const struct intel_bios_encoder_data *devdata;
> >> > +
> >> >  	if (WARN_ON(!has_ddi_port_info(i915)))
> >> >  		return true;
> >> >  
> >> > -	return i915->display.vbt.ports[port];
> >> > +	list_for_each_entry(devdata, &i915->display.vbt.display_devices, node) {
> >> > +		const struct child_device_config *child = &devdata->child;
> >> > +
> >> > +		if (dvo_port_to_port(i915, child->dvo_port) == port)
> >> > +			return true;
> >> > +	}
> >> > +
> >> > +	return false;
> >> >  }
> >> >  
> >> >  /**
> >> 
> >> -- 
> >> Jani Nikula, Intel Open Source Graphics Center
> 
> -- 
> Jani Nikula, Intel Open Source Graphics Center

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2023-02-13 16:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-08  1:54 [Intel-gfx] [PATCH 00/10] drm/i915: Prep work for vbt.ports[] nukage Ville Syrjala
2023-02-08  1:54 ` [Intel-gfx] [PATCH 01/10] drm/i915: Pass the whole encoder to hotplug_enables() Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 02/10] drm/i915: Move variables to loop context Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 03/10] drm/i915: Replace intel_bios_is_lspcon_present() with intel_bios_encoder_is_lspcon() Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 04/10] drm/i915: Replace intel_bios_is_lane_reversal_needed() with intel_bios_encoder_lane_reversal() Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 05/10] drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert() Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 06/10] drm/i915: Consult the registested encoders for the ICL combo PHY w/a Ville Syrjala
2023-02-13 16:12   ` Jani Nikula
2023-02-08  1:55 ` [Intel-gfx] [PATCH 07/10] drm/i915: Populate encoder->devdata for g4x+ DP/HDMI ports Ville Syrjala
2023-02-13 16:12   ` Jani Nikula
2023-02-08  1:55 ` [Intel-gfx] [PATCH 08/10] drm/i915: Pass devdata to intel_bios_port_aux_ch() Ville Syrjala
2023-02-08  1:55 ` [Intel-gfx] [PATCH 09/10] drm/i915: Iterate all child devs in intel_bios_is_port_present() Ville Syrjala
2023-02-13 16:08   ` Jani Nikula
2023-02-13 16:17     ` Ville Syrjälä
2023-02-13 16:41       ` Jani Nikula
2023-02-13 16:47         ` Ville Syrjälä [this message]
2023-02-14  7:38   ` [Intel-gfx] [PATCH v2 " Ville Syrjala
2023-02-14  8:11     ` Jani Nikula
2023-02-08  1:55 ` [Intel-gfx] [PATCH 10/10] drm/i915: Use encoder->devdata in eDP init Ville Syrjala
2023-02-13 16:13   ` Jani Nikula
2023-02-08  4:39 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prep work for vbt.ports[] nukage Patchwork
2023-02-08  8:51 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-02-13 16:11 ` [Intel-gfx] [PATCH 00/10] " Jani Nikula
2023-02-14  8:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prep work for vbt.ports[] nukage (rev2) Patchwork
2023-02-14  9:27 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=Y+pplr7tFJL0Fvzn@intel.com \
    --to=ville.syrjala@linux.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 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).