From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 82CC8C7EE23 for ; Wed, 7 Jun 2023 23:49:53 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AB37910E576; Wed, 7 Jun 2023 23:49:52 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id AEEC310E571; Wed, 7 Jun 2023 23:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686181789; x=1717717789; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version:content-transfer-encoding; bh=JiAW3d8/XuA2paiW7Sxc5eJTXohwUwzTFJuLsYX5yRQ=; b=YRjjafWskSvrOLJkM58JijmppHja2lOuJ+U+n+86RUsMNrWfrC4e5fuO EYz1i9rYnHmjAIKRHw+L3n+kMoQKu06khG3ieMyR0J05GR5dEmJy+ANS8 aRCj8lbkF8t4xHTGum0mIgWDRDRAjcU9Ahm+XzBU5E4vWH8ruEvizkZjB iRgTA5XlKnQZqEKlOGSL4kZnp0llMrEskiZ/cUPs3ey2RY6kBweX2Cgef xATJXlaXkq9JKAMLDnEfcSxJIYtdfQQWYigxKUfk6gKzU8IU8LUSah+SK 0oHHzS+96Ww3MzilO0zfp5791mbz6Bb8T9xZbHX+6355GnknbNF8Ecs2u g==; X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="336769459" X-IronPort-AV: E=Sophos;i="6.00,225,1681196400"; d="scan'208";a="336769459" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2023 16:49:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10734"; a="833929791" X-IronPort-AV: E=Sophos;i="6.00,225,1681196400"; d="scan'208";a="833929791" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.209.85.43]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jun 2023 16:49:48 -0700 Date: Wed, 07 Jun 2023 16:49:46 -0700 Message-ID: <877csen885.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Belgaumkar, Vinay" In-Reply-To: <6c9e4193-f569-b65d-09ed-9a959ef82274@intel.com> References: <20230606203535.292739-1-vinay.belgaumkar@intel.com> <87bkhrm0xk.wl-ashutosh.dixit@intel.com> <87a5xanaoq.wl-ashutosh.dixit@intel.com> <408f6bd2-66bb-5fc6-345b-f7ed34715a5f@intel.com> <6c9e4193-f569-b65d-09ed-9a959ef82274@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] tests/i915_pm_freq_api: Add a suspend subtest X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: igt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 07 Jun 2023 16:40:53 -0700, Belgaumkar, Vinay wrote: > > > On 6/7/2023 4:11 PM, Belgaumkar, Vinay wrote: > > > > On 6/7/2023 3:56 PM, Dixit, Ashutosh wrote: > >> On Wed, 07 Jun 2023 15:31:33 -0700, Belgaumkar, Vinay wrote: > >>> On 6/7/2023 2:12 PM, Dixit, Ashutosh wrote: > >>>> On Tue, 06 Jun 2023 13:35:35 -0700, Vinay Belgaumkar wrote: > >>>> Hi Vinay, > >>>> > >>>>> Verify that SLPC API works as expected after a suspend. > >>>>> > >>>>> Signed-off-by: Vinay Belgaumkar > >>>>> --- > >>>>> =A0=A0 tests/i915/i915_pm_freq_api.c | 30 +++++++++++++++++++++++++= +++++ > >>>>> =A0=A0 1 file changed, 30 insertions(+) > >>>>> > >>>>> diff --git a/tests/i915/i915_pm_freq_api.c > >>>>> b/tests/i915/i915_pm_freq_api.c > >>>>> index 9005cd220..f35f1f8e0 100644 > >>>>> --- a/tests/i915/i915_pm_freq_api.c > >>>>> +++ b/tests/i915/i915_pm_freq_api.c > >>>>> @@ -18,6 +18,9 @@ > >>>>> =A0=A0=A0 * > >>>>> =A0=A0=A0 * SUBTEST: freq-reset > >>>>> =A0=A0=A0 * Description: Test basic freq API works after a reset > >>>>> + * > >>>>> + * SUBTEST: freq-suspend > >>>>> + * Description: Test basic freq API works after a runtime suspend > >>>>> =A0=A0=A0 */ > >>>>> > >>>>> =A0=A0 IGT_TEST_DESCRIPTION("Test SLPC freq API"); > >>>>> @@ -99,6 +102,24 @@ static void test_reset(int i915, int dirfd, int > >>>>> gt) > >>>>> =A0=A0=A0=A0igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) =3D=3D rpn= ); > >>>>> =A0=A0 } > >>>>> > >>>>> +static void test_suspend(int i915, int dirfd, int gt) > >>>>> +{ > >>>>> +=A0=A0=A0 uint32_t rpn =3D get_freq(dirfd, RPS_RPn_FREQ_MHZ); > >>>>> + > >>>>> +=A0=A0=A0 igt_assert(set_freq(dirfd, RPS_MIN_FREQ_MHZ, rpn) > 0); > >>>>> +=A0=A0=A0 igt_assert(set_freq(dirfd, RPS_MAX_FREQ_MHZ, rpn) > 0); > >>>>> +=A0=A0=A0 usleep(ACT_FREQ_LATENCY_US); > >>>>> +=A0=A0=A0 igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) =3D=3D rpn); > >>>>> +=A0=A0=A0 igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) =3D=3D rpn); > >>>>> + > >>>>> +=A0=A0=A0 /* Manually trigger a suspend */ > >>>>> +=A0=A0=A0 igt_system_suspend_autoresume(SUSPEND_STATE_S3, > >>>>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SU= SPEND_TEST_NONE); > >>>>> + > >>>>> +=A0=A0=A0 igt_assert(get_freq(dirfd, RPS_MIN_FREQ_MHZ) =3D=3D rpn); > >>>>> +=A0=A0=A0 igt_assert(get_freq(dirfd, RPS_MAX_FREQ_MHZ) =3D=3D rpn); > >>>> I am wondering what the purpose/value of this test (and also > >>>> "freq-reset") > >>>> is?=A0 How can the "set" min/max set freq (which are just input > >>>> settings) > >>>> change whether or not there is a suspend/resume or a reset? Especial= ly > >>>> when > >>>> we just return cached min/max values from i915? > >>> It is mainly checking that we don't smother the softlimit during a > >>> reset or > >>> suspend flow. > >> How can softlimit which is a ordinary variable in memory get clobbered > >> by > >> suspend resume? > > It shouldn't, but funnier things have happened. Anyways, I can add a check > for cur_freq and ensure that is at min. That will prove we applied the so= ft > limit after suspend. > > Thanks, > > Vinay. > > >> > >>> In addition, it also tests the read/write interface works as expected > >>> after those events. > >> There's no write. Sorry, but I'm not convinced. There should be some > >> more > >> meat to the test. > > There are writes in the IGT fixture after the test completes. This should also be in an exit handler, not in the fixture? See gem_ctx_freq e.g. Thanks. -- Ashutosh > >> > >> Maybe we can write a test which will check /all/ sysfs values are the > >> same > >> after a suspend resume cycle? Why do only these specific ones have to = be > >> checked? > > > > This test is specific to the freq api, hence just min/max entries. > > > > Thanks, > > > > Vinay. > > > >> > >> Thanks. > >> -- > >> Ashutosh > >> > >> > >>> Thanks, > >>> > >>> Vinay. > >>> > >>>> Thanks. > >>>> -- > >>>> Ashutosh > >>>> > >>>> > >>>>> +} > >>>>> + > >>>>> =A0=A0 igt_main > >>>>> =A0=A0 { > >>>>> =A0=A0=A0=A0int i915 =3D -1; > >>>>> @@ -143,6 +164,15 @@ igt_main > >>>>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 test_reset(i915, dirf= d, gt); > >>>>> =A0=A0=A0=A0} > >>>>> > >>>>> +=A0=A0=A0 igt_describe("Test basic freq API works after suspend"); > >>>>> +=A0=A0=A0 igt_subtest_with_dynamic_f("freq-suspend") { > >>>>> +=A0=A0=A0=A0=A0=A0=A0 int dirfd, gt; > >>>>> + > >>>>> +=A0=A0=A0=A0=A0=A0=A0 for_each_sysfs_gt_dirfd(i915, dirfd, gt) > >>>>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 igt_dynamic_f("gt%u", gt) > >>>>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 test_suspend(i915, d= irfd, gt); > >>>>> +=A0=A0=A0 } > >>>>> + > >>>>> =A0=A0=A0=A0igt_fixture { > >>>>> =A0=A0=A0=A0=A0=A0=A0 int dirfd, gt; > >>>>> =A0=A0=A0=A0=A0=A0=A0 /* Restore frequencies */ > >>>>> -- > >>>>> 2.38.1 > >>>>>