dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Michał Winiarski" <michal.winiarski@intel.com>
To: Mauro Carvalho Chehab <mauro.chehab@linux.intel.com>
Cc: David Gow <davidgow@google.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	igt-dev@lists.freedesktop.org,
	Brendan Higgins <brendan.higgins@linux.dev>,
	linux-kselftest@vger.kernel.org,
	Shuah Khan <skhan@linuxfoundation.org>,
	kunit-dev@googlegroups.com
Subject: Re: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
Date: Mon, 7 Nov 2022 19:38:09 +0100	[thread overview]
Message-ID: <20221107183809.z5ntt6fj5ohs4bnn@nostramo> (raw)
In-Reply-To: <20221103162302.4ba62d72@maurocar-mobl2>

On Thu, Nov 03, 2022 at 04:23:02PM +0100, Mauro Carvalho Chehab wrote:
> Hi,
> 
> I'm facing a couple of issues when testing KUnit with the i915 driver.
> 
> The DRM subsystem and the i915 driver has, for a long time, his own
> way to do unit tests, which seems to be added before KUnit.
> 
> I'm now checking if it is worth start using KUnit at i915. So, I wrote
> a RFC with some patches adding support for the tests we have to be
> reported using Kernel TAP and KUnit.
> 
> There are basically 3 groups of tests there:
> 
> - mock tests - check i915 hardware-independent logic;
> - live tests - run some hardware-specific tests;
> - perf tests - check perf support - also hardware-dependent.
> 
> As they depend on i915 driver, they run only on x86, with PCI
> stack enabled, but the mock tests run nicely via qemu.
> 
> The live and perf tests require a real hardware. As we run them
> together with our CI, which, among other things, test module
> unload/reload and test loading i915 driver with different
> modprobe parameters, the KUnit tests should be able to run as
> a module.

Note that KUnit tests that are doing more of a functional/integration
testing (on "live" hardware) rather than unit testing (where hardware
interactions are mocked) are not very common.
Do we have other KUnit tests like this merged?
Some of the "live tests" are not even that, being more of a pure
hardware tests (e.g. live_workarounds, which is checking whether values
in MMIO regs stick over various HW state transitions).

I'm wondering, is KUnit the right tool for this job?

-Michał

  parent reply	other threads:[~2022-11-07 18:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 15:23 KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL Mauro Carvalho Chehab
2022-11-03 22:43 ` Daniel Latypov
2022-11-04  7:49   ` Mauro Carvalho Chehab
2022-11-04 12:47     ` Mauro Carvalho Chehab
2022-11-04 19:20     ` Daniel Latypov
2022-11-08  1:40       ` Daniel Latypov
2022-11-07 18:38 ` Michał Winiarski [this message]
2022-11-07 23:16   ` Daniel Latypov
2022-11-14 10:59     ` Mauro Carvalho Chehab
2022-11-08  4:30 ` David Gow

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=20221107183809.z5ntt6fj5ohs4bnn@nostramo \
    --to=michal.winiarski@intel.com \
    --cc=brendan.higgins@linux.dev \
    --cc=davidgow@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mauro.chehab@linux.intel.com \
    --cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).