All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sharma, Shashank" <shashank.sharma@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	"Jindal, Sonika" <sonika.jindal@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/6] drm/i915: Add HDMI probe function
Date: Mon, 14 Sep 2015 09:55:33 +0000	[thread overview]
Message-ID: <FF3DDC77922A8A4BB08A3BC48A1EA8CB09A27D11@BGSMSX101.gar.corp.intel.com> (raw)
In-Reply-To: <20150914083008.GI3383@phenom.ffwll.local>

> You need to inject a fake hpd or similar everytime the world might have changed from under us, which isn't just init but also system resume.
This is a fake hpd only, just without wrapper, if you want, we can create a wrapper function like (intel_hdmi_insert_fake_hpd), and call this function from init()
And call HDMI probe(hot_plug) function from here. This would be just adding some CPU cycles in the code. 

> Adding hacks like these in the init code is certainly the wrong approach, since we never done detection this early (so surprising from a high-level
> ordering) and it also misses resume (which is why it should be done in code shared between driver load and resume).
During the ADF code development, we saw that fb_console comes up very soon, as soon as the intel_fbdev is ready, causing a detect() on a connected HDMI. 
Do you think intel_hpd_init() would be the right place to probe, coz as you rightly mentioned, we will need this on suspend/resume also. 

Regards
Shashank
-----Original Message-----
From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of Daniel Vetter
Sent: Monday, September 14, 2015 2:00 PM
To: Jindal, Sonika
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add HDMI probe function

