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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF1EEC352A4 for ; Thu, 13 Feb 2020 01:29:12 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id AC56B2467B for ; Thu, 13 Feb 2020 01:29:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC56B2467B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 413536E145; Thu, 13 Feb 2020 01:29:12 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id E64316E145; Thu, 13 Feb 2020 01:29:10 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2020 17:29:10 -0800 X-IronPort-AV: E=Sophos;i="5.70,434,1574150400"; d="scan'208";a="252111786" Received: from dbstims-dev.fm.intel.com ([10.1.27.172]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2020 17:29:09 -0800 From: Dale B Stimson To: igt-dev@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Date: Wed, 12 Feb 2020 17:28:35 -0800 Message-Id: <20200213012840.31472-1-dale.b.stimson@intel.com> X-Mailer: git-send-email 2.25.0 MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH i-g-t v2 0/5] mmio_base via debugfs infrastructure + gem_ctx_isolation 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" v2: - Introduce and use igt_exit_early() so that a failed initialization (in igt_fixture) will not attempt to invoke the per-engine loop. - Initialize mmio_base db inside initial igt_fixture instead of after. - Some additional functions handle NULL input mmio_base db pointer. - Variables mbp and mmio_base initialized to NULL/0 so their values will not be uninitialized for --list-subtests. - Failure to obtain an mmio_base db is now igt_debug instead of igt_warn. This patch series provides infrastructure to allow determination of i915 per-engine mmio_base (which is otherwise sometimes hard to get). The provided method uses debugfs mmio_base information if present. Otherwise, a default determination is provided when possible. Also, gem_ctx_isolation is modified to use the new infrastructure. For example, on TGL, gem_ctx_isolation (without these or similar changes) will fail for subtests that use engine vcs1. The patches in this series are as they are intended to be submitted (subject to comments), except I would like to squash the two gem_ctx_isolation "relative registers" patches into one (as discussed below). Also, function gem_engine_mmio_base_info_dump() could be removed. On 2020-01-27, Chris wilson sent to the ML: [igt-dev] [PATCH i-g-t 1/5] i915: Start putting the mmio_base to wider use [igt-dev] [PATCH i-g-t 2/5] i915/gem_ctx_isolation: Check engine relative registers plus the following, which are not addressed here: [igt-dev] [PATCH i-g-t 3/5] i915: Exercise preemption timeout controls in sysfs [igt-dev] [PATCH i-g-t 4/5] i915: Exercise sysfs heartbeat controls [igt-dev] [PATCH i-g-t 5/5] i915: Exercise timeslice sysfs property This patch list is: i915/gem_mmio_base.c - get mmio_base from debugfs (if possible) i915/gem_ctx_isolation: Check engine relative registers i915/gem_ctx_isolation: Check engine relative registers - Part 2 The first 2020-01-27 patch obtains mmio_base information via sysfs, and depends on a proposed kernel change that would provide the mmio_base information via sysfs. It is unclear when or whether that kernel change will progress. The mmio_base information used by this patch series is available through debugfs now (as of kernel 5.4). If the per-engine mmio_base information is ever added to sysfs, it would be easy to plug that into the infrastructure proposed here as an additional higher-priority source of that information. This submission replaces the first patch (switching from sysfs to debugfs), retains the second 2020-01-27 patch i915/gem_ctx_isolation: Check engine relative registers and has a third patch that modifies the original second patch to support the altered API: i915/gem_ctx_isolation: Check engine relative registers - Part 2 I propose squashing the two gem_ctx_isolation "relative registers" patches into one patch with author == "Chris Wilson" if Chris agrees. Some differences from the 2020-01-27 patches: The mmio_base information is fetched once into local data structures, and is obtained from them thereafter instead of being fetched from the kernel everytime it is wanted. The function that obtains the mmio_base information is called by a particular test that wants it, and returns a handle through which the mmio_base can be requested for any particular engine. These patches introduce new source files lib/i915/gem_mmio_base.c and lib/i915/gem_mmio_base.h. Should the code instead be placed into lib/i915/gem_engine_topology.c? Function gem_engine_mmio_base_info_dump presently exists to dump the mmio_base information to stdout for debugging or informational purposes. This function is not currently called. I presume this function should be removed. Is there any desire to keep it around for future use? The 2020-01-27 patches define function gem_engine_mmio_base() with its first parameter as "fd". The new patches replace the first parameter with the mmio_base object handle. Chris Wilson (1): i915/gem_ctx_isolation: Check engine relative registers Dale B Stimson (4): i915/gem_mmio_base.c - get mmio_base from debugfs (if possible) i915/gem_ctx_isolation: Check engine relative registers - Part 2 lib/igt_core.c - Introduce igt_exit_early() i915/gem_ctx_isolation.c - If initialization fails, exit lib/Makefile.sources | 2 + lib/i915/gem_mmio_base.c | 353 +++++++++++++++++++++++++++++++++ lib/i915/gem_mmio_base.h | 19 ++ lib/igt.h | 1 + lib/igt_core.c | 27 +++ lib/igt_core.h | 1 + lib/meson.build | 1 + tests/i915/gem_ctx_isolation.c | 244 ++++++++++++++--------- 8 files changed, 556 insertions(+), 92 deletions(-) create mode 100644 lib/i915/gem_mmio_base.c create mode 100644 lib/i915/gem_mmio_base.h -- 2.25.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx