Intel-GFX Archive on lore.kernel.org
 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 v3 04/22] drm/i915: Introduce <platoform>_hotplug_mask()
Date: Tue, 28 Feb 2023 21:52:06 +0200	[thread overview]
Message-ID: <Y/5bZkc4E0TIRwvt@intel.com> (raw)
In-Reply-To: <871qm9y6vz.fsf@intel.com>

On Tue, Feb 28, 2023 at 08:36:16PM +0200, Jani Nikula wrote:
> On Wed, 22 Feb 2023, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Pair each <platform>_hotplug_enables() function with
> > a corresponding <platform>_hotplug_mask() function so that
> > we can determine right bits to clear on a per hpd_pin basis.
> > We'll need this for turning on HPD sense for a specific
> > encoder rather than just all of them.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 231 ++++++++++++++++++++++----------
> >  1 file changed, 160 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index 13ada0916c2a..ecfa6dad145a 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2835,8 +2835,25 @@ static void cherryview_irq_reset(struct drm_i915_private *dev_priv)
> >  		vlv_display_irq_reset(dev_priv);
> >  	spin_unlock_irq(&dev_priv->irq_lock);
> >  }
> >  
> > +static u32 ibx_hotplug_mask(struct drm_i915_private *i915,
> > +			    enum hpd_pin hpd_pin)
> 
> 
> What's the reason for passing i915 to these functions? I see no use in
> this series, am I missing something? Seems like it makes some calls a
> bit convoluted.
> 
> BR,
> Jani.
> 
> > +{
> > +	switch (hpd_pin) {
> > +	case HPD_PORT_A:

I think I initially copied over the LPT-LP check from
ibx_hotplug_enables(), which is what needed i915. But
apparently I got rid of it later, and so looks like 
i915 can go too.

> > +		return PORTA_HOTPLUG_ENABLE;
> > +	case HPD_PORT_B:
> > +		return PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_MASK;
> > +	case HPD_PORT_C:
> > +		return PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_MASK;
> > +	case HPD_PORT_D:
> > +		return PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_MASK;
> > +	default:
> > +		return 0;
> > +	}
> > +}
> > +
> >  static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
> >  {
> >  	struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> >  
> > @@ -2869,15 +2886,12 @@ static void ibx_hpd_detection_setup(struct drm_i915_private *dev_priv)
> >  	 * duration to 2ms (which is the minimum in the Display Port spec).
> >  	 * The pulse duration bits are reserved on LPT+.
> >  	 */
> >  	intel_uncore_rmw(&dev_priv->uncore, PCH_PORT_HOTPLUG,
> > -			 PORTA_HOTPLUG_ENABLE |

No LPT-LP check here either, so presumably clearing the bit
unconditionally is fine... Yeah, doesn't look like there was
anything else there, ever.

> > -			 PORTB_HOTPLUG_ENABLE |
> > -			 PORTC_HOTPLUG_ENABLE |
> > -			 PORTD_HOTPLUG_ENABLE |
> > -			 PORTB_PULSE_DURATION_MASK |
> > -			 PORTC_PULSE_DURATION_MASK |
> > -			 PORTD_PULSE_DURATION_MASK,
> > +			 ibx_hotplug_mask(dev_priv, HPD_PORT_A) |
> > +			 ibx_hotplug_mask(dev_priv, HPD_PORT_B) |
> > +			 ibx_hotplug_mask(dev_priv, HPD_PORT_C) |
> > +			 ibx_hotplug_mask(dev_priv, HPD_PORT_D),
> >  			 intel_hpd_hotplug_enables(dev_priv, ibx_hotplug_enables));
> >  }
> >  

-- 
Ville Syrjälä
Intel

  reply	other threads:[~2023-02-28 19:52 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-21 23:02 [Intel-gfx] [PATCH v3 00/22] drm/i915: Init DDI ports in VBT order Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 01/22] drm/i915: Populate dig_port->connected() before connector init Ville Syrjala
2023-02-28 17:58   ` Jani Nikula
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 02/22] drm/i915: Fix SKL DDI A digital port .connected() Ville Syrjala
2023-02-28 18:18   ` Jani Nikula
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 03/22] drm/i915: Get rid of the gm45 HPD live state nonsense Ville Syrjala
2023-02-28 18:19   ` Jani Nikula
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 04/22] drm/i915: Introduce <platoform>_hotplug_mask() Ville Syrjala
2023-02-28 18:36   ` Jani Nikula
2023-02-28 19:52     ` Ville Syrjälä [this message]
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 05/22] drm/i915: Introduce intel_hpd_detection() Ville Syrjala
2023-02-28 12:40   ` Jani Nikula
2023-02-28 12:50     ` Ville Syrjälä
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 06/22] drm/i915: Check HPD live state during eDP probe Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 07/22] drm/i915: Sanitize child devices later Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 08/22] drm/i915: Split map_aux_ch() into per-platform arrays Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 09/22] drm/i915: Flip VBT DDC pin maps around Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 10/22] drm/i915: Nuke intel_bios_is_port_dp_dual_mode() Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 11/22] drm/i915: Remove bogus DDI-F from hsw/bdw output init Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 12/22] drm/i915: Introduce device info port_mask Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 13/22] drm/i915: Assert that device info bitmasks have enough bits Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 14/22] drm/i915: Assert that the port being initialized is valid Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 15/22] drm/i915: Beef up SDVO/HDMI port checks Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 16/22] drm/i915: Init DDI outputs based on port_mask on skl+ Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 17/22] drm/i915: Try to initialize DDI/ICL+ DSI ports for every VBT child device Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 18/22] drm/i915: Convert HSW/BDW to use VBT driven DDI probe Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 19/22] drm/i915: Remove DDC pin sanitation Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 20/22] drm/i915: Remove AUX CH sanitation Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 21/22] drm/i915: Initialize dig_port->aux_ch to NONE to be sure Ville Syrjala
2023-02-21 23:02 ` [Intel-gfx] [PATCH v3 22/22] drm/i915: Only populate aux_ch is really needed Ville Syrjala
2023-02-21 23:35 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Init DDI ports in VBT order (rev3) Patchwork
2023-02-22  3:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-02-22  5:11 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-02-22 15:50 ` [Intel-gfx] [PATCH v3 00/22] drm/i915: Init DDI ports in VBT order Ville Syrjälä
2023-05-26  4:48 ` Kai-Heng Feng

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/5bZkc4E0TIRwvt@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