On Fri, Sep 11, 2015 at 04:15:39PM +0530, Jindal, Sonika wrote:
> 
> 
> On 9/10/2015 12:25 AM, Rodrigo Vivi wrote:
> >I liked the approach and agree with Daniel, so with his suggestions 
> >feel free to use:
> >Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com 
> ><mailto:rodrigo.vivi@intel.com>>
> >
> >On Fri, Sep 4, 2015 at 7:46 AM Daniel Vetter <daniel@ffwll.ch 
> ><mailto:daniel@ffwll.ch>> wrote:
> >
> >    On Fri, Sep 04, 2015 at 06:56:12PM +0530, Sonika Jindal wrote:
> >     > From: Shashank Sharma <shashank.sharma@intel.com
> >    <mailto:shashank.sharma@intel.com>>
> >     >
> >     > This patch adds a separate probe function for HDMI
> >     > EDID read over DDC channel. This function has been
> >     > registered as a .hot_plug handler for HDMI encoder.
> >     >
> >     > The current implementation of hdmi_detect()
> >     > function re-sets the cached HDMI edid (in connector->detect_edid) in
> >     > every detect call.This function gets called many times, sometimes
> >     > directly from userspace probes, forcing drivers to read EDID every
> >     > detect function call.This causes several problems like:
> >     >
> >     > 1. Race conditions in multiple hot_plug / unplug cases, between
> >     >    interrupts bottom halves and userspace detections.
> >     > 2. Many Un-necessary EDID reads for single hotplug/unplug
> >     > 3. HDMI complaince failures which expects only one EDID read per
> >    hotplug
> >     >
> >     > This function will be serving the purpose of really reading the EDID
> >     > by really probing the DDC channel, and updating the cached EDID.
> >     >
> >     > The plan is to:
> >     > 1. i915 IRQ handler bottom half function already calls
> >     >    intel_encoder->hotplug() function. Adding This probe function
> >    which
> >     >    will read the EDID only in case of a hotplug / unplug.
> >     > 2. During init_connector his probe will be called to read the edid
> >     > 3. Reuse the cached EDID in hdmi_detect() function.
> >     >
> >     > The "< gen7" check is there because this was tested only for >=gen7
> >     > platforms. For older platforms the hotplug/reading edid path
> >    remains same.
> >     >
> >     > v2: Calling set_edid instead of hdmi_probe during init.
> >     > Also, for platforms having DDI, intel_encoder for DP and HDMI is same
> >     > (taken from intel_dig_port), so for DP also, hot_plug function
> >    gets called
> >     > which is not intended here. So, check for HDMI in intel_hdmi_probe
> >     > Rely on HPD for updating edid only for platforms gen > 8 and also
> >    for VLV.
> >     >
> >     > v3: Dropping the gen < 8 || !VLV  check. Now all platforms should
> >    rely on
> >     > hotplug or init for updating the edid.(Daniel)
> >     > Also, calling hdmi_probe in init instead of set_edid
> >     >
> >     > Signed-off-by: Shashank Sharma <shashank.sharma@intel.com
> >    <mailto:shashank.sharma@intel.com>>
> >     > Signed-off-by: Sonika Jindal <sonika.jindal@intel.com
> >    <mailto:sonika.jindal@intel.com>>
> >     > ---
> >     >  drivers/gpu/drm/i915/intel_hdmi.c |   46
> >    ++++++++++++++++++++++++++++++++-----
> >     >  1 file changed, 40 insertions(+), 6 deletions(-)
> >     >
> >     > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> >    b/drivers/gpu/drm/i915/intel_hdmi.c
> >     > index 5bdb386..1eda71a 100644
> >     > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >     > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >     > @@ -1368,23 +1368,53 @@ intel_hdmi_set_edid(struct drm_connector
> >    *connector)
> >     >       return connected;
> >     >  }
> >     >
> >     > +void intel_hdmi_probe(struct intel_encoder *intel_encoder)
> >
> >    Please call it _hot_plug if it's for the _hot_plug path.
> >
> Hmm, initial plan was to call it from other places if any..
> But now it seems more logical to name it _hot_plug.
> I will do that.
> 
> >     > +{
> >     > +     struct intel_hdmi *intel_hdmi =
> >     > +                     enc_to_intel_hdmi(&intel_encoder->base);
> >     > +     struct intel_connector *intel_connector =
> >     > +                             intel_hdmi->attached_connector;
> >     > +
> >     > +     /*
> >     > +      * We are here, means there is a hotplug or a force
> >     > +      * detection. Clear the cached EDID and probe the
> >     > +      * DDC bus to check the current status of HDMI.
> >     > +      */
> >     > +     intel_hdmi_unset_edid(&intel_connector->base);
> >     > +     if (intel_hdmi_set_edid(&intel_connector->base))
> >     > +             DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
> >     > +     else
> >     > +             DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
> >     > +}
> >     > +
> >     >  static enum drm_connector_status
> >     >  intel_hdmi_detect(struct drm_connector *connector, bool force)
> >     >  {
> >     >       enum drm_connector_status status;
> >     > +     struct intel_connector *intel_connector =
> >     > +                             to_intel_connector(connector);
> >     >
> >     >       DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> >     >                     connector->base.id <http://base.id>,
> >    connector->name);
> >     > +     /*
> >     > +      * There are many userspace calls which probe EDID from
> >     > +      * detect path. In case of multiple hotplug/unplug, these
> >     > +      * can cause race conditions while probing EDID. Also its
> >     > +      * waste of CPU cycles to read the EDID again and again
> >     > +      * unless there is a real hotplug.
> >     > +      * So, rely on hotplugs and init to read edid.
> >     > +      * Check connector status based on availability of cached EDID.
> >     > +      */
> >     >
> >     > -     intel_hdmi_unset_edid(connector);
> >     > -
> >     > -     if (intel_hdmi_set_edid(connector)) {
> >     > +     if (intel_connector->detect_edid) {
> >     >               struct intel_hdmi *intel_hdmi =
> >    intel_attached_hdmi(connector);
> >     > -
> >     > -             hdmi_to_dig_port(intel_hdmi)->base.type =
> >    INTEL_OUTPUT_HDMI;
> >     >               status = connector_status_connected;
> >     > -     } else
> >     > +             hdmi_to_dig_port(intel_hdmi)->base.type =
> >    INTEL_OUTPUT_HDMI;
> >     > +             DRM_DEBUG_DRIVER("hdmi status = connected\n");
> >     > +     } else {
> >     >               status = connector_status_disconnected;
> >     > +             DRM_DEBUG_DRIVER("hdmi status = disconnected\n");
> >     > +     }
> >     >
> >     >       return status;
> >     >  }
> >     > @@ -2104,11 +2134,15 @@ void intel_hdmi_init_connector(struct
> >    intel_digital_port *intel_dig_port,
> >     >       intel_connector->unregister = intel_connector_unregister;
> >     >
> >     >       intel_hdmi_add_properties(intel_hdmi, connector);
> >     > +     intel_encoder->hot_plug = intel_hdmi_probe;
> >     >
> >     >       intel_connector_attach_encoder(intel_connector, intel_encoder);
> >     >       drm_connector_register(connector);
> >     >       intel_hdmi->attached_connector = intel_connector;
> >     >
> >     > +     /* Set edid during init */
> >     > +     intel_hdmi_probe(intel_encoder);
> >
> >    Separate patch, but we really don't want this, initial probe should be
> >    done async to avoid stalling the driver.
> >    -Daniel
> 
> Where else do you suggest to do this? detect call is one place which 
> does this for DP and used to do for HDMI also.
> But since we need to take the edid reading part out of edid, I dont 
> see any other place.
> Please suggest.

You need to inject a fake hpd or similar everytime the world might have changed from under us, which isn't just init but also system resume.

We do that already, so you just have to make sure that keeps on working.
Probably another reason why it would be better to rework that entire hpd handling/detection code, to make sure it's clean and can be understood.

Adding hacks like these in the init code is certainly the wrong approach, since we never done detection this early (so surprising from a high-level
ordering) and it also misses resume (which is why it should be done in code shared between driver load and resume).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-09-14  9:55 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-04 13:26 [PATCH 0/6] HDMI optimization series Sonika Jindal
2015-09-04 13:26 ` [PATCH 1/6] drm/i915: add attached connector to hdmi container Sonika Jindal
2015-09-09 18:54   ` Rodrigo Vivi
2015-09-10 15:24     ` Daniel Vetter
2015-09-04 13:26 ` [PATCH 2/6] drm/i915: Add HDMI probe function Sonika Jindal
2015-09-04 14:48   ` Daniel Vetter
2015-09-09 18:55     ` Rodrigo Vivi
2015-09-11 10:45       ` Jindal, Sonika
2015-09-14  8:30         ` Daniel Vetter
2015-09-14  9:55           ` Sharma, Shashank [this message]
2015-09-14 13:07             ` Daniel Vetter
2015-09-14 13:45               ` Sharma, Shashank
2015-09-28  8:56                 ` [PATCH] drm/i915: Add hot_plug hook for hdmi encoder Sonika Jindal
2015-09-28 13:34                   ` Daniel Vetter
2015-09-29  4:13                     ` Jindal, Sonika
2015-09-29  9:04                       ` Daniel Vetter
2015-10-05 11:13                     ` [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases Sonika Jindal
2015-10-05 11:13                       ` [PATCH 2/2] drm/i915: Add hot_plug hook for hdmi encoder Sonika Jindal
2015-10-06  8:28                         ` Daniel Vetter
2015-12-10  4:30                           ` Sonika Jindal
2015-12-10  4:45                             ` [PATCH] " Sonika Jindal
2015-12-10  8:29                               ` Daniel Vetter
2015-12-10  8:35                                 ` Jindal, Sonika
2015-12-10  8:53                                   ` Daniel Vetter
2015-12-10  9:04                                     ` Jindal, Sonika
2015-10-08 13:35                       ` [PATCH 1/2] drm/i915: Call encoder hotplug for init and resume cases Ville Syrjälä
2015-10-08 14:38                         ` Jani Nikula
2015-10-08 19:54                           ` Daniel Vetter
2015-10-09  4:31                             ` Jindal, Sonika
2015-12-10  4:27                             ` Sonika Jindal
2015-10-12 12:24                         ` Sharma, Shashank
2015-10-15  1:32                           ` Jindal, Sonika
2015-09-04 13:26 ` [PATCH 3/6] drm/i915: Make intel_digital_port_connected global Sonika Jindal
2015-09-09 18:57   ` Rodrigo Vivi
2015-09-11 11:28     ` [PATCH] drm/i915/bxt: Use intel_encoder->hpd_pin to check live status Sonika Jindal
2015-09-11 18:00       ` Rodrigo Vivi
2015-09-12 12:02         ` Jindal, Sonika
2015-09-14  8:34       ` Daniel Vetter
2015-09-14  8:38         ` Jindal, Sonika
2015-09-14  9:15           ` Daniel Vetter
2015-09-04 13:26 ` [PATCH 4/6] drm/i915: drm/i915: Check live status before reading edid Sonika Jindal
2015-09-04 14:49   ` Daniel Vetter
2015-09-07  5:02     ` [PATCH] " Sonika Jindal
2015-09-08 11:21       ` Sonika Jindal
2015-09-09 19:11     ` [PATCH 4/6] drm/i915: " Rodrigo Vivi
2015-09-11 11:26       ` [PATCH] " Sonika Jindal
2015-09-11 17:56         ` Rodrigo Vivi
2015-09-14  8:42           ` Daniel Vetter
2015-09-14  9:14             ` Jindal, Sonika
2015-09-14  9:36               ` Daniel Vetter
2015-09-15  4:14                 ` Sonika Jindal
2015-09-23  8:18                   ` Daniel Vetter
2016-03-08 21:03                   ` Chris Wilson
2016-03-09  5:52                     ` Jindal, Sonika
2016-03-09  5:55                       ` Sharma, Shashank
2016-03-10 11:37                         ` Sharma, Shashank
2015-09-04 13:26 ` [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func Sonika Jindal
2015-09-04 14:47   ` Daniel Vetter
2015-09-06  4:31     ` Jindal, Sonika
2015-09-07  5:04       ` [PATCH] drm/i915: Call encoder hot_plug hook only for hdmi Sonika Jindal
2015-09-07 16:26         ` Daniel Vetter
2015-09-08  4:42           ` Jindal, Sonika
2015-09-08 11:38             ` Jindal, Sonika
2015-09-09 15:17               ` Daniel Vetter
2015-09-10  1:07                 ` Jindal, Sonika
2015-09-10 14:47                   ` Daniel Vetter
2015-09-09 19:20       ` [PATCH 5/6] drm/i915: drm/i915: Process hpd only for hdmi inside hotplug_work_func Rodrigo Vivi
2015-09-09 23:37         ` Jindal, Sonika
2015-09-04 13:26 ` [PATCH 6/6] drm/i915/bxt: Fix irq_port for eDP Sonika Jindal
2015-09-09 19:24   ` Rodrigo Vivi
2015-09-10 10:49     ` Jindal, Sonika
2015-09-10 13:07     ` R, Durgadoss
2015-09-10 13:35       ` Ville Syrjälä
2015-09-10 14:51         ` Daniel Vetter

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=FF3DDC77922A8A4BB08A3BC48A1EA8CB09A27D11@BGSMSX101.gar.corp.intel.com \
    --to=shashank.sharma@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=sonika.jindal@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.