All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Gupta, Anshuman" <anshuman.gupta@intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>,
	"Wilson, Chris P" <chris.p.wilson@intel.com>,
	"Nilawar, Badal" <badal.nilawar@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 3/3] i915_pm_rpm: rpm resume by user forcewake
Date: Wed, 11 May 2022 08:03:11 +0000	[thread overview]
Message-ID: <54f86f76208046e2bbb317aabaeba675@intel.com> (raw)
In-Reply-To: <875ymmqer3.wl-ashutosh.dixit@intel.com>



> -----Original Message-----
> From: Dixit, Ashutosh <ashutosh.dixit@intel.com>
> Sent: Wednesday, May 4, 2022 6:46 AM
> To: Gupta, Anshuman <anshuman.gupta@intel.com>
> Cc: igt-dev@lists.freedesktop.org; Nilawar, Badal <badal.nilawar@intel.com>;
> Ewins, Jon <jon.ewins@intel.com>; Wilson, Chris P <chris.p.wilson@intel.com>
> Subject: Re: [PATCH i-g-t 3/3] i915_pm_rpm: rpm resume by user forcewake
> 
> On Thu, 21 Apr 2022 10:02:45 -0700, Anshuman Gupta wrote:
> >
> > Few gem rpm tests relies on enabling kms crtc in order to trigger rpm
> > resume but on headless platforms these tests skips.
> 
> skip
> 
> > Let it triggered the rpm resume by taking user forcewake.
> 
> Let it trigger rpm resume by taking user forcewake.
Thanks for review comments.
> 
> > +static void
> > +enable_one_screen_or_forcewake_and_wait(struct mode_set_data *data) {
> > +	bool headless;
> > +
> > +	/* Try to resume by enabling any type of display */
> > +	headless = !enable_one_screen_with_type(data, SCREEN_TYPE_ANY);
> > +
> > +	/*
> > +	 * Get User Forcewake to trigger rpm resume in case of headless
> > +	 * as well as no display being connected.
> > +	 */
> > +	if (headless && has_runtime_pm) {
> 
> I think we should remove 'has_runtime_pm' from here, it's confusing. E.g. what
> should we do in the '(headless && !has_runtime_pm)'
> case? There is already a 'igt_require(has_runtime_pm)' in
> setup_environment() triggered from igt_fixture.
Make sense I will do that change.
> 
> Different question: do we need to do this only in headless or can we do this
> unconditionally (i.e. get forcewake both with and without display)? If we can do
> this unconditionally the function becomes
> enable_one_screen_and_forcewake_and_wait() (s/or/and/).
I was conservative to add forcewake overhead to display test.
IMO let's only add this for non-display test.
enable_one_screen() does a modeset and that forces a resume, we need forcewake 
only when system is headless as it can't resume.
> 
> (Note to myself: with this change display tests will use
> enable_one_screen_and_wait() and skip when no display and tests which can
> run with or without display will use
> enable_one_screen_or_forcewake_and_wait(). For display tests we do need to
> call enable_one_screen_with_type() to initialize display).
Correct enable_one_screen_with_type() will do a modeset , display init will be there 
in setup_envirnment().

> 
> > +		data->fw_fd = igt_open_forcewake_handle(drm_fd);
> > +		igt_require(data->fw_fd > 0);
> > +	}
> > +	igt_assert(wait_for_active());
> > +}
> > +
> > +static void clear_forcewake(struct mode_set_data *data) {
> > +	if (data->fw_fd <= 0)
> > +		return;
> > +
> > +	data->fw_fd = close(data->fw_fd);
> > +	igt_assert_eq(data->fw_fd, 0);
> > +}
> > +
> > +static void
> > +disable_all_screens_or_clr_forcewake_and_wait(struct mode_set_data
> > +*data) {
> > +	clear_forcewake(data);
> > +	disable_all_screens(data);
> > +	igt_assert(wait_for_suspended());
> > +}
> > +
> 
> Change function name to disable_all_screens_and_clr_forcewake_and_wait()
> (s/or/and/) since we are doing both?
> 
> >  static drmModePropertyBlobPtr get_connector_edid(drmModeConnectorPtr
> connector,
> >						 int index)
> >  {
> > @@ -842,8 +879,10 @@ static void basic_subtest(void)
> >  {
> >	disable_all_screens_and_wait(&ms_data);
> >
> > -	if (ms_data.res)
> > -		enable_one_screen_and_wait(&ms_data);
> > +	if (ms_data.res) {
> 
> We shouldn't have this check now since we are now supporting headless?
Thanks for pointing this out,  I will remove this cond.
> 
> > +		enable_one_screen_or_forcewake_and_wait(&ms_data);
> > +		clear_forcewake(&ms_data);
> > +	}
> 
> /snip/
> 
> > @@ -2195,8 +2237,10 @@ igt_main_args("", long_options, help_str,
> opt_handler, NULL)
> >		pm_test_caching();
> >	}
> >
> > -	igt_fixture
> > +	igt_fixture {
> >		teardown_environment(false);
> > +		clear_forcewake(&ms_data);
> 
> Also looks like we do not need to install an exit_handler (which calls
> clear_forcewake()) since just closing the fd disables forcewake (and fd will be
> closed on process exit whether in error or not). So that part is ok.
> 
> Other tests seem display related but do we also need to change
> pm_test_tiling()?
This is display specific tilling , TileX, TileY. AFAIU tilling can not be tested without
connected display.
Only missing test I could think of module-reload test, there wcan have a test for headless .

Thanks,
Anshuman Gupta.  

  parent reply	other threads:[~2022-05-11  8:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 17:02 [igt-dev] [PATCH i-g-t 0/3] RPM Test on HEADLESS Anshuman Gupta
2022-04-21 17:02 ` [igt-dev] [PATCH i-g-t 1/3] test: i915_pm_rpm: init devid in setup_envirnoment Anshuman Gupta
2022-04-21 23:26   ` Dixit, Ashutosh
2022-04-21 17:02 ` [igt-dev] [PATCH i-g-t 2/3] test: i915_pm_rpm: conditional initialization of igt_display_t Anshuman Gupta
2022-04-21 23:29   ` Dixit, Ashutosh
2022-04-22  4:30     ` Gupta, Anshuman
2022-05-03 21:17     ` Dixit, Ashutosh
2022-04-21 17:02 ` [igt-dev] [PATCH i-g-t 3/3] i915_pm_rpm: rpm resume by user forcewake Anshuman Gupta
2022-05-04  1:16   ` Dixit, Ashutosh
2022-05-04  2:51     ` Dixit, Ashutosh
2022-05-04  4:32       ` Dixit, Ashutosh
2022-05-11  8:03     ` Gupta, Anshuman [this message]
2022-04-21 18:00 ` [igt-dev] ✗ GitLab.Pipeline: warning for RPM Test on HEADLESS Patchwork
2022-04-21 18:25 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2022-04-21 22:52 ` [igt-dev] ✓ 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=54f86f76208046e2bbb317aabaeba675@intel.com \
    --to=anshuman.gupta@intel.com \
    --cc=ashutosh.dixit@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=chris.p.wilson@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    /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.