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 05/22] drm/i915: Introduce intel_hpd_detection()
Date: Tue, 28 Feb 2023 14:50:27 +0200 [thread overview]
Message-ID: <Y/34k0p0S30+xgIT@intel.com> (raw)
In-Reply-To: <87k002ynd7.fsf@intel.com>
On Tue, Feb 28, 2023 at 02:40:20PM +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>
> >
> > Add a mechanism by which we can toggle the HPD sense for
> > individual encoders.
> >
> > This will be used during eDP probing to figure out if
> > anything is actually connected. The normal intel_hpd_irq_setup()
> > thing doesn't work since we only do that after probing the
> > outputs, and we only enable HPD sense for encoders that were
> > successfully probed.
> >
> > The other idea that crossed my minds was to just turn on
> > HPD sense for all pins before output probing and let hpd_irq_setup()
> > clean it up afterwards. But that doesn't work for BXT/GLK where
> > the HPD invert information comes from the VBT child device.
> > So looks like this really needs to be per-encoder.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 132 ++++++++++++++++++++++++++++++++
> > drivers/gpu/drm/i915/i915_irq.h | 2 +
> > 2 files changed, 134 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index ecfa6dad145a..c5058d834f99 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2893,8 +2893,17 @@ static void ibx_hpd_detection_setup(struct drm_i915_private *dev_priv)
> > ibx_hotplug_mask(dev_priv, HPD_PORT_D),
> > intel_hpd_hotplug_enables(dev_priv, ibx_hotplug_enables));
> > }
> >
> > +static void ibx_hpd_detection(struct intel_encoder *encoder, bool enable)
>
> Just quickly skimming through the series...
>
> ...and nitpicking, *_detection() should really be a verb.
>
> It isn't obvious to me what intel_hpd_detection() does without looking
> at the implementation.
I was origianlly musing about foo_enable_hpd_detection(), but then
passing in a 'bool enable' for an enable() function seems a bit
crap. I guess it could be foo_set_hpd_detection() or something like
that.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2023-02-28 12:50 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ä
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ä [this message]
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/34k0p0S30+xgIT@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 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.