All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: imre.deak@intel.com
Cc: igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t v2] tests/kms_chamelium: Make sure we wait for each connectors' hotplug event
Date: Thu, 09 May 2019 14:24:10 +0200	[thread overview]
Message-ID: <856d50c4dfb80a98d73ed93bc0edf7ef8cc008d0.camel@bootlin.com> (raw)
In-Reply-To: <20190509120845.GC11264@ideak-desk.fi.intel.com>

Hi,

On Thu, 2019-05-09 at 15:08 +0300, Imre Deak wrote:
> On Thu, May 09, 2019 at 09:25:41AM +0200, Paul Kocialkowski wrote:
> > On Wed, 2019-05-08 at 11:24 +0300, Imre Deak wrote:
> > > After scheduling an HPD toggle event, make sure that we wait for the
> > > hotplug event for each connector that may be sent by the driver.
> > > 
> > > Depending on the scheduling there could be 1 event or as many events as
> > > connectors we scheduled an HPD toggle event on, depending on the timing.
> > > So if we don't yet see the expected connector state on a given connector
> > > try to wait for an additional hotplug event and reprobe/recheck the
> > > state.
> > 
> > This changes makes good sense to me, so:
> > 
> > Reviewed-By: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > 
> > And it brings back hard feelings about the hotplug interface we have
> > today...
> 
> Yes, I was surprised too not find any way to identify which connector(s)
> the hotplug event is associated with. We discussed with Ville if it'd
> make sense to add a connector ID map to the uevent, but not sure if it'd
> be useful outside of this test, or how that would align with Chris'
> connector probe state generation idea.

Either way, I'm definitely in favor of having something more reliable
to expose to userspace. Having something to correlate each event to one
(or more) connector(s) sounds good to me.

And I think there is a general need for this, it's not just IGT.

Currently, every userspace application using DRM has to do a full
reprobe once a hotplug uevent is received, which is really not optimal.
If an entry identifying the connector was also provided, userspace
could only reprobe that connector. The step after that would be having
the indication of whether the connector was connected or disconnected
directly in uevent too, so that no probing needs to be done at all when
a given connector is disconnected.

Anyway, if you're interested in the idea and that Ville and Chris are
in favor, I really think it would be worth fixing that. And we'd only
be adding new elements to uevent, so that would stay backward-
compatible too.

Cheers,

Paul

> > > v2:
> > > - s/igt_assert(x >= y)/igt_assert_lte(y, x)/ to see the actual limits in
> > >   the debugging output. (Lyude)
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110534
> > > Cc: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > Cc: Lyude Paul <lyude@redhat.com>
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > Reviewed-by: Lyude Paul <lyude@redhat.com>
> > > ---
> > >  tests/kms_chamelium.c | 45 +++++++++++++++++++++++++++++++++++++------
> > >  1 file changed, 39 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/tests/kms_chamelium.c b/tests/kms_chamelium.c
> > > index 714e5e06..502f1efa 100644
> > > --- a/tests/kms_chamelium.c
> > > +++ b/tests/kms_chamelium.c
> > > @@ -284,11 +284,32 @@ test_edid_read(data_t *data, struct chamelium_port *port,
> > >  	drmModeFreeConnector(connector);
> > >  }
> > >  
> > > +/* Wait for hotplug and return the remaining time left from timeout */
> > > +static bool wait_for_hotplug(struct udev_monitor *mon, int *timeout)
> > > +{
> > > +	struct timespec start, end;
> > > +	int elapsed;
> > > +	bool detected;
> > > +
> > > +	igt_assert_eq(igt_gettime(&start), 0);
> > > +	detected = igt_hotplug_detected(mon, *timeout);
> > > +	igt_assert_eq(igt_gettime(&end), 0);
> > > +
> > > +	elapsed = igt_time_elapsed(&start, &end);
> > > +	igt_assert_lte(0, elapsed);
> > > +	*timeout = max(0, *timeout - elapsed);
> > > +
> > > +	return detected;
> > > +}
> > > +
> > >  static void
> > >  try_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
> > >  		       enum igt_suspend_state state, enum igt_suspend_test test,
> > >  		       struct udev_monitor *mon, bool connected)
> > >  {
> > > +	drmModeConnection target_state = connected ? DRM_MODE_DISCONNECTED :
> > > +						     DRM_MODE_CONNECTED;
> > > +	int timeout = HOTPLUG_TIMEOUT;
> > >  	int delay;
> > >  	int p;
> > >  
> > > @@ -310,17 +331,29 @@ try_suspend_resume_hpd(data_t *data, struct chamelium_port *port,
> > >  	}
> > >  
> > >  	igt_system_suspend_autoresume(state, test);
> > > +	igt_assert(wait_for_hotplug(mon, &timeout));
> > >  
> > > -	igt_assert(igt_hotplug_detected(mon, HOTPLUG_TIMEOUT));
> > >  	if (port) {
> > > -		igt_assert_eq(reprobe_connector(data, port), connected ?
> > > -			      DRM_MODE_DISCONNECTED : DRM_MODE_CONNECTED);
> > > +		igt_assert_eq(reprobe_connector(data, port), target_state);
> > >  	} else {
> > >  		for (p = 0; p < data->port_count; p++) {
> > > +			drmModeConnection current_state;
> > > +
> > >  			port = data->ports[p];
> > > -			igt_assert_eq(reprobe_connector(data, port), connected ?
> > > -				      DRM_MODE_DISCONNECTED :
> > > -				      DRM_MODE_CONNECTED);
> > > +			/*
> > > +			 * There could be as many hotplug events sent by
> > > +			 * driver as connectors we scheduled an HPD toggle on
> > > +			 * above, depending on timing. So if we're not seeing
> > > +			 * the expected connector state try to wait for an HPD
> > > +			 * event for each connector/port.
> > > +			 */
> > > +			current_state = reprobe_connector(data, port);
> > > +			if (p > 0 && current_state != target_state) {
> > > +				igt_assert(wait_for_hotplug(mon, &timeout));
> > > +				current_state = reprobe_connector(data, port);
> > > +			}
> > > +
> > > +			igt_assert_eq(current_state, target_state);
> > >  		}
> > >  
> > >  		port = NULL;
> > -- 
> > Paul Kocialkowski, Bootlin
> > Embedded Linux and kernel engineering
> > https://bootlin.com
> > 
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-05-09 12:24 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 17:51 [igt-dev] [PATCH i-g-t] tests/kms_chamelium: Make sure we wait for each connectors' hotplug event Imre Deak
2019-05-06 18:38 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2019-05-06 19:40 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2019-05-07 18:44 ` [igt-dev] [PATCH i-g-t] " Lyude Paul
2019-05-08  8:24 ` [igt-dev] [PATCH i-g-t v2] " Imre Deak
2019-05-09  7:25   ` Paul Kocialkowski
2019-05-09 12:08     ` Imre Deak
2019-05-09 12:24       ` Paul Kocialkowski [this message]
2019-05-09 15:56         ` Lyude Paul
2019-05-10  6:55           ` Ser, Simon
2019-05-10  7:42             ` Improving DRM connector hotplug uevents Paul Kocialkowski
2019-05-10  7:42               ` [igt-dev] " Paul Kocialkowski
2019-05-10  7:56               ` Daniel Vetter
2019-05-10  7:56                 ` [igt-dev] " Daniel Vetter
2019-05-10  8:00                 ` Paul Kocialkowski
2019-05-10  8:00                   ` [igt-dev] " Paul Kocialkowski
2019-05-10  8:06                   ` Daniel Vetter
2019-05-10  8:06                     ` [igt-dev] " Daniel Vetter
2019-05-10 14:28                     ` Paul Kocialkowski
2019-05-10 14:28                       ` [igt-dev] " Paul Kocialkowski
2019-05-10 14:39                 ` Ser, Simon
2019-05-10 14:39                   ` [igt-dev] " Ser, Simon
2019-05-08 10:06 ` [igt-dev] ✓ Fi.CI.BAT: success for tests/kms_chamelium: Make sure we wait for each connectors' hotplug event (rev2) Patchwork
2019-05-08 11:06 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
2019-05-09 13:59   ` Imre Deak

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=856d50c4dfb80a98d73ed93bc0edf7ef8cc008d0.camel@bootlin.com \
    --to=paul.kocialkowski@bootlin.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=imre.deak@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.