Re: [PATCH] docs: document python version used for compilation
Em Fri, 10 May 2024 13:39:17 +0300 Dmitry Baryshkov escreveu: > On Fri, 10 May 2024 at 13:09, Jani Nikula wrote: > > > > On Fri, 10 May 2024, Mauro Carvalho Chehab wrote: > > > Em Fri, 10 May 2024 11:08:38 +0300 > > > Jani Nikula escreveu: > > > > > >> On Thu, 09 May 2024, Dmitry Baryshkov > > >> wrote: > > >> > The drm/msm driver had adopted using Python3 script to generate > > >> > register > > >> > header files instead of shipping pre-generated header files. Document > > >> > the minimal Python version supported by the script. > > >> > > > >> > Signed-off-by: Dmitry Baryshkov > > >> > --- > > >> > Documentation/process/changes.rst | 1 + > > >> > 1 file changed, 1 insertion(+) > > >> > > > >> > diff --git a/Documentation/process/changes.rst > > >> > b/Documentation/process/changes.rst > > >> > index 5685d7bfe4d0..8d225a9f65a2 100644 > > >> > --- a/Documentation/process/changes.rst > > >> > +++ b/Documentation/process/changes.rst > > >> > @@ -63,6 +63,7 @@ cpio any cpio > > >> > --version > > >> > GNU tar1.28 tar --version > > >> > gtags (optional) 6.6.5gtags --version > > >> > mkimage (optional) 2017.01 mkimage --version > > >> > +Python (optional) 3.5.xpython3 --version > > >> > > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in > > >> using anything older than the oldest supported version of Python, > > >> i.e. 3.8 at this time? > > > > > > What's the point of breaking compilation with on older distros? > > > The idea of minimal versions here is to specify the absolute minimum > > > version that it is required for the build to happen. If 3.5 is > > > the minimal one, then be it. > > > > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should > > at least be aware *why* we'd be sticking to old versions. > > From my side, the 3.5 was chosen basing on the previous feedback from > Jon Hunter: > https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonath...@nvidia.com/ Patch there seems small/simple enough if it is all it takes for 3.5. Yet, it would be nice to hear from Jon Hunter about the rationale for 3.5 support (if any). > > Minimum versions here also means sticking to features available in said > > versions, for Python just as well as for GCC or any other tool. That's > > not zero cost. > > > > I guess there are two angles here too. The absolute minimum version > > currently required, and the, uh, maximum the minimum version can be > > safely bumped to. Say, you want to use a feature not available in the > > current minimum, how far up can you bump the version to? > > > > Could we define and document the criteria (e.g. based on distros as you > > suggest below) so we don't have to repeat the discussion? Agreed. While we should not bump version randomly, defining a criteria about when we should update the requirement sounds a great idea. For me, the criteria is: - the minimal version shall be at least the minimal one required for the Kernel to build at the most used LTS distros that are not EOL, e. g.: Debian, openSUSE/SUSE, CentOS/RHEL and Ubuntu LTS[1]. [1] In practice, Ubuntu LTS usually has a python version newer than Debian LTS, and CentOS versions are identical to RHEL ones, so I guess checking for Debian, openSUSE, SUSE and RHEL should be enough. Regards, Mauro
Re: [PATCH] docs: document python version used for compilation
Em Fri, 10 May 2024 13:39:17 +0300 Dmitry Baryshkov escreveu: > On Fri, 10 May 2024 at 13:09, Jani Nikula wrote: > > > > On Fri, 10 May 2024, Mauro Carvalho Chehab wrote: > > > Em Fri, 10 May 2024 11:08:38 +0300 > > > Jani Nikula escreveu: > > > > > >> On Thu, 09 May 2024, Dmitry Baryshkov > > >> wrote: > > >> > The drm/msm driver had adopted using Python3 script to generate > > >> > register > > >> > header files instead of shipping pre-generated header files. Document > > >> > the minimal Python version supported by the script. > > >> > > > >> > Signed-off-by: Dmitry Baryshkov > > >> > --- > > >> > Documentation/process/changes.rst | 1 + > > >> > 1 file changed, 1 insertion(+) > > >> > > > >> > diff --git a/Documentation/process/changes.rst > > >> > b/Documentation/process/changes.rst > > >> > index 5685d7bfe4d0..8d225a9f65a2 100644 > > >> > --- a/Documentation/process/changes.rst > > >> > +++ b/Documentation/process/changes.rst > > >> > @@ -63,6 +63,7 @@ cpio any cpio > > >> > --version > > >> > GNU tar1.28 tar --version > > >> > gtags (optional) 6.6.5gtags --version > > >> > mkimage (optional) 2017.01 mkimage --version > > >> > +Python (optional) 3.5.xpython3 --version > > >> > > >> Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in > > >> using anything older than the oldest supported version of Python, > > >> i.e. 3.8 at this time? > > > > > > What's the point of breaking compilation with on older distros? > > > The idea of minimal versions here is to specify the absolute minimum > > > version that it is required for the build to happen. If 3.5 is > > > the minimal one, then be it. > > > > AFAICT 3.5 was an arbitrary rather than a deliberate choice. We should > > at least be aware *why* we'd be sticking to old versions. > > From my side, the 3.5 was chosen basing on the previous feedback from > Jon Hunter: > https://lore.kernel.org/dri-devel/20240412165407.42163-1-jonath...@nvidia.com/ > > After checking distros that I can easily use, I don't think I will be > able to test the script with Python versions earlier than 3.7.3 > (Debian oldoldstable). > I can try setting up Debian stretch (old-old-old-stable), which has > Python 3.5 and so cover the needs of Jon. Fedora 40 supports version 3.6 and above (plus 2.7): https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html You could do something similar with Ubuntu/Debian: https://askubuntu.com/questions/682869/how-do-i-install-a-different-python-version-using-apt-get Once an old version is installed, you can enable it with: $ python3.6 -m venv v3.6 # create the environment $ . v3.6/bin/activate Then, if needed, install whatever dependencies are needed with pip, inside the venv (for instance if you want to also test Sphinx, you can install it there via pip). I guess it should be possible to use a similar venv procedure with older versions, but you may need to compile it from the sources if you don't have binaries available for your distro. Regards, Mauro
Re: [PATCH] docs: document python version used for compilation
Em Fri, 10 May 2024 11:08:38 +0300 Jani Nikula escreveu: > On Thu, 09 May 2024, Dmitry Baryshkov wrote: > > The drm/msm driver had adopted using Python3 script to generate register > > header files instead of shipping pre-generated header files. Document > > the minimal Python version supported by the script. > > > > Signed-off-by: Dmitry Baryshkov > > --- > > Documentation/process/changes.rst | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/process/changes.rst > > b/Documentation/process/changes.rst > > index 5685d7bfe4d0..8d225a9f65a2 100644 > > --- a/Documentation/process/changes.rst > > +++ b/Documentation/process/changes.rst > > @@ -63,6 +63,7 @@ cpio any cpio --version > > GNU tar1.28 tar --version > > gtags (optional) 6.6.5gtags --version > > mkimage (optional) 2017.01 mkimage --version > > +Python (optional) 3.5.xpython3 --version > > Python 3.5 reached end-of-life 3½ years ago [1]. What's the point in > using anything older than the oldest supported version of Python, > i.e. 3.8 at this time? What's the point of breaking compilation with on older distros? The idea of minimal versions here is to specify the absolute minimum version that it is required for the build to happen. If 3.5 is the minimal one, then be it. - Now, a criteria is needed to raise the minimal version. IMO, the minimal version shall be at least the minimal one present on most used LTS distros that are not EOL. I would look for at least 4 such distros: - Debian Looking at https://wiki.debian.org/LTS, Debian 10 EOL will be on June, 2024. Looking at: https://distrowatch.com/table.php?distribution=debian Debian 10 uses python 3.7.3. - Looking at Distrowatch for openSUSE Leap 15.5, it uses Python 3.6.15 and has an EOL schedule for Dec, 2024. - RHEL 8.9 uses a bigger version than those two - 3.11.5 - again looking at Distrowatch to check it. - SLES 15 SP4 and above uses Python 3.11, according with: https://www.suse.com/c/python-3-11-stack-for-suse-linux-enterprise-15/ From the above, IMO kernel shall support building with Python 3.6 at least until the end of this year. Regards, Mauro
Re: [PATCH v0 04/14] media: au0828: Make I2C terminology more inclusive
Em Fri, 29 Mar 2024 17:00:28 +
Easwar Hariharan escreveu:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of
> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
> in the specification.
>
> Compile tested, no functionality changes intended
Current media drivers are perfectly fine with the current terminology.
None of them implement the above new standards.
Please drop patches for current stuff under drivers/media.
Regards,
Mauro
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Signed-off-by: Easwar Hariharan
> ---
> drivers/media/usb/au0828/au0828-i2c.c | 4 ++--
> drivers/media/usb/au0828/au0828-input.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/au0828/au0828-i2c.c
> b/drivers/media/usb/au0828/au0828-i2c.c
> index 749f90d73b5b..3e66d42bf134 100644
> --- a/drivers/media/usb/au0828/au0828-i2c.c
> +++ b/drivers/media/usb/au0828/au0828-i2c.c
> @@ -23,7 +23,7 @@ MODULE_PARM_DESC(i2c_scan, "scan i2c bus at insmod time");
> #define I2C_WAIT_DELAY 25
> #define I2C_WAIT_RETRY 1000
>
> -static inline int i2c_slave_did_read_ack(struct i2c_adapter *i2c_adap)
> +static inline int i2c_client_did_read_ack(struct i2c_adapter *i2c_adap)
> {
> struct au0828_dev *dev = i2c_adap->algo_data;
> return au0828_read(dev, AU0828_I2C_STATUS_201) &
> @@ -35,7 +35,7 @@ static int i2c_wait_read_ack(struct i2c_adapter *i2c_adap)
> int count;
>
> for (count = 0; count < I2C_WAIT_RETRY; count++) {
> - if (!i2c_slave_did_read_ack(i2c_adap))
> + if (!i2c_client_did_read_ack(i2c_adap))
> break;
> udelay(I2C_WAIT_DELAY);
> }
> diff --git a/drivers/media/usb/au0828/au0828-input.c
> b/drivers/media/usb/au0828/au0828-input.c
> index 3d3368202cd0..98a57b6e02e2 100644
> --- a/drivers/media/usb/au0828/au0828-input.c
> +++ b/drivers/media/usb/au0828/au0828-input.c
> @@ -30,7 +30,7 @@ struct au0828_rc {
> int polling;
> struct delayed_work work;
>
> - /* i2c slave address of external device (if used) */
> + /* i2c client address of external device (if used) */
> u16 i2c_dev_addr;
>
> int (*get_key_i2c)(struct au0828_rc *ir);
Re: [PATCH i-g-t 2/2] lib/kunit: Execute test cases synchronously
On Mon, 6 Nov 2023 10:59:38 +0100
Janusz Krzysztofik wrote:
> Up to now we've been loading a KUnit test module in background and parsing
> in parallel its KTAP output with results from all the module's test cases.
> However, recent KUnit implementation is capable of executing only those
> test cases that match a user filter specified on test module load.
>
> Stop loading the KUnit test module in background once per the whole
> subtest. Instead, load the module on each dynamic sub-subtest execution
> with a filter that selects a specific test case and wait for its
> completion. If successful and no kernel taint then parse the whole KTAP
> report it has produced and translate it to IGT result of the sub-subtest.
>
> With that in place, we no longer need to skip the whole subtest on a
> failure from module loading or KTAP reading or parsing. Since such event
> is now local to execution of an individual test case, only fail its
> corresponding dynamic sub-subtests and continue with subsequent ones.
> However, still omit execution of subsequent test cases once the kernel
> gets tainted.
The main reason why loading the module in background was done in the
first place was because if there is a BUG() or PANIC() or gpu hang
while executing KUnit, the dmesg KUnit parser was not producing anything,
and were blocking normal dmesg parsing by IGT runner. While I didn't
test such changes, we need to check what will be there at the JSON file
when IGT resume run is enabled, and those kind of bugs are triggered.
-
Yet, let's take one step back, as IMO this may not solve the issues.
See, when you say:
> only fail its
> corresponding dynamic sub-subtests and continue with subsequent ones.
When a normal failure happens on KUnit, other tests will be executed. This
is the normal KUnit behavior. So, except if we're doing something wrong on
Xe or KMS tests, the other subtests after the failure will be tested.
However, if such failure is calling BUG_ON(), then the driver will be
tainted, and will prevent module unload. On such case, it doesn't matter
if tests are executed in batch or not: IGT will try to unload the
KUnit module but it will fail due to BUG_ON() behavior.
Also, doing module unload/reload every time will bring some performance penalty,
as loading/unloading KUnit for every individual test case will increase the
time to execute such tests.
Ok, if are there filtering rules on IGT limiting what subtests will be
executed, then be it. But for normal execution, I can't see why we
would be adding a performance penalty.
Regards,
Mauro
>
> Signed-off-by: Janusz Krzysztofik
> ---
> lib/igt_kmod.c | 135 -
> 1 file changed, 31 insertions(+), 104 deletions(-)
>
> diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> index 37591b7389..5bd8f56088 100644
> --- a/lib/igt_kmod.c
> +++ b/lib/igt_kmod.c
> @@ -960,6 +960,7 @@ static int kunit_kmsg_get_results(struct igt_list_head
> *results,
> {
> char *suite_name = NULL, *case_name = NULL;
> struct igt_ktap_results *ktap;
> + unsigned long taints;
> int flags, err;
>
> if (igt_debug_on(tst->kmsg < 0))
> @@ -998,6 +999,11 @@ static int kunit_kmsg_get_results(struct igt_list_head
> *results,
> if (err)
> goto out_kmod_unload;
>
> + if (igt_debug_on(igt_kernel_tainted())) {
> + err = -ENOTRECOVERABLE;
> + goto out_remove_module;
> + }
> +
> ktap = igt_ktap_alloc(results);
> if (igt_debug_on(!ktap)) {
> err = -ENOMEM;
> @@ -1203,84 +1209,43 @@ static void __igt_kunit(struct igt_ktest *tst,
> const char *opts,
> struct igt_list_head *tests)
> {
> - struct modprobe_data modprobe = { tst->kmod, opts, 0, pthread_self(), };
> - char *suite_name = NULL, *case_name = NULL;
> - struct igt_ktap_result *t, *r = NULL;
> - struct igt_ktap_results *ktap;
> - pthread_mutexattr_t attr;
> - IGT_LIST_HEAD(results);
> - int ret = -EINPROGRESS;
> - unsigned long taints;
> -
> - igt_skip_on(lseek(tst->kmsg, 0, SEEK_END) < 0);
> -
> - ktap = igt_ktap_alloc();
> - igt_require(ktap);
> + struct igt_ktap_result *t;
>
> igt_list_for_each_entry(t, tests, link) {
> + char *suite_name = NULL, *case_name = NULL;
> + IGT_LIST_HEAD(results);
> + unsigned long taints;
> +
> igt_dynamic_f("%s%s%s",
> strcmp(t->suite_name, name) ? t->suite_name : "",
> strcmp(t->suite_name, name) ? "-" : "",
> t->case_name) {
> + struct igt_ktap_result *r = NULL;
> + char filter[1024];
> + int expect = 2;
>
> - if (!modprobe.thread) {
> - igt_assert_eq(pthread_mutexattr_init(), 0);
> -
Re: [PATCH 0/2] Add support for inlined documentation for kunit and kselftests
Em Tue, 03 Oct 2023 11:00:20 -0600 Jonathan Corbet escreveu: > Mauro Carvalho Chehab writes: > > > This is a follow-up of the discussions taken here: > > > > > > https://lore.kernel.org/linux-doc/20230704132812.02ba97ba@maurocar-mobl2/T/#t > > > > I sent a previous version as RFC. This is basically what we had there, with > > some > > improvements at test_list.py. > > > > It adds a new extension that allows documenting tests using the same tool > > we're > > using for DRM unit tests at IGT GPU tools: > > https://gitlab.freedesktop.org/drm/igt-gpu-tools. > > > > While kernel-doc has provided documentation for in-lined functions/struct > > comments, > > it was not meant to document tests. > > > > Tests need to be grouped by the test functions. It should also be possible > > to produce > > other outputs from the documentation, to integrate it with test suites. For > > instance, > > Internally at Intel, we use the comments to generate DOT files > > hierarchically grouped > > per feature categories. > > > > This is meant to be an initial series to start documenting kunit. > > I've played with this a bit...a couple of quick impressions: > > - That's quite a chunk of Python code to be adding. I've not yet had > the chance to read it through properly, will hopefully be able to do > so soon. A bit more commenting would not have gone amiss here... I'll try to add more comments when respin this series. I guess I should also add a documentation similar to the one I wrote for IGT [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/master/docs/test_documentation.md?ref_type=heads#documenting-tests-via-testplan [1] this document is specific for the way IGT uses it; I'll write something similar to it considering the names we've agreed for KUnit. > > - I kind of think that this should go under dev-tools rather than being > a new top-level directory. Is there a reason not to put it there? No particular reason. I'll change it to be under dev-tools/tests at the next submission. Should I wait for you to take a look at patch 1/2 before sending a new version? Regards, Mauro
Re: [PATCH RFC 2/2] drm: add documentation for drm_buddy_test kUnit test
Hi Rae, Em Thu, 13 Jul 2023 17:31:19 -0400 Rae Moar escreveu: > On Wed, Jul 12, 2023 at 10:29 AM Mauro Carvalho Chehab > wrote: > > > As an example for the new documentation tool, add a documentation > > for drm_buddy_test. > > > > I opted to place this on a completely different directory, in order > > to make easier to test the feature with: > > > > $ make SPHINXDIRS="tests" htmldocs > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH RFC 0/2] at: > > https://lore.kernel.org/all/cover.1689171160.git.mche...@kernel.org/ > > > > Documentation/index.rst| 2 +- > > Documentation/tests/index.rst | 6 ++ > > Documentation/tests/kunit.rst | 5 + > > drivers/gpu/drm/tests/drm_buddy_test.c | 12 > > 4 files changed, 24 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/tests/index.rst > > create mode 100644 Documentation/tests/kunit.rst > > > > diff --git a/Documentation/index.rst b/Documentation/index.rst > > index 9dfdc826618c..80a6ce14a61a 100644 > > --- a/Documentation/index.rst > > +++ b/Documentation/index.rst > > @@ -60,7 +60,7 @@ Various other manuals with useful information for all > > kernel developers. > > fault-injection/index > > livepatch/index > > rust/index > > - > > + test/index > > > > User-oriented documentation > > === > > diff --git a/Documentation/tests/index.rst b/Documentation/tests/index.rst > > new file mode 100644 > > index ..bfc39eb5c0aa > > --- /dev/null > > +++ b/Documentation/tests/index.rst > > @@ -0,0 +1,6 @@ > > + > > +Kunit documentation test > > + > > + > > +.. toctree:: > > + kunit > > diff --git a/Documentation/tests/kunit.rst b/Documentation/tests/kunit.rst > > new file mode 100644 > > index ..6ffc151988a0 > > --- /dev/null > > +++ b/Documentation/tests/kunit.rst > > @@ -0,0 +1,5 @@ > > +Kunit tests > > +--- > > + > > +.. include-test:: drivers/gpu/drm/tests/drm_buddy_test.c > > + > > diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c > > b/drivers/gpu/drm/tests/drm_buddy_test.c > > index 09ee6f6af896..dd6c5afd6cd6 100644 > > --- a/drivers/gpu/drm/tests/drm_buddy_test.c > > +++ b/drivers/gpu/drm/tests/drm_buddy_test.c > > @@ -737,6 +737,18 @@ static int drm_buddy_suite_init(struct kunit_suite > > *suite) > > return 0; > > } > > > > +/** > > + * KTEST_SUITE: set of tests for drm buddy alloc > > + * Scope: drm subsystem > > + * Mega feature: drm > > + * Feature: buddy_alloc > > + * > > + * KTEST_TEST: drm_test_buddy_alloc_%s > > + * Description: Run DRM buddy allocation %arg[1] test > > + * > > + * arg[1].values: limit, range, optimistic, smoke, pathological > > + */ > > > Hi! > > This is such a cool patch series. I just have a few comments related to the > output. Thank you for your comments! Sorry for not answering earlier. I took some vacations and this series ended sleeping over other tasks on my todo list. Also, before sending another version, I wanted to have the test_list.py changes to make it generic enough to be merged on IGT, to avoid having a fork of it. Those got merged today. > In the html output the tests are listed as: > ktest@drm_buddy_test@… > > I wonder if instead of using the file name of “drm_buddy_test” this could > possibly be the suite name, “drm_buddy”, as this is what users will call > when using kunit.py to run the tests. Although "drm_buddy_test" is also the > module name so I don't mind it too much. But in the future the file name > and module name are not guaranteed to be the same for other tests. > > Most preferably, there would be a reference to the kunit suite name, file > name, and the module name. I guess it shouldn't be hard to do such change in a way that it won't affect its usage on IGT. We need to define what would be the best pattern. As this can be used for both kunit and selftests, I would place kunit at the beginning. Currently, we're using: kunit@@ Some possible patterns would be: kunit@@@ kunit kunit@@@ Would do you think it would work best? > This may be difficult to implement as these can all differ. I am currently > working on the KUnit Attribute framework which saves the mod
[PATCH 2/2] drm: add documentation for drm_buddy_test kUnit test
As an example for the new documentation tool, add a documentation
for drm_buddy_test.
I opted to place this on a completely different directory, in order
to make easier to test the feature with:
$ make SPHINXDIRS="tests" htmldocs
Acked-by: Christian König
Reviewed-by: Arunpravin Paneer Selvam
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/index.rst| 2 +-
Documentation/tests/index.rst | 6 ++
Documentation/tests/kunit.rst | 5 +
drivers/gpu/drm/tests/drm_buddy_test.c | 12
4 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 Documentation/tests/index.rst
create mode 100644 Documentation/tests/kunit.rst
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 9dfdc826618c..80a6ce14a61a 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -60,7 +60,7 @@ Various other manuals with useful information for all kernel
developers.
fault-injection/index
livepatch/index
rust/index
-
+ test/index
User-oriented documentation
===
diff --git a/Documentation/tests/index.rst b/Documentation/tests/index.rst
new file mode 100644
index ..bfc39eb5c0aa
--- /dev/null
+++ b/Documentation/tests/index.rst
@@ -0,0 +1,6 @@
+
+Kunit documentation test
+
+
+.. toctree::
+ kunit
diff --git a/Documentation/tests/kunit.rst b/Documentation/tests/kunit.rst
new file mode 100644
index ..6ffc151988a0
--- /dev/null
+++ b/Documentation/tests/kunit.rst
@@ -0,0 +1,5 @@
+Kunit tests
+---
+
+.. include-test:: drivers/gpu/drm/tests/drm_buddy_test.c
+
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 09ee6f6af896..dd6c5afd6cd6 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -737,6 +737,18 @@ static int drm_buddy_suite_init(struct kunit_suite *suite)
return 0;
}
+/**
+ * KTEST_SUITE: set of tests for drm buddy alloc
+ * Scope: drm subsystem
+ * Mega feature: drm
+ * Feature: buddy_alloc
+ *
+ * KTEST_TEST: drm_test_buddy_alloc_%s
+ * Description: Run DRM buddy allocation %arg[1] test
+ *
+ * arg[1].values: limit, range, optimistic, smoke, pathological
+ */
+
static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_limit),
KUNIT_CASE(drm_test_buddy_alloc_range),
--
2.41.0
[PATCH 0/2] Add support for inlined documentation for kunit and kselftests
This is a follow-up of the discussions taken here: https://lore.kernel.org/linux-doc/20230704132812.02ba97ba@maurocar-mobl2/T/#t I sent a previous version as RFC. This is basically what we had there, with some improvements at test_list.py. It adds a new extension that allows documenting tests using the same tool we're using for DRM unit tests at IGT GPU tools: https://gitlab.freedesktop.org/drm/igt-gpu-tools. While kernel-doc has provided documentation for in-lined functions/struct comments, it was not meant to document tests. Tests need to be grouped by the test functions. It should also be possible to produce other outputs from the documentation, to integrate it with test suites. For instance, Internally at Intel, we use the comments to generate DOT files hierarchically grouped per feature categories. This is meant to be an initial series to start documenting kunit. It comes with a documenation for a kunit suite from drm at drm_buddy_test.c. My plan is that, once we get this merged, start documenting other unit tests and work to add extra requirements at the tool needed by Linux Kernel. On this series, we have: - patch 1: adds test_list.py - which is identical to the file with the same name I developed for IGT tree; - patch 2: adds test documentation from a single DRM kunit file (drm_buddy_test.c). Mauro Carvalho Chehab (2): docs: add support for documenting kUnit and kSelftests drm: add documentation for drm_buddy_test kUnit test Documentation/conf.py |2 +- Documentation/index.rst|2 +- Documentation/sphinx/test_kdoc.py | 108 ++ Documentation/sphinx/test_list.py | 1314 Documentation/tests/index.rst |6 + Documentation/tests/kunit.rst |5 + drivers/gpu/drm/tests/drm_buddy_test.c | 12 + 7 files changed, 1447 insertions(+), 2 deletions(-) create mode 100755 Documentation/sphinx/test_kdoc.py create mode 100644 Documentation/sphinx/test_list.py create mode 100644 Documentation/tests/index.rst create mode 100644 Documentation/tests/kunit.rst -- 2.41.0
Re: [PATCH 0/4] Invalidate TLB cache for all GT's
On 8/1/23 16:19, Andi Shyti wrote: Hi, This series revisits a once-trendy topic: TLB invalidation support for multi-gt. It's a theme that's been passed around and reshaped by several of us. I've filtered out most of the original changes from this series, initially sent by Mauro [1]. His ideas were inspired by some changes from Chris, who in turn was inspired by a change from me[2], all of which stemmed from offline talks by Chris (it's like a game of inspiration tag!). What I've done is simply rebase and refactor the patches, focusing solely on the changes needed for multi-gt TLB invalidation in MMIO memory. The result is a leaner, more targeted proposal. Series look good to me. Feel free to add my R-B to the patches I didn't sign already. Reviewed-by: Mauro Carvalho Chehab Other patches from the original series might follow. Thanks, Andi [1] https://patchwork.freedesktop.org/series/106293/ [2] https://patchwork.freedesktop.org/series/103831/ Andi Shyti (2): i915/drm/gt: Move the gt defines in the gt directory drm/i915: Remove unnecessary include Chris Wilson (2): drm/i915/gt: Move TLB invalidation to its own file drm/i915: Invalidate the TLBs on each GT drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c | 15 +- drivers/gpu/drm/i915/gt/intel_gt.c| 140 +-- drivers/gpu/drm/i915/gt/intel_gt.h| 12 -- drivers/gpu/drm/i915/gt/intel_gt_defines.h| 11 ++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 4 +- drivers/gpu/drm/i915/gt/intel_tlb.c | 159 ++ drivers/gpu/drm/i915/gt/intel_tlb.h | 29 drivers/gpu/drm/i915/gt/selftest_tlb.c| 3 +- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_vma.c | 15 +- 12 files changed, 231 insertions(+), 163 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_defines.h create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h
Re: [PATCH RFC 2/2] drm: add documentation for drm_buddy_test kUnit test
Em Wed, 12 Jul 2023 18:03:00 +0300
Jani Nikula escreveu:
> On Wed, 12 Jul 2023, Mauro Carvalho Chehab wrote:
> > diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
> > b/drivers/gpu/drm/tests/drm_buddy_test.c
> > index 09ee6f6af896..dd6c5afd6cd6 100644
> > --- a/drivers/gpu/drm/tests/drm_buddy_test.c
> > +++ b/drivers/gpu/drm/tests/drm_buddy_test.c
> > @@ -737,6 +737,18 @@ static int drm_buddy_suite_init(struct kunit_suite
> > *suite)
> > return 0;
> > }
> >
> > +/**
> > + * KTEST_SUITE: set of tests for drm buddy alloc
> > + * Scope: drm subsystem
> > + * Mega feature: drm
> > + * Feature: buddy_alloc
> > + *
> > + * KTEST_TEST: drm_test_buddy_alloc_%s
> > + * Description: Run DRM buddy allocation %arg[1] test
> > + *
> > + * arg[1].values: limit, range, optimistic, smoke, pathological
> > + */
> > +
>
> "/**" indicates a kernel-doc comment, and this is not a kernel-doc
> comment.
>
> $ scripts/kernel-doc -none drivers/gpu/drm/tests/drm_buddy_test.c
> drivers/gpu/drm/tests/drm_buddy_test.c:752: warning: cannot understand
> function prototype: 'struct kunit_case drm_buddy_tests[] = '
>
> Nowadays kernel-doc is part of W=1 builds.
True. I already told it at patch 0. I opted to not add a patch for it on this
RFC series, to make it simpler. A simple logic at kernel-doc is enough to
tell its state machine to ignore blocks that contain the KTEST_\w+: pattern:
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index d0116c6939dc..bf386460691f 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -259,6 +259,7 @@ my $doc_sect = $doc_com .
'\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:([^:].*)?$';
my $doc_content = $doc_com_body . '(.*)';
my $doc_block = $doc_com . 'DOC:\s*(.*)?';
+my $ktest_block = $doc_com . 'KTEST_\w+:\s*(.*)?';
my $doc_inline_start = '^\s*/\*\*\s*$';
my $doc_inline_sect = '\s*\*\s*(@\s*[\w][\w\.]*\s*):(.*)';
my $doc_inline_end = '^\s*\*/\s*$';
@@ -2015,6 +2016,10 @@ sub process_name($$) {
my $file = shift;
my $descr;
+if (/$ktest_block/o) {
+ $state = STATE_NORMAL;
+ return;
+}
if (/$doc_block/o) {
$state = STATE_DOCBLOCK;
$contents = "";
Thanks,
Mauro
[PATCH RFC 2/2] drm: add documentation for drm_buddy_test kUnit test
As an example for the new documentation tool, add a documentation
for drm_buddy_test.
I opted to place this on a completely different directory, in order
to make easier to test the feature with:
$ make SPHINXDIRS="tests" htmldocs
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC 0/2] at:
https://lore.kernel.org/all/cover.1689171160.git.mche...@kernel.org/
Documentation/index.rst| 2 +-
Documentation/tests/index.rst | 6 ++
Documentation/tests/kunit.rst | 5 +
drivers/gpu/drm/tests/drm_buddy_test.c | 12
4 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 Documentation/tests/index.rst
create mode 100644 Documentation/tests/kunit.rst
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 9dfdc826618c..80a6ce14a61a 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -60,7 +60,7 @@ Various other manuals with useful information for all kernel
developers.
fault-injection/index
livepatch/index
rust/index
-
+ test/index
User-oriented documentation
===
diff --git a/Documentation/tests/index.rst b/Documentation/tests/index.rst
new file mode 100644
index ..bfc39eb5c0aa
--- /dev/null
+++ b/Documentation/tests/index.rst
@@ -0,0 +1,6 @@
+
+Kunit documentation test
+
+
+.. toctree::
+ kunit
diff --git a/Documentation/tests/kunit.rst b/Documentation/tests/kunit.rst
new file mode 100644
index ..6ffc151988a0
--- /dev/null
+++ b/Documentation/tests/kunit.rst
@@ -0,0 +1,5 @@
+Kunit tests
+---
+
+.. include-test:: drivers/gpu/drm/tests/drm_buddy_test.c
+
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 09ee6f6af896..dd6c5afd6cd6 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -737,6 +737,18 @@ static int drm_buddy_suite_init(struct kunit_suite *suite)
return 0;
}
+/**
+ * KTEST_SUITE: set of tests for drm buddy alloc
+ * Scope: drm subsystem
+ * Mega feature: drm
+ * Feature: buddy_alloc
+ *
+ * KTEST_TEST: drm_test_buddy_alloc_%s
+ * Description: Run DRM buddy allocation %arg[1] test
+ *
+ * arg[1].values: limit, range, optimistic, smoke, pathological
+ */
+
static struct kunit_case drm_buddy_tests[] = {
KUNIT_CASE(drm_test_buddy_alloc_limit),
KUNIT_CASE(drm_test_buddy_alloc_range),
--
2.40.1
[PATCH RFC 0/2] Add support for inlined documentation for kunit and kselftests
This RFC is a follow-up of the discussions taken here: https://lore.kernel.org/linux-doc/20230704132812.02ba97ba@maurocar-mobl2/T/#t It adds a new extension that allows documenting tests using the same tool we're using for DRM unit tests at IGT GPU tools: https://gitlab.freedesktop.org/drm/igt-gpu-tools. While kernel-doc has provided documentation for in-lined functions/struct comments, it was not meant to document tests. Tests need to be grouped by the test functions. It should also be possible to produce other outputs from the documentation, to integrate it with test suites. For instance, Internally at Intel, we use the comments to generate DOT files hierarchically grouped per feature categories. This is just an initial RFC to start discussions around the solution. Before being merged upstream, we need to define what tags will be used to identify test markups and add a simple change at kernel-doc to let it ignore such markups. On this series, we have: - patch 1: adding test_list.py as present at the IGT tree, after a patch series to make it more generic: https://patchwork.freedesktop.org/series/120622/ - patch 2: adds an example about how tests could be documented. This is a really simple example, just to test the feature, specially designed to make easy to build just the test documentation from a single DRM kunit file. After discussions, my plan is to send a new version addressing the issues, and add some documentation for DRM and/or i915 kunit tests. Mauro Carvalho Chehab (2): docs: add support for documenting kUnit and kSelftests drm: add documentation for drm_buddy_test kUnit test Documentation/conf.py |2 +- Documentation/index.rst|2 +- Documentation/sphinx/test_kdoc.py | 108 ++ Documentation/sphinx/test_list.py | 1288 Documentation/tests/index.rst |6 + Documentation/tests/kunit.rst |5 + drivers/gpu/drm/tests/drm_buddy_test.c | 12 + 7 files changed, 1421 insertions(+), 2 deletions(-) create mode 100644 Documentation/sphinx/test_kdoc.py create mode 100644 Documentation/sphinx/test_list.py create mode 100644 Documentation/tests/index.rst create mode 100644 Documentation/tests/kunit.rst -- 2.40.1
Re: scripts/kernel-doc does not handle duplicate struct & function names (e.g., in amdgpu)
Em Tue, 11 Jul 2023 20:45:18 -0700
Randy Dunlap escreveu:
> On 7/11/23 20:32, Akira Yokosawa wrote:
> > Hi Randy,
> >
> >> [just documenting this for posterity or in case someone wants to fix it.]
> >>
> >> In drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c, one can find both
> >>
> >> struct amdgpu_vm_tlb_seq_cb {...};
> >>
> >> and
> >> static void amdgpu_vm_tlb_seq_cb(...)
> >>
> >> Of course C has no problem with this, but kernel-doc reports:
> >>
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:833: WARNING: Duplicate C
> >> declaration, also defined at gpu/amdgpu/driver-core:115.
> >>
> >> And of course, if the name of one of them is changed, kernel-doc is all
> >> happy...
> >> not that I am suggesting that one of them should be changed.
> >>
> >> I just want to make people aware of this. (or maybe people are already
> >> aware of this?)
> >
> > The duplicate warning is emitted from Sphinx, not kernel-doc.
> >
> > This is a bug of Sphinx >=3.1, first reported by Mauro back in September
> > 2020 at:
> >
> > https://github.com/sphinx-doc/sphinx/issues/8241
> >
> > It was closed when a local fix was presented. Unfortunately, it was not
> > merged at the time and a subsequent pull request was opened at:
> >
> > https://github.com/sphinx-doc/sphinx/pull/8313
> >
> > It is not merged yet and carries a milestone of Sphinx 7.x.
> >
> > Looks like we need to wait patiently.
> >
> > Thanks, Akira
>
> Ooooh, thanks for your assistance. Waiting :)
Yeah, we've been waiting this since Sphinx version 3.x times :-(
It seems that applying the fix would break an extension
(intersphinx). We don't use at the Kernel, so it won't affect
us, but it seems to be a popular extension, as it allows one
web server to have cross-references to Sphinx docs produced
elsewhere. Btw, such extension could be interesting on partial
doc builds (e. g. make SPHNXDIRS="foo_dir" htmldocs), as the
non-existing cross-references would be pointing, for instance,
to the docs stored at kernel.doc latest docs.
Btw, I'm still using version 2.4.4 when building the docs
to avoid the wrong duplicate warnings with 3.1+ due to this bug.
Thanks,
Mauro
Re: [RFC v3 3/3] drm/ttm/tests: Add tests for ttm_pool
On Mon, 3 Jul 2023 13:21:43 +0200 Christian König wrote: > > + /* We don't need this BO later, release it */ > > + ttm_bo_put(bo); > > That won't work. A BO must always outlive the TT object allocated for it. > > Otherwise you can get crashes during TT release. Just my two cents: shouldn't the TT object be increasing Kobj refcount then, in order to properly manage the BO object lifetime? Regards, Mauro
Re: [PATCH] media: Fix building pdfdocs
Em Sun, 26 Feb 2023 08:39:32 +0900
Akira Yokosawa escreveu:
> [+CC: Jon, linux-doc]
>
> On Wed, 8 Feb 2023 10:29:16 +0200, Tomi Valkeinen wrote:
> > Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added
> > documatation for a few new RGB formats. For some reason these break the
> > pdfdocs build, even if the same style seems to work elsewhere in the
> > file.
> >
> > Remove the trailing empty dash lines, which seems to fix the issue.
> >
> > Fixes: 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats")
> > Reported-by: Akira Yokosawa
> Link:
> https://lore.kernel.org/r/12250823-8445-5854-dfb8-b92c0ff08...@gmail.com/
>
> > Signed-off-by: Tomi Valkeinen
> > ---
> >
> > Note: the offending patch was merged via drm tree, so we may want to
> > apply the fix to the drm tree also.
>
> So, the offending commit is now in mainline without this fix...
> I believe this build regression -- a real build error of "make pdfdocs"
> -- should be fixed ASAP.
>
> Tomi, Laurent has suggested a typo fix in the Changelog.
> Can you respin ?
>
> Or, Laurent, can you do the fix on your own?
>
> Hopefully, the fix can make v6.3-rc1.
Better to wait for media PR to be handled. There were some changes at
the documentation that affected the patch. I guess the bug is gone.
If not, we'll need to rebase the patch.
Regards,
Mauro
>
> Thanks, Akira
>
> >
> > Documentation/userspace-api/media/v4l/pixfmt-rgb.rst | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > index d330aeb4d3eb..ea545ed1aeaa 100644
> > --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > @@ -868,7 +868,6 @@ number of bits for each component.
> >- r\ :sub:`4`
> >- r\ :sub:`3`
> >- r\ :sub:`2`
> > - -
> > * .. _V4L2-PIX-FMT-RGBA1010102:
> >
> >- ``V4L2_PIX_FMT_RGBA1010102``
> > @@ -909,7 +908,6 @@ number of bits for each component.
> >- r\ :sub:`4`
> >- r\ :sub:`3`
> >- r\ :sub:`2`
> > - -
> > * .. _V4L2-PIX-FMT-ARGB2101010:
> >
> >- ``V4L2_PIX_FMT_ARGB2101010``
> > @@ -950,7 +948,6 @@ number of bits for each component.
> >- r\ :sub:`6`
> >- r\ :sub:`5`
> >- r\ :sub:`4`
> > - -
> >
> > .. raw:: latex
> >
Thanks,
Mauro
Re: [PATCH] media: Fix building pdfdocs
Em Wed, 8 Feb 2023 11:11:34 +0200
Laurent Pinchart escreveu:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Feb 08, 2023 at 10:29:16AM +0200, Tomi Valkeinen wrote:
> > Commit 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats") added
> > documatation for a few new RGB formats. For some reason these break the
>
> s/documatation/documentation/
>
> > pdfdocs build, even if the same style seems to work elsewhere in the
> > file.
> >
> > Remove the trailing empty dash lines, which seems to fix the issue.
> >
> > Fixes: 8d0e3fc61abd ("media: Add 2-10-10-10 RGB formats")
> > Reported-by: Akira Yokosawa
> > Signed-off-by: Tomi Valkeinen
>
> Reviewed-by: Laurent Pinchart
>
> > ---
> >
> > Note: the offending patch was merged via drm tree, so we may want to
> > apply the fix to the drm tree also.
>
> Sounds good to me. Mauro, could you ack this patch ?
Acked-by: Mauro Carvalho Chehab
>
> > Documentation/userspace-api/media/v4l/pixfmt-rgb.rst | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > index d330aeb4d3eb..ea545ed1aeaa 100644
> > --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst
> > @@ -868,7 +868,6 @@ number of bits for each component.
> >- r\ :sub:`4`
> >- r\ :sub:`3`
> >- r\ :sub:`2`
> > - -
> > * .. _V4L2-PIX-FMT-RGBA1010102:
> >
> >- ``V4L2_PIX_FMT_RGBA1010102``
> > @@ -909,7 +908,6 @@ number of bits for each component.
> >- r\ :sub:`4`
> >- r\ :sub:`3`
> >- r\ :sub:`2`
> > - -
> > * .. _V4L2-PIX-FMT-ARGB2101010:
> >
> >- ``V4L2_PIX_FMT_ARGB2101010``
> > @@ -950,7 +948,6 @@ number of bits for each component.
> >- r\ :sub:`6`
> >- r\ :sub:`5`
> >- r\ :sub:`4`
> > - -
> >
> > .. raw:: latex
> >
>
Thanks,
Mauro
Re: [PATCH v3 0/7] media/drm: renesas: Add new pixel formats
Em Tue, 17 Jan 2023 15:38:25 +0200 Laurent Pinchart escreveu: > Hi Tomi, > > (CC'ing Mauro and Hans) > > On Tue, Jan 10, 2023 at 04:25:37PM +0200, Tomi Valkeinen wrote: > > On 26/12/2022 16:56, Laurent Pinchart wrote: > > > Hi Tomi, > > > > > > (CC'ing Daniel and Dave) > > > > > > On Wed, Dec 21, 2022 at 11:24:41AM +0200, Tomi Valkeinen wrote: > > >> From: Tomi Valkeinen > > >> > > >> Hi, > > >> > > >> These add new pixel formats for Renesas V3U and V4H SoCs. > > >> > > >> As the display pipeline is split between DRM and V4L2 components, this > > >> series touches both subsystems. I'm sending all these together to > > >> simplify review. If needed, I can later split this to V4L2 and DRM > > >> parts, of which the V4L2 part needs to be merged first. > > > > > > As the changes on the DRM side are small and shouldn't conflict with > > > anything else queued for v6.3, it would be easier to merge the whole > > > series through the media tree. Daniel, Dave, would you be OK with that ? > > > If so, could you please ack patches 6/7 and 7/7 ? > > > > Note that these patches depend on the two DRM driver patches in "[PATCH > > v5 0/7] Renesas V4H DSI & DP output support", which are not very small > > (but still not big). > > Good point. I'm thus leaning more towards merging this through the DRM > tree then. Mauro, can we get your ack on the V4L2 part of this series ? > We'll create a stable branch based on v6.2-rc1 in case it also need to > be merged in the media tree due to last minute conflicts (I'm mainly > thinking about the new formats). Feel free to merge the V4L2 patches via DRM tree with my ack: Acked-by: Mauro Carvalho Chehab > > Hans, as there won't be a pull request through the media tree, if you > want to review the new formats, now would be a good time. > > > I don't think there's a compile-time dependency between the DRM and V4L2 > > parts, but there's a functional side dependency, so it would be nice to > > merge these via a single tree. I can't say if DRM or V4L2 tree is > > easier, but I don't expect conflicts either way. > Thanks, Mauro
[PATCH 0/3] Add KUnit support for i915 mock selftests
That's an updated version of my previous KUnit RFC series: https://patchwork.freedesktop.org/series/110481/ While the RFC series added support for live and perf, let's start with mock, as running tests in bare metal is not the current focus of KUnit. So, basically patch 1 was changed to export just mock functions, and the bare metal patches got removed from this version. As before, running KUnit on i915 driver requires the --arch parameter: ./tools/testing/kunit/kunit.py run --arch=x86_64 --kunitconfig=drivers/gpu/drm/i915/selftests/ --jobs=`nproc --all` [13:18:40] Configuring KUnit Kernel ... [13:18:40] Building KUnit Kernel ... Populating config with: $ make ARCH=x86_64 O=.kunit olddefconfig Building with: $ make ARCH=x86_64 O=.kunit --jobs=8 [13:23:20] Starting KUnit Kernel (1/1)... [13:23:20] Running tests with: $ qemu-system-x86_64 -nodefaults -m 1024 -kernel .kunit/arch/x86/boot/bzImage -append 'kunit.enable=1 console=ttyS0 kunit_shutdown=reboot' -no-reboot -nographic -serial stdio [13:23:21] i915 mock selftests (18 subtests) = [13:23:21] [PASSED] mock_sanitycheck [13:23:21] [PASSED] mock_shmem [13:23:24] [PASSED] mock_fence [13:23:25] [PASSED] mock_scatterlist [13:23:27] [PASSED] mock_syncmap [13:23:27] [PASSED] mock_uncore [13:23:27] [PASSED] mock_ring [13:23:27] [PASSED] mock_engine [13:23:31] [PASSED] mock_timelines [13:23:32] [PASSED] mock_requests [13:23:32] [PASSED] mock_objects [13:23:32] [PASSED] mock_phys [13:23:32] [PASSED] mock_dmabuf [13:23:38] [PASSED] mock_vma [13:23:38] [PASSED] mock_evict [13:23:41] [PASSED] mock_gtt [13:23:42] [PASSED] mock_hugepages [13:23:42] [PASSED] mock_memory_region [13:23:42] === [PASSED] i915 mock selftests === [13:23:42] [13:23:42] Testing complete. Ran 18 tests: passed: 18 [13:23:42] Elapsed time: 302.766s total, 0.003s configuring, 280.393s building, 22.341s running Mauro Carvalho Chehab (3): drm/i915: place selftest preparation on a separate function drm/i915: export all mock selftest functions drm/i915: allow running mock selftests via Kunit drivers/gpu/drm/i915/Kconfig | 15 +++ drivers/gpu/drm/i915/Makefile | 5 + .../gpu/drm/i915/gem/selftests/huge_pages.c | 1 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 1 + .../drm/i915/gem/selftests/i915_gem_object.c | 1 + .../drm/i915/gem/selftests/i915_gem_phys.c| 1 + drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/selftest_ring.c | 1 + drivers/gpu/drm/i915/gt/selftest_timeline.c | 1 + drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 + drivers/gpu/drm/i915/i915_selftest.h | 2 + drivers/gpu/drm/i915/selftests/.kunitconfig | 12 +++ .../gpu/drm/i915/selftests/i915_gem_evict.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 + drivers/gpu/drm/i915/selftests/i915_kunit.c | 95 +++ drivers/gpu/drm/i915/selftests/i915_request.c | 1 + .../gpu/drm/i915/selftests/i915_selftest.c| 23 +++-- .../gpu/drm/i915/selftests/i915_sw_fence.c| 1 + drivers/gpu/drm/i915/selftests/i915_syncmap.c | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c | 1 + .../drm/i915/selftests/intel_memory_region.c | 1 + drivers/gpu/drm/i915/selftests/intel_uncore.c | 1 + drivers/gpu/drm/i915/selftests/scatterlist.c | 1 + 23 files changed, 161 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/selftests/.kunitconfig create mode 100644 drivers/gpu/drm/i915/selftests/i915_kunit.c -- 2.38.1
[PATCH 3/3] drm/i915: allow running mock selftests via Kunit
ap [ 615.995098] i915: Running i915_vma_mock_selftests/igt_vma_partial [ 618.518421] ok 14 - mock_vma [ 618.519367] mock: [drm] Using Transparent Hugepages [ 618.528625] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 618.536467] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 618.544330] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 618.552318] i915: Running i915_gem_evict_mock_selftests/igt_evict_something [ 618.697340] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_vma [ 618.836366] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_cache_color [ 618.849926] i915: Running i915_gem_evict_mock_selftests/igt_evict_vm [ 618.992647] i915: Running i915_gem_evict_mock_selftests/igt_overcommit [ 619.170384] ok 15 - mock_evict [ 619.171566] mock: [drm] Using Transparent Hugepages [ 619.181351] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 619.189520] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 619.197366] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 619.205322] i915: Running i915_gem_gtt_mock_selftests/igt_mock_drunk [ 619.712643] drunk_hole timed out after 41097/524288 [ 619.717987] i915: Running i915_gem_gtt_mock_selftests/igt_mock_walk [ 620.225588] walk_hole timed out at a692000 [ 620.230687] i915: Running i915_gem_gtt_mock_selftests/igt_mock_pot [ 620.976730] pot_hole timed out after 19/33 [ 620.981596] i915: Running i915_gem_gtt_mock_selftests/igt_mock_fill [ 621.491729] fill_hole timed out (npages=1, prime=257) [ 621.497424] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_reserve [ 621.620470] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_insert [ 621.891015] ok 16 - mock_gtt [ 621.892018] mock: [drm] Using Transparent Hugepages [ 621.901620] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 621.909449] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 621.917347] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 621.925497] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_exhaust_device_supported_pages [ 621.937541] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages [ 621.947479] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_misaligned_dma [ 622.032179] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_huge_fill [ 622.540726] igt_mock_ppgtt_huge_fill timed out at size 61313024 [ 622.547707] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_64K [ 622.944941] ok 17 - mock_hugepages [ 622.945866] mock: [drm] Using Transparent Hugepages [ 622.956054] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 622.963891] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 622.971705] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 622.979664] i915: Running intel_memory_region_mock_selftests/igt_mock_reserve [ 623.006381] i915: Running intel_memory_region_mock_selftests/igt_mock_fill [ 623.057022] i915: Running intel_memory_region_mock_selftests/igt_mock_contiguous [ 624.040905] i915: Running intel_memory_region_mock_selftests/igt_mock_splintered_region [ 624.075553] i915: Running intel_memory_region_mock_selftests/igt_mock_max_segment [ 624.108598] i915: Running intel_memory_region_mock_selftests/igt_mock_io_size [ 624.116097] igt_mock_io_size with ps=1000, io_size=a7823000, total=1b5fee000 [ 624.133227] igt_mock_io_size mappable theft=(632MiB/2680MiB), total=7007MiB [ 624.204955] ok 18 - mock_memory_region [ 624.204964] # i915 mock selftests: pass:18 fail:0 skip:0 total:18 [ 624.209921] # Totals: pass:18 fail:0 skip:0 total:18 [ 624.216762] ok 1 - i915 mock selftests. They could be parsed with kunit.py with: echo "[0.00] TAP version 14" >logs dmesg >>logs ./tools/testing/kunit/kunit.py parse logs Note: kunit.py is currently broken with modules, not producing any results if "TAP version xx" is not found. It also shows the results duplicated. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH 0/3] at: https://lore.kernel.org/all/cover.1669897668.git.mche...@kernel.org/ drivers/gpu/drm/i915/Kconfig| 15 drivers/gpu/drm/i915
[PATCH 1/3] drm/i915: place selftest preparation on a separate function
The selftest preparation logic should also be used by KUnit. So,
place it on a separate function and export it.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 0/3] at:
https://lore.kernel.org/all/cover.1669897668.git.mche...@kernel.org/
drivers/gpu/drm/i915/i915_selftest.h | 2 ++
.../gpu/drm/i915/selftests/i915_selftest.c| 22 ---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index bdf3e22c0a34..cd0065033ed9 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -44,6 +44,7 @@ struct i915_selftest {
extern struct i915_selftest i915_selftest;
+void i915_prepare_selftests(const char *name);
int i915_mock_selftests(void);
int i915_live_selftests(struct pci_dev *pdev);
int i915_perf_selftests(struct pci_dev *pdev);
@@ -113,6 +114,7 @@ int __i915_subtests(const char *caller,
#else /* !IS_ENABLED(CONFIG_DRM_I915_SELFTEST) */
+static inline void i915_prepare_selftests(const char *) {};
static inline int i915_mock_selftests(void) { return 0; }
static inline int i915_live_selftests(struct pci_dev *pdev) { return 0; }
static inline int i915_perf_selftests(struct pci_dev *pdev) { return 0; }
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..bc85dac4eb15 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -127,13 +127,8 @@ static void set_default_test_all(struct selftest *st,
unsigned int count)
st[i].enabled = true;
}
-static int __run_selftests(const char *name,
- struct selftest *st,
- unsigned int count,
- void *data)
+void i915_prepare_selftests(const char *name)
{
- int err = 0;
-
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
@@ -142,10 +137,21 @@ static int __run_selftests(const char *name,
msecs_to_jiffies_timeout(i915_selftest.timeout_ms) :
MAX_SCHEDULE_TIMEOUT;
- set_default_test_all(st, count);
-
pr_info(DRIVER_NAME ": Performing %s selftests with st_random_seed=0x%x
st_timeout=%u\n",
name, i915_selftest.random_seed, i915_selftest.timeout_ms);
+}
+EXPORT_SYMBOL_NS_GPL(i915_prepare_selftests, I915_SELFTEST);
+
+static int __run_selftests(const char *name,
+ struct selftest *st,
+ unsigned int count,
+ void *data)
+{
+ int err = 0;
+
+ i915_prepare_selftests(name);
+
+ set_default_test_all(st, count);
/* Tests are listed in order in i915_*_selftests.h */
for (; count--; st++) {
--
2.38.1
[PATCH 2/3] drm/i915: export all mock selftest functions
In order to prepare for a new KUnit module that will run
selftests, export all mock selftest functions to I915_SELFTEST
namespace.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH 0/3] at:
https://lore.kernel.org/all/cover.1669897668.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c | 1 +
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 1 +
drivers/gpu/drm/i915/gt/selftest_ring.c | 1 +
drivers/gpu/drm/i915/gt/selftest_timeline.c | 1 +
drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 1 +
drivers/gpu/drm/i915/selftests/i915_request.c| 1 +
drivers/gpu/drm/i915/selftests/i915_selftest.c | 1 +
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 1 +
drivers/gpu/drm/i915/selftests/i915_syncmap.c| 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c| 1 +
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 1 +
drivers/gpu/drm/i915/selftests/intel_uncore.c| 1 +
drivers/gpu/drm/i915/selftests/scatterlist.c | 1 +
18 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index beaf27e09e8a..954d37552681 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1944,6 +1944,7 @@ int i915_gem_huge_page_mock_selftests(void)
mock_destroy_device(dev_priv);
return err;
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_huge_page_mock_selftests, I915_SELFTEST);
int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
{
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index e57f9390076c..2f6422eb9801 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -543,6 +543,7 @@ int i915_gem_dmabuf_mock_selftests(void)
mock_destroy_device(i915);
return err;
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_dmabuf_mock_selftests, I915_SELFTEST);
int i915_gem_dmabuf_live_selftests(struct drm_i915_private *i915)
{
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
index bdf5bb40ccf1..4c50be935462 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c
@@ -88,6 +88,7 @@ int i915_gem_object_mock_selftests(void)
mock_destroy_device(i915);
return err;
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_object_mock_selftests, I915_SELFTEST);
int i915_gem_object_live_selftests(struct drm_i915_private *i915)
{
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c
index d43d8dae0f69..03cd27066153 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c
@@ -85,3 +85,4 @@ int i915_gem_phys_mock_selftests(void)
mock_destroy_device(i915);
return err;
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_phys_mock_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
index 881b64f3e7b9..e3e4918b3f9e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/selftest_engine_cs.c
@@ -437,3 +437,4 @@ int intel_engine_cs_mock_selftests(void)
return i915_subtests(tests, NULL);
}
+EXPORT_SYMBOL_NS_GPL(intel_engine_cs_mock_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gt/selftest_ring.c
b/drivers/gpu/drm/i915/gt/selftest_ring.c
index 2a8c534dc125..6590c9c504b9 100644
--- a/drivers/gpu/drm/i915/gt/selftest_ring.c
+++ b/drivers/gpu/drm/i915/gt/selftest_ring.c
@@ -108,3 +108,4 @@ int intel_ring_mock_selftests(void)
return i915_subtests(tests, NULL);
}
+EXPORT_SYMBOL_NS_GPL(intel_ring_mock_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
b/drivers/gpu/drm/i915/gt/selftest_timeline.c
index 522d0190509c..fcf044c9feea 100644
--- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
+++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
@@ -450,6 +450,7 @@ int intel_timeline_mock_selftests(void)
return i915_subtests(tests, NULL);
}
+EXPORT_SYMBOL_NS_GPL(intel_timeline_mock_selftests, I915_SELFTEST);
static int emit_ggtt_store_dw(struct i915_request *rq, u32 addr, u32 value)
{
diff --git a/drivers/gpu/drm/i915/gt/st_shmem_utils.c
b/drivers/gpu/drm/i915/gt/st_shmem_utils.c
Re: [PATCH 2/5] driver core: make struct class.devnode() take a const *
Em Wed, 23 Nov 2022 13:25:20 +0100
Greg Kroah-Hartman escreveu:
> The devnode() in struct class should not be modifying the device that is
> passed into it, so mark it as a const * and propagate the function
> signature changes out into all relevant subsystems that use this
> callback.
Acked-by: Mauro Carvalho Chehab
>
> Cc: Fenghua Yu
> Cc: Reinette Chatre
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: x...@kernel.org
> Cc: "H. Peter Anvin"
> Cc: FUJITA Tomonori
> Cc: Jens Axboe
> Cc: Justin Sanders
> Cc: Arnd Bergmann
> Cc: Sumit Semwal
> Cc: Benjamin Gaignard
> Cc: Liam Mark
> Cc: Laura Abbott
> Cc: Brian Starkey
> Cc: John Stultz
> Cc: "Christian König"
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Dennis Dalessandro
> Cc: Dmitry Torokhov
> Cc: Mauro Carvalho Chehab
> Cc: Sean Young
> Cc: Frank Haverkamp
> Cc: Jiri Slaby
> Cc: "Michael S. Tsirkin"
> Cc: Jason Wang
> Cc: Alex Williamson
> Cc: Cornelia Huck
> Cc: Kees Cook
> Cc: Anton Vorontsov
> Cc: Colin Cross
> Cc: Tony Luck
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Hans Verkuil
> Cc: Christophe JAILLET
> Cc: Xie Yongji
> Cc: Gautam Dawar
> Cc: Dan Carpenter
> Cc: Eli Cohen
> Cc: Parav Pandit
> Cc: Maxime Coquelin
> Cc: alsa-de...@alsa-project.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: k...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-bl...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-me...@vger.kernel.org
> Cc: linux-r...@vger.kernel.org
> Cc: linux-s...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Signed-off-by: Greg Kroah-Hartman
> ---
> arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 4 ++--
> arch/x86/kernel/cpuid.c| 2 +-
> arch/x86/kernel/msr.c | 2 +-
> block/bsg.c| 2 +-
> drivers/block/aoe/aoechr.c | 2 +-
> drivers/char/mem.c | 2 +-
> drivers/char/misc.c| 4 ++--
> drivers/dma-buf/dma-heap.c | 2 +-
> drivers/gpu/drm/drm_sysfs.c| 2 +-
> drivers/infiniband/core/user_mad.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 2 +-
> drivers/infiniband/hw/hfi1/device.c| 4 ++--
> drivers/input/input.c | 2 +-
> drivers/media/dvb-core/dvbdev.c| 4 ++--
> drivers/media/pci/ddbridge/ddbridge-core.c | 4 ++--
> drivers/media/rc/rc-main.c | 2 +-
> drivers/misc/genwqe/card_base.c| 2 +-
> drivers/tty/tty_io.c | 2 +-
> drivers/usb/core/file.c| 2 +-
> drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
> drivers/vfio/vfio_main.c | 2 +-
> fs/pstore/pmsg.c | 2 +-
> include/linux/device/class.h | 2 +-
> sound/sound_core.c | 2 +-
> 24 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> index d961ae3ed96e..4e4231a58f38 100644
> --- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> +++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
> @@ -1560,9 +1560,9 @@ static const struct file_operations
> pseudo_lock_dev_fops = {
> .mmap = pseudo_lock_dev_mmap,
> };
>
> -static char *pseudo_lock_devnode(struct device *dev, umode_t *mode)
> +static char *pseudo_lock_devnode(const struct device *dev, umode_t *mode)
> {
> - struct rdtgroup *rdtgrp;
> + const struct rdtgroup *rdtgrp;
>
> rdtgrp = dev_get_drvdata(dev);
> if (mode)
> diff --git a/arch/x86/kernel/cpuid.c b/arch/x86/kernel/cpuid.c
> index 6f7b8cc1bc9f..621ba9c0f17a 100644
> --- a/arch/x86/kernel/cpuid.c
> +++ b/arch/x86/kernel/cpuid.c
> @@ -139,7 +139,7 @@ static int cpuid_device_destroy(unsigned int cpu)
> return 0;
> }
>
> -static char *cpuid_devnode(struct device *dev, umode_t *mode)
> +static char *cpuid_devnode(const struct device *dev, umode_t *mode)
> {
> return kasprintf(GFP_KERNEL, "cpu/%u/cpuid", MINOR(dev->devt));
> }
> diff --git a/arch/x86/kernel/msr.c b/arch/x86/kernel/msr.c
> index ed8ac6bcbafb..708751311786 100644
> --- a/arch/x86/kernel/msr.c
> +++ b/arch/x86/kernel/msr.c
> @@ -250,7 +250,7 @@ static int ms
Re: [PATCH v10 18/19] drm/vc4: vec: Add support for more analog TV standards
On Thu, 17 Nov 2022 10:29:01 +0100
Maxime Ripard wrote:
> From: Mateusz Kwiatkowski
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
> 4.43361875 MHz (the PAL subcarrier frequency). Never used for
> broadcasting, but sometimes used as a hack to play NTSC content in PAL
> regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
> 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
> and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
That's not right. Argentina uses a different standard than Paraguay and
Uruguai.
See, there are two variants of PAL/N. The original one and PAL/N' - also
called PAL/NC or PAL/CN (Combination N). Some of the timings are
different on /NC variant.
As far as I'm aware, PAL/Nc is used in Argentina, while
PAL/N is used in Paraguai and Uruguai, but I may be wrong on that,
as it has been a long time since had to touch on this.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
> frequency. Another non-standard, non-broadcast mode, used in similar
> contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
> been broadcast in Eastern Europe and various parts of Africa and Asia.
> Uses the same 576i50 timings as PAL.
This is also wrong. just like PAL, there are several variants of SECAM,
one used in France, and a different one in France overseas and on
previous France colonies in Africa and Asia. Eastern Europe also used
different variants of SECAM.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Mateusz Kwiatkowski
> Tested-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v6:
> - Support PAL60 again
> ---
> drivers/gpu/drm/vc4/vc4_vec.c | 111
> --
> 1 file changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a828fc6fb776..d23dbad3cbf6 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
> #define VEC_CONFIG0_YDEL(x) ((x) << 26)
> #define VEC_CONFIG0_CDEL_MASKGENMASK(25, 24)
> #define VEC_CONFIG0_CDEL(x) ((x) << 24)
> +#define VEC_CONFIG0_SECAM_STDBIT(21)
> #define VEC_CONFIG0_PBPR_FIL BIT(18)
> #define VEC_CONFIG0_CHROMA_GAIN_MASK GENMASK(17, 16)
> #define VEC_CONFIG0_CHROMA_GAIN_UNITY(0 << 16)
> @@ -76,6 +77,27 @@
> #define VEC_SOFT_RESET 0x10c
> #define VEC_CLMP0_START 0x144
> #define VEC_CLMP0_END0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit half-word,
> + * VEC_FREQ3_2 contains the least significant 16-bit half-word.
> + * 0x8000 seems to be equivalent to the pixel clock
> + * (which itself is the VEC clock divided by 8).
> + *
> + * Reference values (with the default pixel clock of 13.5 MHz):
> + *
> + * NTSC (3579545.[45] Hz) - 0x21F07C1F
> + * PAL (4433618.75 Hz) - 0x2A098ACB
> + * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
> + * PAL-N (3582056.25 Hz) - 0x21F69446
> + *
> + * NOTE: For SECAM, it is used as the Dr center frequency,
> + * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
> + * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
> + */
> #define VEC_FREQ3_2 0x180
> #define VEC_FREQ1_0 0x184
>
> @@ -118,6 +140,14 @@
>
> #define VEC_INTERRUPT_CONTROL0x190
> #define VEC_INTERRUPT_STATUS 0x194
> +
> +/*
> + * Db center frequency for SECAM; the clock for this is the same as for
> + * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
> + *
> + * This is specified as 425 Hz, which corresponds to 0x284BDA13.
> + * That is also the default value, so no need to set it explicitly.
> + */
> #define VEC_FCW_SECAM_B 0x198
> #define VEC_SECAM_GAIN_VAL 0x19c
>
> @@ -197,10 +227,15 @@ enum vc4_vec_tv_mode_id {
> VC4_VEC_TV_MODE_NTSC_J,
> VC4_VEC_TV_MODE_PAL,
> VC4_VEC_TV_MODE_PAL_M,
> + VC4_VEC_TV_MODE_NTSC_443,
> + VC4_VEC_TV_MODE_PAL_60,
> + VC4_VEC_TV_MODE_PAL_N,
> + VC4_VEC_TV_MODE_SECAM,
> };
>
> struct vc4_vec_tv_mode {
> unsigned int mode;
> + u16 expected_htotal;
> u32 config0;
> u32 config1;
> u32 custom_freq;
> @@ -236,35 +271,68 @@ static const struct debugfs_reg32 vec_regs[] = {
> static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
> {
>
Re: [PATCH v10 05/19] drm/connector: Add TV standard property
On Thu, 17 Nov 2022 10:28:48 +0100
Maxime Ripard wrote:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
>
> Let's create a new enum tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports, and the property
> creation function will filter out the modes not supported.
>
> We'll then be able to phase out the older tv mode property.
>
> Tested-by: Mateusz Kwiatkowski
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in v10:
> - Fix checkpatch warning
>
> Changes in v5:
> - Create an analog TV properties documentation section, and document TV
> Mode there instead of the csv file
>
> Changes in v4:
> - Add property documentation to kms-properties.csv
> - Fix documentation
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 122
> +-
> include/drm/drm_connector.h | 64
> include/drm/drm_mode_config.h | 8 +++
> 5 files changed, 203 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index b4377a545425..321f2f582c64 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -520,6 +520,12 @@ HDMI Specific Connector Properties
> .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> :doc: HDMI connector properties
>
> +Analog TV Specific Connector Properties
> +--
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> + :doc: Analog TV Connector Properties
> +
> Standard CRTC Properties
>
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 7f2b9a07fbdf..d867e7f9f2cd 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -700,6 +700,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> state->tv.margins.bottom = val;
> } else if (property == config->legacy_tv_mode_property) {
> state->tv.legacy_mode = val;
> + } else if (property == config->tv_mode_property) {
> + state->tv.mode = val;
> } else if (property == config->tv_brightness_property) {
> state->tv.brightness = val;
> } else if (property == config->tv_contrast_property) {
> @@ -810,6 +812,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->tv.margins.bottom;
> } else if (property == config->legacy_tv_mode_property) {
> *val = state->tv.legacy_mode;
> + } else if (property == config->tv_mode_property) {
> + *val = state->tv.mode;
> } else if (property == config->tv_brightness_property) {
> *val = state->tv.brightness;
> } else if (property == config->tv_contrast_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 06e737ed15f5..07d449736956 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -984,6 +984,17 @@ static const struct drm_prop_enum_list
> drm_dvi_i_subconnector_enum_list[] = {
> DRM_ENUM_NAME_FN(drm_get_dvi_i_subconnector_name,
>drm_dvi_i_subconnector_enum_list)
>
> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
> + { DRM_MODE_TV_MODE_NTSC, "NTSC" },
> + { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> + { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> + { DRM_MODE_TV_MODE_PAL, "PAL" },
> + { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> + { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> + { DRM_MODE_TV_MODE_SECAM, "SECAM" },
> +};
Nack. It sounds a very bad idea to have standards as generic as
NTSC, PAL, SECAM.
If you take a look at the CCIR/ITU-R specs that define video standards,
you'll see that the standard has actually two components:
1. the composite color TV signal: PAL, NTSC, SECAM, defined in ITU-R BT1700[1]
2. and the conventional analogue TV (the "monochromatic" part),
as defined in ITU-R BT.1701[2], which is, basically, a letter from A to N
(with some country-specific variants, like Nc). Two of those standards
(M and J) are used on Countries with a power grid of 60Hz, as they have
a frame rate of either 30fps or 29.997fps.
[1] https://www.itu.int/rec/R-REC-BT.1700-0-200502-I/en
[2] https://www.itu.int/rec/R-REC-BT.1701-1-200508-I/en
The actual combination is defined within Country-specific laws, which
selects a conventional analogue signal with a composite color one.
So, for instance, US uses
Re: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
On Mon, 7 Nov 2022 15:16:17 -0800 Daniel Latypov wrote: > On Mon, Nov 7, 2022 at 10:38 AM Michał Winiarski > wrote: > > > > 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? > > I don't think we have other tests like this. > > > 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? > > The main focus of KUnit is for hw-independent tests. > So in theory: no. > > But I can imagine it could be easier to write the validation via > KUNIT_EXPECT_EQ and friends as opposed to writing your own kernel > module w/ its own set of macros, etc. Right now, i915 has its own way of doing that, for both hw-independent and live tests. The current patches are keeping them, because it helps comparing both approaches, and won't disrupt CI jobs. However, if we're willing to merge KUnit support, the best would be to use the same macros/logic for both, as having two different unit test frameworks used on i915 doesn't make much sense. So yeah, using KUNIT_EXPECT_EQ and friends for live unit and hw tests makes sense to me. The main difference between i915 selftest and KUnit seems to be at the way the tests are started: - i915 selftest uses module parameters to run the driver on test mode. When such parameters are enabled, the probe() function will run the tests. - from what I understood, KUnit uses a .kunit_test_suites code section, which does an early initialization of the tests, calling the test suite a lot earlier than probe(). Due to such differences, running KUnit against a real hardware requires to load the real driver first, letting it probe the hardware. Once the driver is loaded and have the hardware properly initialized, load a separate KUnit module that would call the test functions from the driver. That's the approach took on this series. It sounds possible to merge both approaches, by adding some helper functions similar to what kunit_test_suites() do, but, instead of using a separate segment, run the tests at probe() time. That would mean a cleaner solution with the usage of all KUnit macros and, in thesis, it will be equivalent to what i915 selftest already does. Another possibility would be to make sure that kunit_test_suites() will fully initiate the user context, allowing mmap() to work. > So my first thought is: "if it works, then you can try using it." > (Might want to take steps like make sure they don't get enabled by > CONFIG_KUNIT_ALL_TESTS=y). Yeah, it makes sense to have hw-dependent tests not enabled with KUNIT_ALL_TESTS. Another approach would be to just skip them when hw is required[1]. Skipping the tests is needed anyway, as the hardware probing may fail. [1] Btw, despite the comments: /** * kunit_skip() - Marks @test_or_suite as skipped * * @test_or_suite: The test context object. * @fmt: A printk() style format string. * * Skips the test. @fmt is given output as the test status * comment, typically the reason the test was skipped. * * Test execu
Re: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
On Fri, 4 Nov 2022 08:49:55 +0100
Mauro Carvalho Chehab wrote:
> On Thu, 3 Nov 2022 15:43:26 -0700
> Daniel Latypov wrote:
>
> > On Thu, Nov 3, 2022 at 8:23 AM 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.
> > >
> > > While testing KUnit, I noticed a couple of issues:
> > >
> > > 1. kunit.py parser is currently broken when used with modules
> > >
> > > the parser expects "TAP version xx" output, but this won't
> > > happen when loading the kunit test driver.
> > >
> > > Are there any plans or patches fixing this issue?
> >
> > Partially.
> > Note: we need a header to look for so we can strip prefixes (like
> > timestamps).
> >
> > But there is a patch in the works to add a TAP header for each
> > subtest, hopefully in time for 6.2.
>
> Good to know.
>
> > This is to match the KTAP spec:
> > https://kernel.org/doc/html/latest/dev-tools/ktap.html
>
> I see.
>
> > That should fix it so you can parse one suite's results at a time.
> > I'm pretty sure it won't fix the case where there's multiple suites
> > and/or you're trying to parse all test results at once via
> >
> > $ find /sys/kernel/debug/kunit/ -type f | xargs cat |
> > ./tools/testing/kunit/kunit.py parse
>
> Could you point me to the changeset? perhaps I can write a followup
> patch addressing this case.
>
> > I think that in-kernel code change + some more python changes could
> > make the above command work, but no one has actively started looking
> > at that just yet.
> > Hopefully we can pick this up and also get it done for 6.2 (unless I'm
> > underestimating how complicated this is).
> >
> > >
> > > 2. current->mm is not initialized
> > >
> > > Some tests do mmap(). They need the mm user context to be initialized,
> > > but this is not happening right now.
> > >
> > > Are there a way to properly initialize it for KUnit?
> >
> > Right, this is a consequence of how early built-in KUnit tests are run
> > after boot.
> > I think for now, the answer is to make the test module-only.
> >
> > I know David had some ideas here, but I can't speak to them.
>
> This is happening when test-i915 is built as module as well.
>
> I suspect that the function which initializes it is mm_alloc() inside
> kernel/fork.c:
>
> struct mm_struct *mm_alloc(void)
> {
> struct mm_struct *mm;
>
> mm = allocate_mm();
> if (!mm)
> return NULL;
>
> memset(mm, 0, sizeof(*mm));
> return mm_init(mm, current, current_user_ns());
> }
>
> As modprobing a test won't fork until all tests run, this never runs.
>
> It seems that the normal usage is at fs/exec.c:
>
> fs/exec.c: bprm->mm = mm = mm_alloc();
>
> but other places also call it:
>
> arch/arm/mach-rpc/ecard.c: struct mm_struct * mm = mm_alloc();
> drivers/dma-buf/dma-resv.c: struct mm_struct *mm = mm_alloc();
> include/linux/sched/mm.h:extern struct mm_struct *mm_alloc(void);
> mm/debug_vm_pgtable.c: args->mm = mm_alloc();
>
> Probably the solution would be to call it inside kunit executor code,
> adding support for modules to use it.
Hmm... it is no
Re: KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
On Thu, 3 Nov 2022 15:43:26 -0700
Daniel Latypov wrote:
> On Thu, Nov 3, 2022 at 8:23 AM 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.
> >
> > While testing KUnit, I noticed a couple of issues:
> >
> > 1. kunit.py parser is currently broken when used with modules
> >
> > the parser expects "TAP version xx" output, but this won't
> > happen when loading the kunit test driver.
> >
> > Are there any plans or patches fixing this issue?
>
> Partially.
> Note: we need a header to look for so we can strip prefixes (like timestamps).
>
> But there is a patch in the works to add a TAP header for each
> subtest, hopefully in time for 6.2.
Good to know.
> This is to match the KTAP spec:
> https://kernel.org/doc/html/latest/dev-tools/ktap.html
I see.
> That should fix it so you can parse one suite's results at a time.
> I'm pretty sure it won't fix the case where there's multiple suites
> and/or you're trying to parse all test results at once via
>
> $ find /sys/kernel/debug/kunit/ -type f | xargs cat |
> ./tools/testing/kunit/kunit.py parse
Could you point me to the changeset? perhaps I can write a followup
patch addressing this case.
> I think that in-kernel code change + some more python changes could
> make the above command work, but no one has actively started looking
> at that just yet.
> Hopefully we can pick this up and also get it done for 6.2 (unless I'm
> underestimating how complicated this is).
>
> >
> > 2. current->mm is not initialized
> >
> > Some tests do mmap(). They need the mm user context to be initialized,
> > but this is not happening right now.
> >
> > Are there a way to properly initialize it for KUnit?
>
> Right, this is a consequence of how early built-in KUnit tests are run
> after boot.
> I think for now, the answer is to make the test module-only.
>
> I know David had some ideas here, but I can't speak to them.
This is happening when test-i915 is built as module as well.
I suspect that the function which initializes it is mm_alloc() inside
kernel/fork.c:
struct mm_struct *mm_alloc(void)
{
struct mm_struct *mm;
mm = allocate_mm();
if (!mm)
return NULL;
memset(mm, 0, sizeof(*mm));
return mm_init(mm, current, current_user_ns());
}
As modprobing a test won't fork until all tests run, this never runs.
It seems that the normal usage is at fs/exec.c:
fs/exec.c: bprm->mm = mm = mm_alloc();
but other places also call it:
arch/arm/mach-rpc/ecard.c: struct mm_struct * mm = mm_alloc();
drivers/dma-buf/dma-resv.c: struct mm_struct *mm = mm_alloc();
include/linux/sched/mm.h:extern struct mm_struct *mm_alloc(void);
mm/debug_vm_pgtable.c: args->mm = mm_alloc();
Probably the solution would be to call it inside kunit executor code,
adding support for modules to use it.
> > 3. there's no test filters for modules
> >
> > In order to be able to do proper CI automation, it is needed to
> > be able to control what tests will run or not. That's specially
> > interesting at development time where some tests may not apply
> > or not run properly on new hardware.
> >
> > Are there any plans to add support for it at kunit_test_suites()
> > when the driver is built as module? Ideally, the best would be to
> > export a per-module filter_glob parameter on such cases.
>
> I think this is a good idea and is doable. (I think I said as much on
> the other threa
KUnit issues - Was: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
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. While testing KUnit, I noticed a couple of issues: 1. kunit.py parser is currently broken when used with modules the parser expects "TAP version xx" output, but this won't happen when loading the kunit test driver. Are there any plans or patches fixing this issue? 2. current->mm is not initialized Some tests do mmap(). They need the mm user context to be initialized, but this is not happening right now. Are there a way to properly initialize it for KUnit? 3. there's no test filters for modules In order to be able to do proper CI automation, it is needed to be able to control what tests will run or not. That's specially interesting at development time where some tests may not apply or not run properly on new hardware. Are there any plans to add support for it at kunit_test_suites() when the driver is built as module? Ideally, the best would be to export a per-module filter_glob parameter on such cases. 4. there are actually 3 levels of tests on i915: - Level 1: mock, live, perf - Level 2: test group (mmap, fences, ...) - Level 3: unit tests Currently, KUnit seems to have just two levels (test suite and tests). Are there a way to add test groups there? Regards, Mauro Forwarded message: Date: Thu, 3 Nov 2022 14:51:38 +0000 From: Mauro Carvalho Chehab To: Cc: Thomas Hellström , linux-kselft...@vger.kernel.org, Michał Winiarski , dri-devel@lists.freedesktop.org, intel-...@lists.freedesktop.org, Daniel Latypov , linux-ker...@vger.kernel.org, igt-...@lists.freedesktop.org, Matthew Auld , Daniel Vetter , Rodrigo Vivi , sk...@linuxfoundation.org, Isabella Basso , David Airlie , Christian König Subject: [igt-dev] [PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL The mmap tests require mm in order to work. Failing to do that will cause a crash: [ 316.820722] BUG: kernel NULL pointer dereference, address: 00e8 [ 316.822517] #PF: supervisor write access in kernel mode [ 316.823430] #PF: error_code(0x0002) - not-present page [ 316.824390] PGD 0 P4D 0 [ 316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U N 6.1.0-rc2-drm-266703e6f163+ #14 [ 316.827503] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 [ 316.828633] RIP: 0010:down_write_killable+0x50/0x110 [ 316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89 ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00 48 0f b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74 [ 316.830896] RSP: 0018:c90001eabc58 EFLAGS: 00010246 [ 316.832008] RAX: RBX: 00e8 RCX: [ 316.833141] RDX: 0001 RSI: 81c94fc9 RDI: 81c94fc9 [ 316.834195] RBP: 0158 R08: 0001 R09: [ 316.835231] R10: R11: 8883a13350b8 R12: 0002 [ 316.836259] R13: 0001 R14: 0010 R15: 00e8 [ 316.837237] FS: () GS:8883a380() knlGS: [ 316.838214] CS: 0010 DS: ES: CR0: 80050033 [ 316.839190] CR2: 00e8 CR3: 02812003 CR4: 00770ef0 [ 316.840147] PKRU: 5554 [ 316.841099] Call Trace: [ 316.842047] [ 316.842990] ? vm_mmap_pgoff+0x78/0x150 [ 316.843936] vm_mmap_pgoff+0x78/0x150 [ 316.844884] igt_mmap_offset+0x178/0x1b9 [i915] [ 316.846119] __igt_mmap+0xfe/0x680 [i915] Unfortunately, when KUnit module runs, it doesn't create an user context, causing mmap tests to fail. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH RFC v2 0/8] at: https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 + 1 file chang
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Thu, 3 Nov 2022 10:48:40 +0100 Mauro Carvalho Chehab wrote: > On Sun, 28 Aug 2022 21:09:19 -0300 > Isabella Basso wrote: > > > This adds functions for both executing the tests as well as parsing (K)TAP > > kmsg output, as per the KTAP spec [1]. > > > > [1] https://www.kernel.org/doc/html/latest/dev-tools/ktap.html > > > > Signed-off-by: Isabella Basso > > Hi Isabella, > > I'm doing some tests here with my i915 KUnit patch series. > > There's a problem with the way it is currently parsing the KTAP logs on > IGT. It sounds that it is parsing the data only at the end, and not as > they arrive. That's bad, as if something goes wrong, the previously > reported data is still useful. > > Also, when there's a crash, the IGT process is getting segmentation > fault. So, the end result is that nothing is actually reported. > > $ sudo ./build/tests/i915_selftest > IGT-Version: 1.26-gbab20eb65 (x86_64) (Linux: > 6.1.0-rc2-drm-990037e9984e+ x86_64) > Segmentation fault (core dumped) > > However, the logs are there (see enclosed). In this specific case, there > was a GPU hang while running one of the tests on a real hardware, which > is something that it is actually expected at development time. Btw, if you want to test it, the patches I'm using are at: https://patchwork.freedesktop.org/series/110483/ The latest patch there is a workaround that fixes the issue. So, if you apply patches 1-7 only, skipping (or reverting) patch 8, you'll be able to reproduce the Kernel crash (which seems to be caused by the way KUnit is initialized). Regards, Mauro
[PATCH RFC v2 0/8] Add KUnit support for i915 driver
KUnit test logic identical to i915 selftest. Mauro Carvalho Chehab (8): drm/i915: export all selftest functions drm/i915: place selftest preparation on a separate function drm/i915: allow running mock selftests via Kunit drm/i915: add support to run KUnit tests on bare metal drm/i915: add live selftests to KUnit drm/i915: add perf selftests to KUnit drm/i915: now that all functions are used, remove __maybe_unused drm/i915: check if current->mm is not NULL drivers/gpu/drm/i915/Kconfig | 15 + drivers/gpu/drm/i915/Makefile | 5 + .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 + .../i915/gem/selftests/i915_gem_client_blt.c | 1 + .../i915/gem/selftests/i915_gem_coherency.c | 1 + .../drm/i915/gem/selftests/i915_gem_context.c | 1 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 + .../drm/i915/gem/selftests/i915_gem_migrate.c | 1 + .../drm/i915/gem/selftests/i915_gem_mman.c| 6 + .../drm/i915/gem/selftests/i915_gem_object.c | 2 + .../drm/i915/gem/selftests/i915_gem_phys.c| 1 + drivers/gpu/drm/i915/gt/selftest_context.c| 1 + drivers/gpu/drm/i915/gt/selftest_engine.c | 1 + drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 + .../drm/i915/gt/selftest_engine_heartbeat.c | 1 + drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 + drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 + drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 + drivers/gpu/drm/i915/gt/selftest_lrc.c| 1 + drivers/gpu/drm/i915/gt/selftest_migrate.c| 2 + drivers/gpu/drm/i915/gt/selftest_mocs.c | 1 + drivers/gpu/drm/i915/gt/selftest_reset.c | 1 + drivers/gpu/drm/i915/gt/selftest_ring.c | 1 + .../drm/i915/gt/selftest_ring_submission.c| 1 + drivers/gpu/drm/i915/gt/selftest_slpc.c | 1 + drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 + .../gpu/drm/i915/gt/selftest_workarounds.c| 1 + drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 + drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 1 + .../drm/i915/gt/uc/selftest_guc_hangcheck.c | 1 + .../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 1 + drivers/gpu/drm/i915/i915_selftest.h | 2 + drivers/gpu/drm/i915/selftests/.kunitconfig | 12 + drivers/gpu/drm/i915/selftests/i915_active.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem.c | 1 + .../gpu/drm/i915/selftests/i915_gem_evict.c | 2 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 + drivers/gpu/drm/i915/selftests/i915_kunit.c | 260 ++ drivers/gpu/drm/i915/selftests/i915_perf.c| 1 + drivers/gpu/drm/i915/selftests/i915_request.c | 3 + .../gpu/drm/i915/selftests/i915_selftest.c| 24 +- .../gpu/drm/i915/selftests/i915_sw_fence.c| 1 + drivers/gpu/drm/i915/selftests/i915_syncmap.c | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c | 2 + .../drm/i915/selftests/intel_memory_region.c | 3 + drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 + drivers/gpu/drm/i915/selftests/scatterlist.c | 1 + 47 files changed, 371 insertions(+), 8 deletions(-) create mode 100644 drivers/gpu/drm/i915/selftests/.kunitconfig create mode 100644 drivers/gpu/drm/i915/selftests/i915_kunit.c -- 2.38.1
[PATCH RFC v2 2/8] drm/i915: place selftest preparation on a separate function
The selftest preparation logic should also be used by KUnit. So,
place it on a separate function and export it.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/i915_selftest.h | 2 ++
.../gpu/drm/i915/selftests/i915_selftest.c| 22 ---
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index f54de0499be7..7fab96a42a62 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -44,6 +44,7 @@ struct i915_selftest {
extern struct i915_selftest i915_selftest;
+void i915_prepare_selftests(const char *name);
int i915_mock_selftests(void);
int i915_live_selftests(struct pci_dev *pdev);
int i915_perf_selftests(struct pci_dev *pdev);
@@ -111,6 +112,7 @@ int __i915_subtests(const char *caller,
#else /* !IS_ENABLED(CONFIG_DRM_I915_SELFTEST) */
+static inline void i915_prepare_selftests(const char *) {};
static inline int i915_mock_selftests(void) { return 0; }
static inline int i915_live_selftests(struct pci_dev *pdev) { return 0; }
static inline int i915_perf_selftests(struct pci_dev *pdev) { return 0; }
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 571c9021bd2c..011f7b1f7ff5 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -129,13 +129,8 @@ static void set_default_test_all(struct selftest *st,
unsigned int count)
st[i].enabled = true;
}
-static int __run_selftests(const char *name,
- struct selftest *st,
- unsigned int count,
- void *data)
+void i915_prepare_selftests(const char *name)
{
- int err = 0;
-
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
@@ -144,10 +139,21 @@ static int __run_selftests(const char *name,
msecs_to_jiffies_timeout(i915_selftest.timeout_ms) :
MAX_SCHEDULE_TIMEOUT;
- set_default_test_all(st, count);
-
pr_info(DRIVER_NAME ": Performing %s selftests with st_random_seed=0x%x
st_timeout=%u\n",
name, i915_selftest.random_seed, i915_selftest.timeout_ms);
+}
+EXPORT_SYMBOL_NS_GPL(i915_prepare_selftests, I915_SELFTEST);
+
+static int __run_selftests(const char *name,
+ struct selftest *st,
+ unsigned int count,
+ void *data)
+{
+ int err = 0;
+
+ i915_prepare_selftests(name);
+
+ set_default_test_all(st, count);
/* Tests are listed in order in i915_*_selftests.h */
for (; count--; st++) {
--
2.38.1
[PATCH RFC v2 7/8] drm/i915: now that all functions are used, remove __maybe_unused
The PCI-specific KUnit tests that run in bare metal got added,
so we can remove the __maybe_unused from such functions.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/selftests/i915_kunit.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 6de5d3fa8920..e6dbffe919e6 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -26,7 +26,7 @@
static int n_boards;
static struct pci_dev *dev_i915[MAX_PCI_BOARDS];
-static int __maybe_unused i915_pci_init_suite(struct kunit_suite *suite)
+static int i915_pci_init_suite(struct kunit_suite *suite)
{
struct pci_dev *pdev = NULL;
int i;
@@ -64,7 +64,7 @@ static int __maybe_unused i915_pci_init_suite(struct
kunit_suite *suite)
return 0;
}
-static void __maybe_unused i915_pci_exit_suite(struct kunit_suite *suite)
+static void i915_pci_exit_suite(struct kunit_suite *suite)
{
int i;
@@ -74,8 +74,8 @@ static void __maybe_unused i915_pci_exit_suite(struct
kunit_suite *suite)
n_boards = 0;
}
-static void __maybe_unused run_pci_test(struct kunit *test,
- int (*f)(struct drm_i915_private *i915))
+static void run_pci_test(struct kunit *test,
+int (*f)(struct drm_i915_private *i915))
{
struct drm_i915_private *i915;
int i, ret, disable_display;
--
2.38.1
[PATCH RFC v2 3/8] drm/i915: allow running mock selftests via Kunit
ap [ 615.995098] i915: Running i915_vma_mock_selftests/igt_vma_partial [ 618.518421] ok 14 - mock_vma [ 618.519367] mock: [drm] Using Transparent Hugepages [ 618.528625] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 618.536467] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 618.544330] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 618.552318] i915: Running i915_gem_evict_mock_selftests/igt_evict_something [ 618.697340] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_vma [ 618.836366] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_cache_color [ 618.849926] i915: Running i915_gem_evict_mock_selftests/igt_evict_vm [ 618.992647] i915: Running i915_gem_evict_mock_selftests/igt_overcommit [ 619.170384] ok 15 - mock_evict [ 619.171566] mock: [drm] Using Transparent Hugepages [ 619.181351] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 619.189520] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 619.197366] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 619.205322] i915: Running i915_gem_gtt_mock_selftests/igt_mock_drunk [ 619.712643] drunk_hole timed out after 41097/524288 [ 619.717987] i915: Running i915_gem_gtt_mock_selftests/igt_mock_walk [ 620.225588] walk_hole timed out at a692000 [ 620.230687] i915: Running i915_gem_gtt_mock_selftests/igt_mock_pot [ 620.976730] pot_hole timed out after 19/33 [ 620.981596] i915: Running i915_gem_gtt_mock_selftests/igt_mock_fill [ 621.491729] fill_hole timed out (npages=1, prime=257) [ 621.497424] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_reserve [ 621.620470] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_insert [ 621.891015] ok 16 - mock_gtt [ 621.892018] mock: [drm] Using Transparent Hugepages [ 621.901620] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 621.909449] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 621.917347] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 621.925497] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_exhaust_device_supported_pages [ 621.937541] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages [ 621.947479] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_misaligned_dma [ 622.032179] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_huge_fill [ 622.540726] igt_mock_ppgtt_huge_fill timed out at size 61313024 [ 622.547707] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_64K [ 622.944941] ok 17 - mock_hugepages [ 622.945866] mock: [drm] Using Transparent Hugepages [ 622.956054] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 622.963891] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 622.971705] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 622.979664] i915: Running intel_memory_region_mock_selftests/igt_mock_reserve [ 623.006381] i915: Running intel_memory_region_mock_selftests/igt_mock_fill [ 623.057022] i915: Running intel_memory_region_mock_selftests/igt_mock_contiguous [ 624.040905] i915: Running intel_memory_region_mock_selftests/igt_mock_splintered_region [ 624.075553] i915: Running intel_memory_region_mock_selftests/igt_mock_max_segment [ 624.108598] i915: Running intel_memory_region_mock_selftests/igt_mock_io_size [ 624.116097] igt_mock_io_size with ps=1000, io_size=a7823000, total=1b5fee000 [ 624.133227] igt_mock_io_size mappable theft=(632MiB/2680MiB), total=7007MiB [ 624.204955] ok 18 - mock_memory_region [ 624.204964] # i915 mock selftests: pass:18 fail:0 skip:0 total:18 [ 624.209921] # Totals: pass:18 fail:0 skip:0 total:18 [ 624.216762] ok 1 - i915 mock selftests. They could be parsed with kunit.py with: echo "[0.00] TAP version 14" >logs dmesg >>logs ./tools/testing/kunit/kunit.py parse logs Note: kunit.py is currently broken with modules, not producing any results if "TAP version xx" is not found. It also shows the results duplicated. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH RFC v2 0/8] at: https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/ drivers/gpu/drm/i915/Kconfig| 15 drivers/gpu/drm
[PATCH RFC v2 1/8] drm/i915: export all selftest functions
In order to prepare for a new KUnit module that will run
selftests, export all selftest functions to I915_SELFTEST
namespace.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 2 ++
drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c| 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 ++
drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c| 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 1 +
drivers/gpu/drm/i915/gem/selftests/i915_gem_object.c | 2 ++
drivers/gpu/drm/i915/gem/selftests/i915_gem_phys.c | 1 +
drivers/gpu/drm/i915/gt/selftest_context.c | 1 +
drivers/gpu/drm/i915/gt/selftest_engine.c| 1 +
drivers/gpu/drm/i915/gt/selftest_engine_cs.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_engine_heartbeat.c | 1 +
drivers/gpu/drm/i915/gt/selftest_execlists.c | 1 +
drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 1 +
drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_mocs.c | 1 +
drivers/gpu/drm/i915/gt/selftest_reset.c | 1 +
drivers/gpu/drm/i915/gt/selftest_ring.c | 1 +
drivers/gpu/drm/i915/gt/selftest_ring_submission.c | 1 +
drivers/gpu/drm/i915/gt/selftest_slpc.c | 1 +
drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 ++
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 1 +
drivers/gpu/drm/i915/gt/st_shmem_utils.c | 1 +
drivers/gpu/drm/i915/gt/uc/selftest_guc.c| 1 +
drivers/gpu/drm/i915/gt/uc/selftest_guc_hangcheck.c | 1 +
drivers/gpu/drm/i915/gt/uc/selftest_guc_multi_lrc.c | 1 +
drivers/gpu/drm/i915/selftests/i915_active.c | 1 +
drivers/gpu/drm/i915/selftests/i915_gem.c| 1 +
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c| 2 ++
drivers/gpu/drm/i915/selftests/i915_perf.c | 1 +
drivers/gpu/drm/i915/selftests/i915_request.c| 3 +++
drivers/gpu/drm/i915/selftests/i915_selftest.c | 2 ++
drivers/gpu/drm/i915/selftests/i915_sw_fence.c | 1 +
drivers/gpu/drm/i915/selftests/i915_syncmap.c| 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c| 2 ++
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 3 +++
drivers/gpu/drm/i915/selftests/intel_uncore.c| 2 ++
drivers/gpu/drm/i915/selftests/scatterlist.c | 1 +
42 files changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index 0cb99e75b0bc..7cbd01dbff4c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1948,6 +1948,7 @@ int i915_gem_huge_page_mock_selftests(void)
mock_destroy_device(dev_priv);
return err;
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_huge_page_mock_selftests, I915_SELFTEST);
int i915_gem_huge_page_live_selftests(struct drm_i915_private *i915)
{
@@ -1970,3 +1971,4 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
return i915_live_subtests(tests, i915);
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_huge_page_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index 9a6a6b5b722b..9f1ff1e783f6 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -763,3 +763,4 @@ int i915_gem_client_blt_live_selftests(struct
drm_i915_private *i915)
return i915_live_subtests(tests, i915);
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_client_blt_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index a666d7e610f5..1fcbc68c9c0f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -436,3 +436,4 @@ int i915_gem_coherency_live_selftests(struct
drm_i915_private *i915)
return i915_live_subtests(tests, i915);
}
+EXPORT_SYMBOL_NS_GPL(i915_gem_coherency_live_selftests, I915_SELFTEST);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem
[PATCH RFC v2 4/8] drm/i915: add support to run KUnit tests on bare metal
Add a logic to seek for PCI devices and to run tests on
them, if the tests are willing to run on physical hardware,
instead of using Qemu.
Later patches will add the KUnit tests. So, for now, mark
such functions with __maybe_unused, to avoid build issues
with WERROR.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/selftests/i915_kunit.c | 100
1 file changed, 100 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 731b84a1fdc3..430610864f6e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -8,9 +8,109 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#include
#include
+#include "i915_drv.h"
#include "i915_selftest.h"
+#define MAX_PCI_BOARDS 8
+
+/*
+ * PCI selftest support
+ *
+ * It is possible to run tests that demands hardware in bare metal.
+ *
+ * Add a logic to detect and get PCI devices using i915 driver, up to
+ * MAX_PCI_BOARDS devices.
+ */
+
+static int n_boards;
+static struct pci_dev *dev_i915[MAX_PCI_BOARDS];
+static int __maybe_unused i915_pci_init_suite(struct kunit_suite *suite)
+{
+ struct pci_dev *pdev = NULL;
+ int i;
+
+ /* Check for PCI devices with i915 driver */
+ do {
+ /*
+* Let's search all devices at the PCI ID. We could, instead,
+* use include/drm/i915_pciids.h, but that would mean a much
+* more complex code, and won't still warrant that the device
+* was bound to i915 driver. So, let's check the driver's
+* name instead.
+*/
+ pdev = pci_get_device(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pdev);
+ if (pdev) {
+ if (pdev->driver && !strcmp(pdev->driver->name,
"i915")) {
+ pr_info("%s: it is a i915 device.\n",
+ pci_name(pdev));
+
+ for (i = 0; i < n_boards; i++) {
+ if (pdev == dev_i915[i]) {
+ pci_dev_put(pdev);
+ continue;
+ }
+ }
+ dev_i915[n_boards++] = pdev;
+ if (n_boards >= MAX_PCI_BOARDS)
+ break;
+ } else {
+ pci_dev_put(pdev);
+ }
+ }
+ } while (pdev);
+
+ return 0;
+}
+
+static void __maybe_unused i915_pci_exit_suite(struct kunit_suite *suite)
+{
+ int i;
+
+ for (i = 0; i < n_boards; i++)
+ pci_dev_put(dev_i915[i]);
+
+ n_boards = 0;
+}
+
+static void __maybe_unused run_pci_test(struct kunit *test,
+ int (*f)(struct drm_i915_private *i915))
+{
+ struct drm_i915_private *i915;
+ int i, ret, disable_display;
+
+ if (!n_boards)
+ kunit_skip(test, "runs only on i915 hardware\n");
+
+ for (i = 0; i < n_boards; i++) {
+ i915 = pdev_to_i915(dev_i915[i]);
+
+ cond_resched();
+ if (signal_pending(current))
+ return;
+
+ pr_info("Running %s on %s\n",
+ test->name, pci_name(dev_i915[i]));
+
+ /* FIXME: is it ok to disable_display here? */
+ disable_display = i915->params.disable_display;
+ i915->params.disable_display = 1;
+ ret = f(i915);
+ i915->params.disable_display = disable_display;
+
+ if (ret == -EINTR && !signal_pending(current))
+ ret = 0;
+
+ if (WARN(ret > 0 || ret == -ENOTTY,
+ "%s returned %d, conflicting with selftest's magic
values!\n",
+ test->name, ret))
+ ret = -EINVAL;
+
+ KUNIT_EXPECT_EQ(test, ret, 0);
+ }
+}
+
/*
* Test run logic, similar to what i915 selftest does
*/
--
2.38.1
[PATCH RFC v2 8/8] drm/i915: check if current->mm is not NULL
The mmap tests require mm in order to work. Failing to do that
will cause a crash:
[ 316.820722] BUG: kernel NULL pointer dereference, address: 00e8
[ 316.822517] #PF: supervisor write access in kernel mode
[ 316.823430] #PF: error_code(0x0002) - not-present page
[ 316.824390] PGD 0 P4D 0
[ 316.825357] Oops: 0002 [#1] PREEMPT SMP NOPTI
[ 316.826350] CPU: 0 PID: 1517 Comm: kunit_try_catch Tainted: G U
N 6.1.0-rc2-drm-266703e6f163+ #14
[ 316.827503] Hardware name: Intel Corporation Tiger Lake Client
Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.3243.A01.2006102133
06/10/2020
[ 316.828633] RIP: 0010:down_write_killable+0x50/0x110
[ 316.829756] Code: 24 10 45 31 c9 31 c9 41 b8 01 00 00 00 31 d2 31 f6 48 89
ef e8 e1 74 4a ff bf 01 00 00 00 e8 87 d6 46 ff 31 c0 ba 01 00 00 00 48 0f
b1 13 0f 94 c0 5a 84 c0 74 62 8b 05 49 12 e4 00 85 c0 74
[ 316.830896] RSP: 0018:c90001eabc58 EFLAGS: 00010246
[ 316.832008] RAX: RBX: 00e8 RCX:
[ 316.833141] RDX: 0001 RSI: 81c94fc9 RDI: 81c94fc9
[ 316.834195] RBP: 0158 R08: 0001 R09:
[ 316.835231] R10: R11: 8883a13350b8 R12: 0002
[ 316.836259] R13: 0001 R14: 0010 R15: 00e8
[ 316.837237] FS: () GS:8883a380()
knlGS:
[ 316.838214] CS: 0010 DS: ES: CR0: 80050033
[ 316.839190] CR2: 00e8 CR3: 02812003 CR4: 00770ef0
[ 316.840147] PKRU: 5554
[ 316.841099] Call Trace:
[ 316.842047]
[ 316.842990] ? vm_mmap_pgoff+0x78/0x150
[ 316.843936] vm_mmap_pgoff+0x78/0x150
[ 316.844884] igt_mmap_offset+0x178/0x1b9 [i915]
[ 316.846119] __igt_mmap+0xfe/0x680 [i915]
Unfortunately, when KUnit module runs, it doesn't create an
user context, causing mmap tests to fail.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index add5ae56cd89..2c5f93e946b5 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -1845,6 +1845,11 @@ int i915_gem_mman_live_selftests(struct drm_i915_private
*i915)
SUBTEST(igt_mmap_gpu),
};
+ if (!current->mm) {
+ pr_err("Test called without an user context!\n");
+ return -EINVAL;
+ }
+
return i915_live_subtests(tests, i915);
}
EXPORT_SYMBOL_NS_GPL(i915_gem_mman_live_selftests, I915_SELFTEST);
--
2.38.1
[PATCH RFC v2 6/8] drm/i915: add perf selftests to KUnit
Now that i915 KUnit has PCI support, add perf tests as well.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/selftests/i915_kunit.c | 34 -
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index f5281c866d75..6de5d3fa8920 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -202,6 +202,30 @@ static struct kunit_case i915_live_tests[] = {
};
#undef selftest
+/*
+ * Suite 3: live selftests
+ */
+
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);
+#include "i915_perf_selftests.h"
+#undef selftest
+
+/* Create selftest functions */
+#define selftest(__x, __y) \
+ static void perf_##__x(struct kunit *test) {\
+ run_pci_test(test, __y);\
+ }
+#include "i915_perf_selftests.h"
+#undef selftest
+
+/* Fill tests array */
+#define selftest(__x, __y) KUNIT_CASE(perf_##__x),
+static struct kunit_case i915_perf_tests[] = {
+#include "i915_perf_selftests.h"
+ {}
+};
+#undef selftest
+
/*
* Declare test suites
*/
@@ -219,10 +243,18 @@ static struct kunit_suite i915_test_suites[] = {
.suite_init = i915_pci_init_suite,
.suite_exit = i915_pci_exit_suite,
},
+ {
+ .name = "i915 perf selftests",
+ .test_cases = i915_perf_tests,
+ .init = initialize_i915_selftests,
+ .suite_init = i915_pci_init_suite,
+ .suite_exit = i915_pci_exit_suite,
+ },
};
kunit_test_suites(_test_suites[0],
- _test_suites[1]);
+ _test_suites[1],
+ _test_suites[2]);
MODULE_LICENSE("GPL v2");
MODULE_IMPORT_NS(I915_SELFTEST);
--
2.38.1
[PATCH RFC v2 5/8] drm/i915: add live selftests to KUnit
Now that i915 KUnit has PCI support, add live tests as well.
NOTE: currently, some tests are failing when excecuting via
KUnit. I'll do a further investigation to check why, and if
this patch can be safely merged or not.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH RFC v2 0/8] at:
https://lore.kernel.org/all/cover.1667486144.git.mche...@kernel.org/
drivers/gpu/drm/i915/selftests/i915_kunit.c | 35 -
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_kunit.c
b/drivers/gpu/drm/i915/selftests/i915_kunit.c
index 430610864f6e..f5281c866d75 100644
--- a/drivers/gpu/drm/i915/selftests/i915_kunit.c
+++ b/drivers/gpu/drm/i915/selftests/i915_kunit.c
@@ -177,6 +177,31 @@ static struct kunit_case i915_mock_tests[] = {
};
#undef selftest
+/*
+ * Suite 2: live selftests
+ */
+
+/* Declare selftest functions */
+#define selftest(x, __y) int __y(struct drm_i915_private *i915);
+#include "i915_live_selftests.h"
+#undef selftest
+
+/* Create selftest functions */
+#define selftest(__x, __y) \
+ static void live_##__x(struct kunit *test) {\
+ run_pci_test(test, __y);\
+ }
+#include "i915_live_selftests.h"
+#undef selftest
+
+/* Fill tests array */
+#define selftest(__x, __y) KUNIT_CASE(live_##__x),
+static struct kunit_case i915_live_tests[] = {
+#include "i915_live_selftests.h"
+ {}
+};
+#undef selftest
+
/*
* Declare test suites
*/
@@ -187,9 +212,17 @@ static struct kunit_suite i915_test_suites[] = {
.test_cases = i915_mock_tests,
.init = initialize_i915_selftests,
},
+ {
+ .name = "i915 live selftests",
+ .test_cases = i915_live_tests,
+ .init = initialize_i915_selftests,
+ .suite_init = i915_pci_init_suite,
+ .suite_exit = i915_pci_exit_suite,
+ },
};
-kunit_test_suites(i915_test_suites);
+kunit_test_suites(_test_suites[0],
+ _test_suites[1]);
MODULE_LICENSE("GPL v2");
MODULE_IMPORT_NS(I915_SELFTEST);
--
2.38.1
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Thu, 3 Nov 2022 10:48:40 +0100 Mauro Carvalho Chehab wrote: > On Sun, 28 Aug 2022 21:09:19 -0300 > Isabella Basso wrote: > > > This adds functions for both executing the tests as well as parsing (K)TAP > > kmsg output, as per the KTAP spec [1]. > > > > [1] https://www.kernel.org/doc/html/latest/dev-tools/ktap.html > > > > Signed-off-by: Isabella Basso > > Hi Isabella, > > I'm doing some tests here with my i915 KUnit patch series. > > There's a problem with the way it is currently parsing the KTAP logs on > IGT. It sounds that it is parsing the data only at the end, and not as > they arrive. That's bad, as if something goes wrong, the previously > reported data is still useful. > > Also, when there's a crash, the IGT process is getting segmentation > fault. So, the end result is that nothing is actually reported. > > $ sudo ./build/tests/i915_selftest > IGT-Version: 1.26-gbab20eb65 (x86_64) (Linux: > 6.1.0-rc2-drm-990037e9984e+ x86_64) > Segmentation fault (core dumped) Another issue related to KTAP parsing: this is the output before the KUnit patch, which is used by IGT CI to check the test results, for i915 mock selftest: IGT-Version: 1.26-gbab20eb65 (x86_64) (Linux: 6.1.0-rc2-drm-8dacd9299fcc+ x86_64) process 659 (alsactl) is using audio device. Should be terminated. Starting subtest: mock Starting dynamic subtest: sanitycheck Dynamic subtest sanitycheck: SUCCESS (0.648s) Starting dynamic subtest: shmem Dynamic subtest shmem: SUCCESS (0.557s) Starting dynamic subtest: fence Dynamic subtest fence: SUCCESS (8.078s) Starting dynamic subtest: scatterlist Dynamic subtest scatterlist: SUCCESS (1.531s) Starting dynamic subtest: syncmap Dynamic subtest syncmap: SUCCESS (2.875s) Starting dynamic subtest: uncore Dynamic subtest uncore: SUCCESS (0.525s) Starting dynamic subtest: ring Dynamic subtest ring: SUCCESS (0.529s) Starting dynamic subtest: engine Dynamic subtest engine: SUCCESS (0.527s) Starting dynamic subtest: timelines Dynamic subtest timelines: SUCCESS (4.177s) Starting dynamic subtest: requests Dynamic subtest requests: SUCCESS (3.561s) Starting dynamic subtest: objects Dynamic subtest objects: SUCCESS (0.596s) Starting dynamic subtest: phys Dynamic subtest phys: SUCCESS (0.602s) Starting dynamic subtest: dmabuf Dynamic subtest dmabuf: SUCCESS (0.605s) Starting dynamic subtest: vma Dynamic subtest vma: SUCCESS (9.724s) Starting dynamic subtest: evict Dynamic subtest evict: SUCCESS (1.660s) Starting dynamic subtest: gtt Dynamic subtest gtt: SUCCESS (3.309s) Starting dynamic subtest: hugepages Dynamic subtest hugepages: SUCCESS (1.665s) Starting dynamic subtest: memory_region Dynamic subtest memory_region: SUCCESS (2.789s) Subtest mock: SUCCESS (43.961s) This is the logs after your patch: Missing test version string Executing 18 tests in: i915 mock selftests kmsg> 1..18 kmsg> i915: i915_mock_sanitycheck() - ok! kmsg> ok 1 - mock_sanitycheck kmsg> i915: Running shmem_utils_mock_selftests/igt_shmem_basic kmsg> ok 2 - mock_shmem kmsg> i915: Running i915_sw_fence_mock_selftests/test_self kmsg> i915: Running i915_sw_fence_mock_selftests/test_dag kmsg> i915: Running i915_sw_fence_mock_selftests/test_AB kmsg> i915: Running i915_sw_fence_mock_selftests/test_ABC kmsg> i915: Running i915_sw_fence_mock_selftests/test_AB_C kmsg> i915: Running i915_sw_fence_mock_selftests/test_C_AB kmsg> i915: Running i915_sw_fence_mock_selftests/test_chain kmsg> i915: Running i915_sw_fence_mock_selftests/test_ipc kmsg> i915: Running i915_sw_fence_mock_selftests/test_timer kmsg> i915: Running i915_sw_fence_mock_selftests/test_dma_fence kmsg> Asynchronous wait on fence mock:mock:0 timed out (hint:fence_notify [i915]) kmsg> ok 3 - mock_fence kmsg> i915: Running scatterlist_mock_selftests/igt_sg_alloc kmsg> sg_alloc_table timed out kmsg> i915: Running scatterlist_mock_selftests/igt_sg_trim kmsg> i915_sg_trim timed out kmsg> ok 4 - mock_scatterlist kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_init kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_one kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_join_above kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_join_below kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_neighbours kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_compact kmsg> i915: Running i915_syncmap_mock_selftests/igt_syncmap_random kmsg> ok 5 - mock_syncmap kmsg> ok 6 - mock_uncore kmsg> i915: Running intel_ring_mock_selftests/igt_ring_direction kmsg> ok 7 - mock_ring kmsg> i915: Running intel_engine_cs_mock_selftests/intel_mmio_bases_check kmsg> ok 8 - mock_engine kmsg> i915: Running intel_timeline_mock_selftests/mock_hwsp_freelist kmsg> mock: [drm] Using Transparent Hugepages kmsg> mock: [drm] I
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Sun, 28 Aug 2022 21:09:19 -0300 Isabella Basso wrote: > This adds functions for both executing the tests as well as parsing (K)TAP > kmsg output, as per the KTAP spec [1]. > > [1] https://www.kernel.org/doc/html/latest/dev-tools/ktap.html > > Signed-off-by: Isabella Basso Hi Isabella, I'm doing some tests here with my i915 KUnit patch series. There's a problem with the way it is currently parsing the KTAP logs on IGT. It sounds that it is parsing the data only at the end, and not as they arrive. That's bad, as if something goes wrong, the previously reported data is still useful. Also, when there's a crash, the IGT process is getting segmentation fault. So, the end result is that nothing is actually reported. $ sudo ./build/tests/i915_selftest IGT-Version: 1.26-gbab20eb65 (x86_64) (Linux: 6.1.0-rc2-drm-990037e9984e+ x86_64) Segmentation fault (core dumped) However, the logs are there (see enclosed). In this specific case, there was a GPU hang while running one of the tests on a real hardware, which is something that it is actually expected at development time. FYI, those are the logs (when using the patches I'm still developing to run selftests via KUnit - currently broken): [ 360.446771] [IGT] i915_selftest: executing [ 360.465611] # Subtest: i915 mock selftests [ 360.465614] 1..18 [ 360.466163] i915: i915_mock_sanitycheck() - ok! [ 360.466273] ok 1 - mock_sanitycheck [ 360.466428] i915: Running shmem_utils_mock_selftests/igt_shmem_basic [ 360.466500] ok 2 - mock_shmem [ 360.466592] i915: Running i915_sw_fence_mock_selftests/test_self [ 360.466633] i915: Running i915_sw_fence_mock_selftests/test_dag [ 360.466645] i915: Running i915_sw_fence_mock_selftests/test_AB [ 360.466692] i915: Running i915_sw_fence_mock_selftests/test_ABC [ 360.466729] i915: Running i915_sw_fence_mock_selftests/test_AB_C [ 360.466764] i915: Running i915_sw_fence_mock_selftests/test_C_AB [ 360.466800] i915: Running i915_sw_fence_mock_selftests/test_chain [ 360.502903] i915: Running i915_sw_fence_mock_selftests/test_ipc [ 360.505338] i915: Running i915_sw_fence_mock_selftests/test_timer [ 366.490222] i915: Running i915_sw_fence_mock_selftests/test_dma_fence [ 367.146210] Asynchronous wait on fence mock:mock:0 timed out (hint:fence_notify [i915]) [ 367.147793] ok 3 - mock_fence [ 367.148388] i915: Running scatterlist_mock_selftests/igt_sg_alloc [ 367.648994] sg_alloc_table timed out [ 367.649003] i915: Running scatterlist_mock_selftests/igt_sg_trim [ 368.149994] i915_sg_trim timed out [ 368.150095] ok 4 - mock_scatterlist [ 368.150423] i915: Running i915_syncmap_mock_selftests/igt_syncmap_init [ 368.150446] i915: Running i915_syncmap_mock_selftests/igt_syncmap_one [ 368.651091] i915: Running i915_syncmap_mock_selftests/igt_syncmap_join_above [ 368.651240] i915: Running i915_syncmap_mock_selftests/igt_syncmap_join_below [ 368.652311] i915: Running i915_syncmap_mock_selftests/igt_syncmap_neighbours [ 369.965095] i915: Running i915_syncmap_mock_selftests/igt_syncmap_compact [ 369.965989] i915: Running i915_syncmap_mock_selftests/igt_syncmap_random [ 370.482663] ok 5 - mock_syncmap [ 370.482853] ok 6 - mock_uncore [ 370.483119] i915: Running intel_ring_mock_selftests/igt_ring_direction [ 370.483171] ok 7 - mock_ring [ 370.483328] i915: Running intel_engine_cs_mock_selftests/intel_mmio_bases_check [ 370.483399] ok 8 - mock_engine [ 370.483456] i915: Running intel_timeline_mock_selftests/mock_hwsp_freelist [ 370.484028] mock: [drm] Using Transparent Hugepages [ 370.484164] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 370.484195] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 370.484224] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 372.258731] i915: Running intel_timeline_mock_selftests/igt_sync [ 372.262110] i915: Running intel_timeline_mock_selftests/bench_sync [ 372.463995] bench_sync: 43371 random insertions, 2323ns/insert [ 372.467075] bench_sync: 43371 random lookups, 65ns/lookup [ 372.702995] bench_sync: 836833 in-order insertions, 119ns/insert [ 372.705534] bench_sync: 836833 in-order lookups, 3ns/lookup [ 372.914994] bench_sync: 6214645 repeated insert/lookups, 11ns/op [ 373.015994] bench_sync: 19605180 cyclic/1 insert/lookups, 5ns/op [ 373.116994] bench_sync: 18945372 cyclic/2 insert/lookups, 5ns/op [ 373.217994] bench_sync: 16210409 cyclic/3 insert/lookups, 6ns/op [ 373.318995] bench_sync: 14141870 cyclic/5 insert/lookups, 7ns/op [ 373.419994] bench_sync: 12728929 cyclic/8 insert/lookups, 7ns/op [ 373.520995] bench_sync: 9070286 cyclic/13 insert/lookups, 11ns/op [ 373.639995] bench_sync: 52516 cyclic/21 insert/lookups, 1921ns/op [ 373.762920] ok 9 - mock_timelines [ 373.763522] mock: [drm] Using Transparent Hugepages [ 373.763575] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Tue, 1 Nov 2022 14:17:26 -0300 Isabella Basso wrote: > Hi, Mauro, > > > Am 01/11/2022 um 9:33 AM schrieb Mauro Carvalho Chehab > > : > > > > Hi Isabella, > > > > On Mon, 19 Sep 2022 17:43:19 -0300 > > Isabella Basso wrote: > > > >>> Do you want to _require_ KUnit be built as a module, rather than built-in > >>> here? > >> > >> I’ll change the comment and the warning in v3 to clarify this. > > > > When do you intend to submit v3? > > I’m currently waiting for my peers to review some refactorings and test > things thoroughly. I hope to submit it in a week or two. Sorry it’s taking so > long. No problem. In the mean time, I'll try to do some tests with the current version. Btw, if you want, you can also check the RFC patch I submitted today, adding KUnit support for i915: https://patchwork.freedesktop.org/patch/509448/?series=110384=1 The tests there are hardware-independent, but they need to be built using x86_64 arch, due to i915 dependencies. Regards, Mauro
[PATCH RFC] drm/i915: allow running mock selftests via Kunit
ap [ 615.995098] i915: Running i915_vma_mock_selftests/igt_vma_partial [ 618.518421] ok 14 - mock_vma [ 618.519367] mock: [drm] Using Transparent Hugepages [ 618.528625] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 618.536467] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 618.544330] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 618.552318] i915: Running i915_gem_evict_mock_selftests/igt_evict_something [ 618.697340] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_vma [ 618.836366] i915: Running i915_gem_evict_mock_selftests/igt_evict_for_cache_color [ 618.849926] i915: Running i915_gem_evict_mock_selftests/igt_evict_vm [ 618.992647] i915: Running i915_gem_evict_mock_selftests/igt_overcommit [ 619.170384] ok 15 - mock_evict [ 619.171566] mock: [drm] Using Transparent Hugepages [ 619.181351] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 619.189520] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 619.197366] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 619.205322] i915: Running i915_gem_gtt_mock_selftests/igt_mock_drunk [ 619.712643] drunk_hole timed out after 41097/524288 [ 619.717987] i915: Running i915_gem_gtt_mock_selftests/igt_mock_walk [ 620.225588] walk_hole timed out at a692000 [ 620.230687] i915: Running i915_gem_gtt_mock_selftests/igt_mock_pot [ 620.976730] pot_hole timed out after 19/33 [ 620.981596] i915: Running i915_gem_gtt_mock_selftests/igt_mock_fill [ 621.491729] fill_hole timed out (npages=1, prime=257) [ 621.497424] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_reserve [ 621.620470] i915: Running i915_gem_gtt_mock_selftests/igt_gtt_insert [ 621.891015] ok 16 - mock_gtt [ 621.892018] mock: [drm] Using Transparent Hugepages [ 621.901620] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 621.909449] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 621.917347] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 621.925497] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_exhaust_device_supported_pages [ 621.937541] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_memory_region_huge_pages [ 621.947479] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_misaligned_dma [ 622.032179] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_huge_fill [ 622.540726] igt_mock_ppgtt_huge_fill timed out at size 61313024 [ 622.547707] i915: Running i915_gem_huge_page_mock_selftests/igt_mock_ppgtt_64K [ 622.944941] ok 17 - mock_hugepages [ 622.945866] mock: [drm] Using Transparent Hugepages [ 622.956054] mock: [drm] Incompatible option enable_guc=3 - GuC is not supported! [ 622.963891] mock: [drm] Incompatible option enable_guc=3 - HuC is not supported! [ 622.971705] mock: [drm] Incompatible option enable_guc=3 - GuC submission is N/A [ 622.979664] i915: Running intel_memory_region_mock_selftests/igt_mock_reserve [ 623.006381] i915: Running intel_memory_region_mock_selftests/igt_mock_fill [ 623.057022] i915: Running intel_memory_region_mock_selftests/igt_mock_contiguous [ 624.040905] i915: Running intel_memory_region_mock_selftests/igt_mock_splintered_region [ 624.075553] i915: Running intel_memory_region_mock_selftests/igt_mock_max_segment [ 624.108598] i915: Running intel_memory_region_mock_selftests/igt_mock_io_size [ 624.116097] igt_mock_io_size with ps=1000, io_size=a7823000, total=1b5fee000 [ 624.133227] igt_mock_io_size mappable theft=(632MiB/2680MiB), total=7007MiB [ 624.204955] ok 18 - mock_memory_region [ 624.204964] # i915 mock selftests: pass:18 fail:0 skip:0 total:18 [ 624.209921] # Totals: pass:18 fail:0 skip:0 total:18 [ 624.216762] ok 1 - i915 mock selftests. They could be parsed with kunit.py with: echo "[0.00] TAP version 14" >logs dmesg >>logs ./tools/testing/kunit/kunit.py parse logs Note: kunit.py is currently broken with modules, not producing any results if "TAP version xx" is not found. It also shows the results duplicated. Signed-off-by: Mauro Carvalho Chehab --- drivers/gpu/drm/i915/Kconfig | 15 ++ drivers/gpu/drm/i915/Makefile | 5 ++ .../gpu/drm/i915/gem/selftests/huge_pages.c | 1 + .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 1 + .../drm/i915/gem/selftests/
Re: [igt-dev] [PATCH i-g-t v2 4/4] tests: DRM selftests: switch to KUnit
On Tue, 1 Nov 2022 15:16:02 +0200
Petri Latvala wrote:
> On Tue, Nov 01, 2022 at 01:54:25PM +0100, Mauro Carvalho Chehab wrote:
> > On Tue, 20 Sep 2022 11:18:25 +0300
> > Petri Latvala wrote:
> >
> > > On Sun, Aug 28, 2022 at 09:09:20PM -0300, Isabella Basso wrote:
> > > > As the DRM selftests are now using KUnit [1], update IGT tests as well.
> > > >
> > > > [1] -
> > > > https://lore.kernel.org/all/20220708203052.236290-1-maira.ca...@usp.br/
> > > >
> > > > Signed-off-by: Isabella Basso
> > > > ---
> > > > tests/drm_buddy.c| 7 ---
> > > > tests/drm_mm.c | 7 ---
> > > > tests/kms_selftest.c | 12 +---
> > > > 3 files changed, 17 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/tests/drm_buddy.c b/tests/drm_buddy.c
> > > > index 06876e0c..74c06dce 100644
> > > > --- a/tests/drm_buddy.c
> > > > +++ b/tests/drm_buddy.c
> > > > @@ -6,9 +6,10 @@
> > > > #include "igt.h"
> > > > #include "igt_kmod.h"
> > > >
> > > > -IGT_TEST_DESCRIPTION("Basic sanity check of DRM's buddy allocator
> > > > (struct drm_buddy)");
> > > > +IGT_TEST_DESCRIPTION("Basic sanity check of DRM's buddy allocator
> > > > (struct \
> > > > + drm_buddy) using KUnit");
> > > >
> > > > -igt_main
> > > > +igt_simple_main
> > > > {
> > > > - igt_kselftests("test-drm_buddy", NULL, NULL, NULL);
> > > > + igt_kunit("drm_buddy_test", NULL);
> > > > }
> > >
> > > With kselftests we had the ability to only run a specified set of
> > > tests, and with or without selection, we had sub-results for each
> > > through dynamic subtests. Does kunit have that possibility? I mean I
> > > know kunit itself does but what about igt_kunit()?
> >
> > I don't think so. I created a KUnit with the mock selftests:
> >
> > $ modinfo test-i915-mock
> > filename:
> > /lib/modules/6.1.0-rc2-drm-b1cab854a639+/kernel/drivers/gpu/drm/i915/test-i915-mock.ko
> > import_ns: I915_SELFTEST
> > license:GPL v2
> > depends:i915
> > retpoline: Y
> > intree: Y
> > name: test_i915_mock
> > vermagic: 6.1.0-rc2-drm-b1cab854a639+ SMP preempt mod_unload
> >
> > There's no module parameters. Just loading it makes all tests
> > there to run.
>
> Ah, the selection is in kunit.ko itself. kunit.filter_glob, set from
> kunit.py with
>
> positional arguments:
> filter_glob Filter which KUnit test suites/tests run at
> boot-time, e.g. list* or list*.*del_test
> \
Gah, permissions are 0:
module_param_named(filter_glob, filter_glob_param, charp, 0);
You can't even see what filters were set via sysfs:
$ ls /sys/module/kunit/parameters/
stats_enabled
So, once set, there's no way to change it.
I wonder why this isn't 0x644.
It sounds that, if we want to control it at runtime, we'll need to
build with kunit as module, and unload/reload it every time if/when
we want to run IGT with a different filtering ruleset.
Regards,
Mauro
Re: [igt-dev] [PATCH i-g-t v2 4/4] tests: DRM selftests: switch to KUnit
On Tue, 20 Sep 2022 11:18:25 +0300
Petri Latvala wrote:
> On Sun, Aug 28, 2022 at 09:09:20PM -0300, Isabella Basso wrote:
> > As the DRM selftests are now using KUnit [1], update IGT tests as well.
> >
> > [1] -
> > https://lore.kernel.org/all/20220708203052.236290-1-maira.ca...@usp.br/
> >
> > Signed-off-by: Isabella Basso
> > ---
> > tests/drm_buddy.c| 7 ---
> > tests/drm_mm.c | 7 ---
> > tests/kms_selftest.c | 12 +---
> > 3 files changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/tests/drm_buddy.c b/tests/drm_buddy.c
> > index 06876e0c..74c06dce 100644
> > --- a/tests/drm_buddy.c
> > +++ b/tests/drm_buddy.c
> > @@ -6,9 +6,10 @@
> > #include "igt.h"
> > #include "igt_kmod.h"
> >
> > -IGT_TEST_DESCRIPTION("Basic sanity check of DRM's buddy allocator (struct
> > drm_buddy)");
> > +IGT_TEST_DESCRIPTION("Basic sanity check of DRM's buddy allocator (struct \
> > + drm_buddy) using KUnit");
> >
> > -igt_main
> > +igt_simple_main
> > {
> > - igt_kselftests("test-drm_buddy", NULL, NULL, NULL);
> > + igt_kunit("drm_buddy_test", NULL);
> > }
>
> With kselftests we had the ability to only run a specified set of
> tests, and with or without selection, we had sub-results for each
> through dynamic subtests. Does kunit have that possibility? I mean I
> know kunit itself does but what about igt_kunit()?
I don't think so. I created a KUnit with the mock selftests:
$ modinfo test-i915-mock
filename:
/lib/modules/6.1.0-rc2-drm-b1cab854a639+/kernel/drivers/gpu/drm/i915/test-i915-mock.ko
import_ns: I915_SELFTEST
license:GPL v2
depends:i915
retpoline: Y
intree: Y
name: test_i915_mock
vermagic: 6.1.0-rc2-drm-b1cab854a639+ SMP preempt mod_unload
There's no module parameters. Just loading it makes all tests
there to run.
OK, with the current implementation, we could have one module per subtest,
but that sounds overkill.
Another possibility would be to implement it like:
test-i915-mock-fences
test-i915-mock-hugepages
...
which would allow a finer control. Another possibility would be to
change kunit_suite and kunit_test_suites() to optionally create
a modprobe parameter to allow specifying what tests from the test
suites would run.
On the other hand, not sure if are there any gains implementing it,
at least for the hardware-independent tests. I mean, if one of such
tests fail after a patch, the change is broken and should be reverted,
as this is a regression.
> Orthogonal to that question, drm_mm and test-drm_modeset are _now_
> using kunit but in LTS kernels they're not, and we'd like to be able
> to keep testing those. That means having both launchers here and just
> letting the "incorrect" one produce a 'skip'.
Agreed. Patch 4/4 should be checking if the test module is there.
If not, fall back to selftest.
Regards,
Mauro
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Mon, 19 Sep 2022 17:25:38 -0700 Daniel Latypov wrote: > On Mon, Sep 19, 2022 at 1:43 PM Isabella Basso wrote: > > >> +* "(K)TAP version XX" should be the first line on all > > >> (sub)tests as per > > >> +* > > >> https://www.kernel.org/doc/html/latest/dev-tools/ktap.html#version-lines > > >> +* but actually isn't, as it currently depends on whoever writes > > >> the > > >> +* test to print this info > > > > > > FYI: we're really trying to fix cases of "missing version lines", > > > largely by making the kunit_test_suites() macro work in more > > > circumstances. > > > > > > So while it may be worth still handling the case where this is > > > missing, I don't think there are any tests in the latest versions of > > > the kernel which should have this missing. > > > > I’m not sure if I totally get how these work. Every time I run a KUnit test > > I > > get something like this: https://pastebin.com/7Ff31PMC > > > > As you can see it has been loaded as a module, just like we intend to do it > > from IGT, and I see no version lines whatsoever. Am I doing something > > wrong? > > You're doing everything right. > > The problem is we only print the version line for the *built-in* tests. > It never gets printed for tests in loadable modules. IGT tests require loadable modules, as some tests check if bind/unbind and load/unload works. Also, some tests require modprobing drivers with different parameters. Unfortunately, kunit.py is currently broken on such cases: its parser simply ignores everything if the subtest doesn't have a TAP version just before it. See: $ ./tools/testing/kunit/kunit.py parse /var/log/dmesg [12:37:05] [12:37:05] [ERROR] Test: main: 0 tests run! [12:37:05] [12:37:05] Testing complete. Ran 0 tests: errors: 1 Here, I loaded the test module twice. I can force it to parse it by doing $ (dmesg|grep "TAP version"; dmesg|grep -A intel_i915_mock) >logs But then, it gets confused with two subtests with the same name: $ ./tools/testing/kunit/kunit.py parse logs [12:37:34] [12:37:34] == intel_i915_mock (18 subtests) === [12:37:34] [PASSED] sanitycheck [12:37:34] [PASSED] shmem [12:37:34] [PASSED] fence [12:37:34] [PASSED] scatterlist [12:37:34] [PASSED] syncmap [12:37:34] [PASSED] uncore [12:37:34] [PASSED] ring [12:37:34] [PASSED] engine [12:37:34] [PASSED] timelines [12:37:34] [PASSED] requests [12:37:34] [PASSED] objects [12:37:34] [PASSED] phys [12:37:34] [PASSED] dmabuf [12:37:34] [PASSED] vma [12:37:34] [PASSED] evict [12:37:34] [PASSED] gtt [12:37:34] [PASSED] hugepages [12:37:34] [PASSED] memory_region [12:37:34] = [PASSED] intel_i915_mock = [12:37:34] == intel_i915_mock (18 subtests) === [12:37:34] [PASSED] sanitycheck [12:37:34] [PASSED] shmem [12:37:34] [PASSED] fence [12:37:34] [PASSED] scatterlist [12:37:34] [PASSED] syncmap [12:37:34] [PASSED] uncore [12:37:34] [PASSED] ring [12:37:34] [PASSED] engine [12:37:34] [PASSED] timelines [12:37:34] [PASSED] requests [12:37:34] [PASSED] objects [12:37:34] [PASSED] phys [12:37:34] [PASSED] dmabuf [12:37:34] [PASSED] vma [12:37:34] [PASSED] evict [12:37:34] [PASSED] gtt [12:37:34] [PASSED] hugepages [12:37:34] [PASSED] memory_region [12:37:34] [ERROR] Test: intel_i915_mock: Expected test number 2 but found 1 [12:37:34] = [PASSED] intel_i915_mock = [12:37:34] [12:37:34] Testing complete. Ran 36 tests: passed: 36, errors: 1 > Some more details below, if interested. > Specifically, it happens in > https://elixir.bootlin.com/linux/latest/C/ident/kunit_print_tap_header > > What David is referring to is we had tests that weren't in modules, > but didn't use the normal built-in code path. Those were also missing > TAP version lines. > But KUnit needs to do better here in the case of modules. > > The goal was that you'd be able to parse the result of module based > tests by something like > $ cat /sys/kernel/debug/kunit/*/results | ./tools/testing/kunit/kunit.py parse > but this doesn't work because of the lack of a version line. At least here, debug/kunit doesn't exist: sudo ls -lctra /sys/kernel/debug/|grep kunit > > If we add it to each module's test results, then we'll need to update > the parse to allow multiple verison lines,
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
Hi Isabella, On Mon, 19 Sep 2022 17:43:19 -0300 Isabella Basso wrote: > > Do you want to _require_ KUnit be built as a module, rather than built-in > > here? > > I’ll change the comment and the warning in v3 to clarify this. When do you intend to submit v3? Regards, Mauro
Re: [igt-dev] [PATCH i-g-t v2 3/4] lib/igt_kmod: add compatibility for KUnit
On Thu, 1 Sep 2022 14:37:06 +0800
David Gow wrote:
> On Mon, Aug 29, 2022 at 8:10 AM Isabella Basso wrote:
> >
> > This adds functions for both executing the tests as well as parsing (K)TAP
> > kmsg output, as per the KTAP spec [1].
> >
> > [1] https://www.kernel.org/doc/html/latest/dev-tools/ktap.html
> >
> > Signed-off-by: Isabella Basso
> > ---
>
> Thanks very much for sending these patches out again.
>
> Alas, I don't have a particularly useful igt setup to test this
> properly, but I've left a couple of notes from trying it on my laptop
> here.
>
>
> > lib/igt_kmod.c | 290 +
> > lib/igt_kmod.h | 2 +
> > 2 files changed, 292 insertions(+)
> >
> > diff --git a/lib/igt_kmod.c b/lib/igt_kmod.c
> > index 97cac7f5..93cdfcc5 100644
> > --- a/lib/igt_kmod.c
> > +++ b/lib/igt_kmod.c
> > @@ -25,6 +25,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "igt_aux.h"
> > #include "igt_core.h"
> > @@ -32,6 +33,8 @@
> > #include "igt_sysfs.h"
> > #include "igt_taints.h"
> >
> > +#define BUF_LEN 4096
> > +
> > /**
> > * SECTION:igt_kmod
> > * @short_description: Wrappers around libkmod for module loading/unloading
> > @@ -713,6 +716,293 @@ void igt_kselftest_get_tests(struct kmod_module *kmod,
> > kmod_module_info_free_list(pre);
> > }
> >
> > +/**
> > + * lookup_value:
> > + * @haystack: the string to search in
> > + * @needle: the string to search for
> > + *
> > + * Returns: the value of the needle in the haystack, or -1 if not found.
> > + */
> > +static long lookup_value(const char *haystack, const char *needle)
> > +{
> > + const char *needle_rptr;
> > + char *needle_end;
> > + long num;
> > +
> > + needle_rptr = strcasestr(haystack, needle);
> > +
> > + if (needle_rptr == NULL)
> > + return -1;
> > +
> > + /* skip search string and whitespaces after it */
> > + needle_rptr += strlen(needle);
> > +
> > + num = strtol(needle_rptr, _end, 10);
> > +
> > + if (needle_rptr == needle_end)
> > + return -1;
> > +
> > + if (num == LONG_MIN || num == LONG_MAX)
> > + return 0;
> > +
> > + return num > 0 ? num : 0;
> > +}
> > +
> > +static int find_next_tap_subtest(char *record, char *test_name,
> > +bool is_subtest)
> > +{
> > + const char *name_lookup_str,
> > + *lend, *version_rptr, *name_rptr;
> > + long test_count;
> > +
> > + name_lookup_str = "test: ";
> > +
> > + version_rptr = strcasestr(record, "TAP version ");
> > + name_rptr = strcasestr(record, name_lookup_str);
> > +
> > + /*
> > +* total test count will almost always appear as 0..N at the
> > beginning
> > +* of a run, so we use it as indication of a run
> > +*/
> > + test_count = lookup_value(record, "..");
> > +
> > + /* no count found, so this is probably not starting a (sub)test */
> > + if (test_count < 0) {
> > + if (name_rptr != NULL) {
> > + if (test_name[0] == '\0')
> > + strncpy(test_name,
> > + name_rptr + strlen(name_lookup_str),
> > + BUF_LEN);
> > + else if (strcmp(test_name, name_rptr +
> > strlen(name_lookup_str)) == 0)
> > + return 0;
> > + else
> > + test_name[0] = '\0';
> > +
> > + }
> > + return -1;
> > + }
> > +
> > + /*
> > +* "(K)TAP version XX" should be the first line on all (sub)tests
> > as per
> > +*
> > https://www.kernel.org/doc/html/latest/dev-tools/ktap.html#version-lines
> > +* but actually isn't, as it currently depends on whoever writes the
> > +* test to print this info
>
> FYI: we're really trying to fix cases of "missing version lines",
> largely by making the kunit_test_suites() macro work in more
> circumstances.
>
> So while it may be worth still handling the case where this is
> missing, I don't think there are any tests in the latest versions of
> the kernel which should have this missing.
That doesn't seem to be the case, at least when the tests are loaded
as module.
I'm working on adding more KUnit tests. At least here, TAP version
doesn't appear before the tests (I'm using drm-tip + my KUnit tests):
$ dmesg|grep TAP
[7.597592] TAP version 14
$ sudo lcov -z && sudo modprobe test-i915-mock && sudo
IGT_KERNEL_TREE=~/linux ~/igt/scripts/code_cov_capture mock_selftest && sudo
rmmod test-i915-mock
Auto-detecting gcov kernel support.
Found upstream gcov kernel support at /sys/kernel/debug/gcov
Resetting kernel execution counters
Done.
[3734.23] Code coverage wrote to mock_selftest.info
Re: [Intel-gfx] [PATCH v3 27/37] docs: gpu: i915.rst: gt: add more kernel-doc markups
Em Fri, 9 Sep 2022 05:06:46 -0400 Rodrigo Vivi escreveu: > On Fri, Sep 09, 2022 at 09:34:34AM +0200, Mauro Carvalho Chehab wrote: > > There are several documented GT kAPI that aren't currently part > > of the docs. Add them, as this allows identifying issues with > > badly-formatted tags. > > > > In i915's commits we usually add a version history here > to indicate what changed from the previous submission, > something like > > v2: re-organizing the blocks to group gtt stuff. Placing patch versioning at the email's detailed explanation is actually a violation of the Kernel coding style. See: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format "The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch." Such versions should either go at the cover letter - which is the usual convention on big series, or after "---", as explained at the same document: "The --- marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. ... Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. A good example of such comments might be patch changelogs which describe what has changed between the v1 and v2 version of the patch." > > that helps reviewers to know if their change requested was > addressed or not. True. Next time, I'll add a version at the cover letter. > > but anyways: > > Reviewed-by: Rodrigo Vivi Thank you! Mauro
Re: [Intel-gfx] [PATCH v3 01/37] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files
Em Fri, 16 Sep 2022 17:03:27 +0300 Gwan-gyeong Mun escreveu: > > /** > > - * Called when user space has done writes to this buffer > > + * i915_gem_sw_finish_ioctl - Called when user space has done writes to > > + * this buffer > As per this link[1], the brief description does not have a limitation to > match the indentation when explained over multiple lines, unlike > function parameters. > > [1] > https://docs.kernel.org/doc-guide/kernel-doc.html#function-documentation > > Therefore if you look at the function brief description over several > lines in i915 and drm, > > One of the drm apis, drm_gem_lock_reservations(), is used without > indentation in the form below, > /** > * drm_gem_lock_reservations - Sets up the ww context and acquires > * the lock on an array of GEM objects. > > In i915_perf.c, indentation is set as follows. > > /** > * gen8_append_oa_reports - Copies all buffered OA reports into > * userspace read() buffer. > > ... > > /** > * gen7_append_oa_reports - Copies all buffered OA reports into > * userspace read() buffer. > > If there is no problem when using the same form as > gen8_append_oa_reports when generating kernel-doc, it seems to be > indented to match the existing i915 style. However, if there is a > problem, I think you need to remove the indented part of the i915 code > like the drm apis. > > except i915_gem_sw_finish_ioctl i915_gem_gtt_pwrite_fast parts, the > rest of the parts look good to me. There's no rule about either indent or not. IMO, it makes easier for humans to read when indent is used. Yet, I'd say that, right now, 50% of multi-line comments within the kernel has indent. So, it is more like a matter of personal developer's preference at the moment. > > Reviewed-by: Gwan-gyeong Mun Thanks, Mauro
Re: [Intel-gfx] [PATCH v3 19/37] drm/i915: stop using kernel-doc markups for something else
Em Mon, 12 Sep 2022 10:19:04 -0700
Matt Roper escreveu:
> > Those *appear* to be kernel-doc markups, but they aren't, because
> > the structs themselves are not properly marked. See, for instance
> > struct intel_context.
> >
> > scripts/kerneldoc will *only* consider what's there as a proper
> > comment if you add:
> >
> > /**
> > * struct intel_context - describes an i915 context
> > *
> > */
> > struct intel_context {
> > union {
> > /** @ref: a kernel object reference */
> > struct kref ref; /* no kref_get_unless_zero()! */
> > /** @rcu: a rcu header */
> > struct rcu_head rcu;
> > };
> > ...
> > }
> >
> > Describing all fields inside the struct. Just placing
> > /** something */
> > on some random places in the middle doesn't make it a kernel-doc.
>
> Right, what we have today is incomplete/incorrect. But I think we
> should be fixing that by adding the missing documentation on the
> structure, rather than giving up and removing the kerneldoc. The end
> goal should be to have proper generated documentation, not just silence
> the warnings while leaving the actual output incomplete.
The end goal is to have *real* kernel-doc markups, not fake ones.
We're aiming towards there, where the first step is to get rid of the
ones that just pretend to be kernel-doc without really being validated
in order to check if they produce a valid content.
See, what we have so far are just comments. Some examples from this
patch:
/** Powers down the TV out block, and DAC0-3 */
#define CH7017_TV_POWER_DOWN_EN(1 << 5)
Currently, kernel-doc doesn't have any markup for not-function defines.
What we do to document this at kernel-doc is to either:
1. convert to an enum;
2. embed it inside some struct (or function) definition.
Other examples: this is not a Kernel-doc markup:
/** @file
* driver for the Chrontel 7xxx DVI chip over DVO.
*/
Neither this:
/**
* active: Active tracker for the rq activity (inc. external) on this
* intel_context object.
*/
In summary, what happens is that those "/**" tags removed on this patch are
just pretending to be Kernel-doc, but they aren't anything. See, when a newbie
starts programming in C code, without having a compiler, lots of syntax
issues will happen. When they try to compile their code, hundreds or errors
and warnings happen. That's basically what it is happening here.
See, the very basic syntax thing is missing: just like a C file requires
that all codes to be inside functions, a kernel-doc field description
requires a kernel-doc markup for the struct/function/enum/union that
contains it.
-
Now, I fully agree that the end goal is to have proper kernel-doc markups.
Adding those require a lot of archaeological work, looking at the git
commits which introduced the changes. Patch 34/37, for instance, does
that for struct drm_i915_gem_object:
https://lists.freedesktop.org/archives/intel-gfx/2022-September/305736.html
See, besides adding a real Kernel-doc markup for the struct:
+/**
+ * struct drm_i915_gem_object - describes an i915 GEM object
+ */
struct drm_i915_gem_object {
It had to fix several sintax and semantic mistakes:
Typos:
/**
-* @shared_resv_from: The object shares the resv from this vm.
+* @shares_resv_from: The object shares the resv from this vm.
*/
Invalid kernel-doc markups:
/**
-* @mem_flags - Mutable placement-related flags
+* @mem_flags: Mutable placement-related flags
Kernel markups that miss that they're on an embedded struct inside
the main one (thus those are also invalid kernel-doc markups):
/**
-* @shrink_pin: Prevents the pages from being made visible to
+* @mm.shrink_pin: Prevents the pages from being made visible to
Etc.
Thanks,
Mauro
Re: [PATCH v6 0/4] Let userspace know when snd-hda-intel needs i915
Hi Luis, On Mon, 9 May 2022 13:38:28 -0700 Luis Chamberlain wrote: > On Mon, May 09, 2022 at 06:23:35PM +0200, Mauro Carvalho Chehab wrote: > > Currently, kernel/module annotates module dependencies when > > request_symbol is used, but it doesn't cover more complex inter-driver > > dependencies that are subsystem and/or driver-specific. > > > > At this pount v5.18-rc7 is out and so it is too late to soak this > in for the proper level of testing I'd like to see for modules-next. > So I can review this after the next merge window. I'd want to beat > the hell out of this and if possible I'd like to see if we can have > some test coverage for the intended goal and how to break it. Any news with regards to this patch series? Regards, Mauro
Re: [PATCH v3 19/37] drm/i915: stop using kernel-doc markups for something else
Hi Matt,
Em Mon, 12 Sep 2022 08:09:57 -0700
Matt Roper escreveu:
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
>
> Several of the comments in this file do appear to be kerneldoc (in fact
> kerneldoc that was specifically requested during code review at
> https://patchwork.freedesktop.org/patch/448456/#comment_804252) and this
> file is included from Documentation/gpu/i915.rst, so I think some of
> these changes might be moving in the wrong direction. Should we instead
> focus on fixing up the comments that aren't quite formatted properly?
Those *appear* to be kernel-doc markups, but they aren't, because
the structs themselves are not properly marked. See, for instance
struct intel_context.
scripts/kerneldoc will *only* consider what's there as a proper
comment if you add:
/**
* struct intel_context - describes an i915 context
*
*/
struct intel_context {
union {
/** @ref: a kernel object reference */
struct kref ref; /* no kref_get_unless_zero()! */
/** @rcu: a rcu header */
struct rcu_head rcu;
};
...
}
Describing all fields inside the struct. Just placing
/** something */
on some random places in the middle doesn't make it a kernel-doc.
If you actually run kernel-doc in Werror mode:
./scripts/kernel-doc -Werror -sphinx-version 2.4.4
drivers/gpu/drm/i915/gt/intel_context_types.h | echo "ERROR!"
ERROR!
drivers/gpu/drm/i915/gt/intel_context_types.h:1: warning: no structured
comments found
1 warnings as Errors
you'll see that this is currently broken.
Thanks,
Mauro
[PATCH v3 32/37] docs: gpu: i915.rst: add the remaining kernel-doc markup files
There are other files with kernel-doc markups: $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) >kernel-doc-files $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i Documentation/)" == "" ]; then echo "$i"; fi; done >aaa Add them to i915.rst as well. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 85 +- 1 file changed, 83 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 545fe630557a..7f5cd01ed398 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -13,6 +13,11 @@ Core Driver Infrastructure This section covers core driver infrastructure used by both the display and the GEM parts of the driver. +Core driver +--- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c + Runtime Power Management @@ -29,6 +34,8 @@ Runtime Power Management .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h + Interrupt Handling -- @@ -44,8 +51,25 @@ Interrupt Handling .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c :functions: intel_runtime_pm_enable_interrupts -Intel GVT-g Guest Support(vGPU) +Memory Handling +--- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c + +Intel GVT-g Guest Support (vGPU) + .. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c :doc: Intel GVT-g guest support @@ -109,6 +133,55 @@ Workarounds .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c :doc: Hardware workarounds +Scatterlist handling + + +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c + +i915 request + + +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c + +Others +-- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c + +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h + + +Protected Xe Path (PXP) +--- + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_irq.c + +.. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_tee.c + Display Hardware Handling = @@ -615,6 +688,12 @@ Protected Objects Table Manager (TTM) --- +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.h + +.. kernel-doc:: drivers/gpu/drm/i915/i915_ttm_buddy_manager.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_region_ttm.c + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h @@ -624,6 +703,8 @@ Table Manager (TTM) Graphics Execution Manager (GEM) +.. kernel-doc:: drivers/gpu/drm/i915/i915_gem.c + .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c -- 2.37.3
[PATCH v3 10/37] drm/i915: i915_gpu_error.c: document dump_flags
Kernel-doc dump_flags parameter is missing at i915_capture_error_state().
Document it.
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 9ea2fe34e7d3..c2350284f221 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -2148,7 +2148,8 @@ void i915_error_state_store(struct i915_gpu_coredump
*error)
* i915_capture_error_state - capture an error record for later analysis
* @gt: intel_gt which originated the hang
* @engine_mask: hung engines
- *
+ * @dump_flags: bitmap flags. When %CORE_DUMP_FLAG_IS_GUC_CAPTURE is used,
+ * dump engine record registers and execlists.
*
* Should be called when an error is detected (either a hang or an error
* interrupt) to capture error state from the time of the error. Fills
--
2.37.3
[PATCH v3 05/37] drm/i915: gem: fix some Kernel-doc issues
There are several trivial issueson kernel-doc markups at gem:
drivers/gpu/drm/i915/gem/i915_gem_create.c:146: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:217: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:401: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:116: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:177: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:262: warning: expecting
prototype for Changes the cache(). Prototype was for
i915_gem_object_set_cache_level() instead
drivers/gpu/drm/i915/gem/i915_gem_domain.c:456: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_domain.c:500: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_object.h:110: warning: Function
parameter or member 'file' not described in 'i915_gem_object_lookup_rcu'
drivers/gpu/drm/i915/gem/i915_gem_object.h:110: warning: Excess
function parameter 'filp' description in 'i915_gem_object_lookup_rcu'
drivers/gpu/drm/i915/gem/i915_gem_region.h:35: warning: Function
parameter or member 'process_obj' not described in
'i915_gem_apply_to_region_ops'
drivers/gpu/drm/i915/gem/i915_gem_wait.c:130: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Caused by:
- lack of function name at the kernel-doc markup;
- renamed parameters.
Address them.
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 +---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 17 +++--
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 2 +-
4 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..8cb2eb092031 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -143,7 +143,8 @@ __i915_gem_object_create_user_ext(struct drm_i915_private
*i915, u64 size,
}
/**
- * Creates a new object using the same path as DRM_I915_GEM_CREATE_EXT
+ * __i915_gem_object_create_user - Creates a new object using the same path
+ * as DRM_I915_GEM_CREATE_EXT
* @i915: i915 private
* @size: size of the buffer, in bytes
* @placements: possible placement regions, in priority order
@@ -214,7 +215,7 @@ i915_gem_dumb_create(struct drm_file *file,
}
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ioctl - Creates a new mm object and returns a handle to it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
@@ -398,7 +399,8 @@ static const i915_user_extension_fn create_extensions[] = {
};
/**
- * Creates a new mm object and returns a handle to it.
+ * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle
+ * to it.
* @dev: drm device pointer
* @data: ioctl data blob
* @file: drm file pointer
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index d44a152ce680..fd4f10765208 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -113,7 +113,8 @@ void i915_gem_object_flush_if_display_locked(struct
drm_i915_gem_object *obj)
}
/**
- * Moves a single object to the WC read, and possibly write domain.
+ * i915_gem_object_set_to_wc_domain - Moves a single object to the WC read,
+ * and possibly write domain.
* @obj: object to act on
* @write: ask for write access or read only
*
@@ -174,7 +175,8 @@ i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object
*obj, bool write)
}
/**
- * Moves a single object to the GTT read, and possibly write domain.
+ * i915_gem_object_set_to_gtt_domain - Moves a single object to the GTT read,
+ * and possibly write domain.
* @obj: object to act on
* @write: ask for write access or read only
[PATCH v3 36/37] drm/i915: add GuC functions to the documentation
Currently, functions inside GuC aren't presented as part of the GuC documentation. Add them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 59c532fe0332..b71e9720a1ac 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -759,6 +759,9 @@ GuC .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.c + :internal: + .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c -- 2.37.3
[PATCH v3 25/37] drm/i915: i915_deps: use a shorter title markup
The DOC: tag waits for a one-line short title for the doc section. Using multiple lines will produce a weird output. So, add a shorter description for the title, while keeping the current content below it. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_deps.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_deps.c b/drivers/gpu/drm/i915/i915_deps.c index 297b8e4e42ee..df6af832e3f2 100644 --- a/drivers/gpu/drm/i915/i915_deps.c +++ b/drivers/gpu/drm/i915/i915_deps.c @@ -11,7 +11,9 @@ #include "i915_deps.h" /** - * DOC: Set of utilities to dynamically collect dependencies into a + * DOC: Utilities to collect dependencies for GT migration code + * + * Set of utilities to dynamically collect dependencies into a * structure which is fed into the GT migration code. * * Once we can do async unbinding, this is also needed to coalesce -- 2.37.3
[PATCH v3 02/37] drm/i915: display: fix kernel-doc markup warnings
There are a couple of issues at i915 display kernel-doc markups: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Function parameter or member 'intel_connector' not described in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: Excess function parameter 'connector' description in 'intel_connector_debugfs_add' drivers/gpu/drm/i915/display/intel_display_power.c:700: warning: expecting prototype for intel_display_power_put_async(). Prototype was for __intel_display_power_put_async() instead drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Function parameter or member 'work' not described in 'intel_tc_port_disconnect_phy_work' drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Excess function parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work' Those are due to wrong parameter of function name. Address them. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_display_power.c | 2 +- drivers/gpu/drm/i915/display/intel_tc.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 5dc364e9db49..e8433aa50905 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -2232,7 +2232,7 @@ DEFINE_SHOW_ATTRIBUTE(i915_current_bpc); /** * intel_connector_debugfs_add - add i915 specific connector debugfs files - * @connector: pointer to a registered drm_connector + * @intel_connector: pointer to a registered drm_connector * * Cleanup will be done by drm_connector_unregister() through a call to * drm_debugfs_connector_remove(). diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 1af1705d730d..b080d65d4461 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -686,7 +686,7 @@ intel_display_power_put_async_work(struct work_struct *work) } /** - * intel_display_power_put_async - release a power domain reference asynchronously + * __intel_display_power_put_async - release a power domain reference asynchronously * @i915: i915 device instance * @domain: power domain to reference * @wakeref: wakeref acquired for the reference that is being released diff --git a/drivers/gpu/drm/i915/display/intel_tc.c b/drivers/gpu/drm/i915/display/intel_tc.c index e5af955b5600..10cda362537e 100644 --- a/drivers/gpu/drm/i915/display/intel_tc.c +++ b/drivers/gpu/drm/i915/display/intel_tc.c @@ -797,7 +797,7 @@ void intel_tc_port_lock(struct intel_digital_port *dig_port) /** * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port - * @dig_port: digital port + * @work: workqueue struct * * Disconnect the given digital port from its TypeC PHY (handing back the * control of the PHY to the TypeC subsystem). This will happen in a delayed -- 2.37.3
[PATCH v3 35/37] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
The intel_gt_pm.h file contains some convenient macros to be used
in GT code in order to get/put runtime PM references and for
checking them.
Add descriptions based on the ones at intel_wakeref.h and
intel_runtime_pm.c.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
Documentation/gpu/i915.rst| 2 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 51 +++
2 files changed, 53 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 7f5cd01ed398..59c532fe0332 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -446,6 +446,8 @@ Graphics Translation Tables
Other GT functionality
--
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
+
.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h
.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..7847e15d102e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -11,21 +11,57 @@
#include "intel_gt_types.h"
#include "intel_wakeref.h"
+/**
+ * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
+ *
+ * @gt: pointer to the graphics engine
+ *
+ * Returns: true if a runtime pm reference is currently held and the GT is
+ * awake.
+ */
static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
{
return intel_wakeref_is_active(>wakeref);
}
+/**
+ * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is powered up
+ * @gt: pointer to the graphics engine
+ *
+ * Any runtime pm reference obtained by this function must have a symmetric
+ * call to intel_gt_pm_put() to release the reference again.
+ *
+ * Note that this is allowed to fail, in which case the runtime-pm wakeref
+ * will be released and the acquisition unwound.
+ */
static inline void intel_gt_pm_get(struct intel_gt *gt)
{
intel_wakeref_get(>wakeref);
}
+/**
+ * __intel_gt_pm_get: Acquire the runtime PM reference again
+ * @gt: pointer to the graphics engine which contains the wakeref
+ *
+ * Increment the PM reference counter, only valid if it is already held by
+ * the caller.
+ *
+ * See intel_gt_pm_get().
+ */
static inline void __intel_gt_pm_get(struct intel_gt *gt)
{
__intel_wakeref_get(>wakeref);
}
+/**
+ * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
+ * @gt: pointer to the graphics engine which contains the PM reference
+ *
+ * Acquire a hold on the PM reference, but only if the GT is already
+ * active.
+ *
+ * Returns: true if the wakeref was acquired, false otherwise.
+ */
static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
{
return intel_wakeref_get_if_active(>wakeref);
@@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt *gt)
intel_wakeref_might_get(>wakeref);
}
+/**
+ * intel_gt_pm_put: Release the runtime PM reference
+ * @gt: pointer to the graphics engine which contains the PM reference
+ *
+ * Release our hold on the runtime PM for GT.
+ *
+ * It might power down the GT right away if this is the last reference.
+ */
static inline void intel_gt_pm_put(struct intel_gt *gt)
{
intel_wakeref_put(>wakeref);
@@ -51,6 +95,13 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
intel_wakeref_might_put(>wakeref);
}
+/**
+ * with_intel_gt_pm - get a GT reference ensuring that GT is powered up,
+ * run some code and then put the reference away.
+ *
+ * @gt: pointer to the gt
+ * @tmp: pointer to a temporary wakeref.
+ */
#define with_intel_gt_pm(gt, tmp) \
for (tmp = 1, intel_gt_pm_get(gt); tmp; \
intel_gt_pm_put(gt), tmp = 0)
--
2.37.3
[PATCH v3 20/37] drm/i915: dvo_ch7xxx.c: use SPDX header
This file is licensed with MIT license. Change its license text to use SPDX. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 33 +-- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c index 1c1fe1f29675..b4d94a565fdb 100644 --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c +++ b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c @@ -1,30 +1,9 @@ -/** - -Copyright © 2006 Dave Airlie - -All Rights Reserved. - -Permission is hereby granted, free of charge, to any person obtaining a -copy of this software and associated documentation files (the -"Software"), to deal in the Software without restriction, including -without limitation the rights to use, copy, modify, merge, publish, -distribute, sub license, and/or sell copies of the Software, and to -permit persons to whom the Software is furnished to do so, subject to -the following conditions: - -The above copyright notice and this permission notice (including the -next paragraph) shall be included in all copies or substantial portions -of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. -IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR -ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, -TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE -SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - -**/ +// SPDX-License-Identifier: MIT +/* + * Copyright © 2006 Dave Airlie + * + * All Rights Reserved. + */ #include "intel_display_types.h" #include "intel_dvo_dev.h" -- 2.37.3
[PATCH v3 16/37] drm/i915: i915_gem_region.h: fix i915_gem_apply_to_region_ops doc
The kernel-doc markup for i915_gem_apply_to_region_ops() has some
issues:
1. The field should be marked as @process_obj;
2. The callback parameters aren't document properly, as sphinx
will consider them to be placed at the wrong place.
Fix (1) and change the way the parameters are described, using
a list, in order for it to be properly parsed during documentation
build time.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_region.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.h
b/drivers/gpu/drm/i915/gem/i915_gem_region.h
index 2dfcc41c0170..b0134bf4b1b7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.h
@@ -22,9 +22,11 @@ struct i915_gem_apply_to_region;
*/
struct i915_gem_apply_to_region_ops {
/**
-* process_obj - Process the current object
-* @apply: Embed this for private data.
-* @obj: The current object.
+* @process_obj: Callback function to process the current object
+* it requires two arguments:
+*
+* - @apply: Embed this for private data.
+* - @obj: The current object.
*
* Note that if this function is part of a ww transaction, and
* if returns -EDEADLK for one of the objects, it may be
--
2.37.3
[PATCH v3 37/37] drm/i915: be consistent with kernel-doc function declaration
Currently, 91% of kernel-doc function declarations don't have
parenthesis on it. Let's be consistent inside the driver by
removing the parenthesis from the other ones.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/intel_atomic.c| 2 +-
drivers/gpu/drm/i915/display/intel_audio.c | 4 ++--
drivers/gpu/drm/i915/display/intel_crtc.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
drivers/gpu/drm/i915/display/intel_dsb.c | 10 +-
drivers/gpu/drm/i915/display/intel_lpe_audio.c | 8
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 10 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c| 8
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c | 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +-
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
drivers/gpu/drm/i915/i915_reg_defs.h | 12 ++--
drivers/gpu/drm/i915/intel_wopcm.c | 4 ++--
18 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 18f0a5ae3bac..9b604a720ff0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -373,7 +373,7 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
}
/**
- * intel_atomic_setup_scalers() - setup scalers for crtc per staged requests
+ * intel_atomic_setup_scalers - setup scalers for crtc per staged requests
* @dev_priv: i915 device
* @intel_crtc: intel crtc
* @crtc_state: incoming crtc_state to validate and setup scalers
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index aacbc6da84ef..667fe9a8ff8e 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -1385,7 +1385,7 @@ static void i915_audio_component_cleanup(struct
drm_i915_private *dev_priv)
}
/**
- * intel_audio_init() - Initialize the audio driver either using
+ * intel_audio_init - Initialize the audio driver either using
* component framework or using lpe audio bridge
* @dev_priv: the i915 drm device private data
*
@@ -1397,7 +1397,7 @@ void intel_audio_init(struct drm_i915_private *dev_priv)
}
/**
- * intel_audio_deinit() - deinitialize the audio driver
+ * intel_audio_deinit - deinitialize the audio driver
* @dev_priv: the i915 drm device private data
*
*/
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 6792a9056f46..507d7aec7b1c 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -463,7 +463,7 @@ static int intel_mode_vblank_start(const struct
drm_display_mode *mode)
}
/**
- * intel_pipe_update_start() - start update of a set of display registers
+ * intel_pipe_update_start - start update of a set of display registers
* @new_crtc_state: the new crtc state
*
* Mark the start of an update to pipe registers that should be updated
@@ -617,7 +617,7 @@ static void dbg_vblank_evade(struct intel_crtc *crtc,
ktime_t end) {}
#endif
/**
- * intel_pipe_update_end() - end update of a set of display registers
+ * intel_pipe_update_end - end update of a set of display registers
* @new_crtc_state: the new crtc state
*
* Mark the end of an update started with intel_pipe_update_start(). This
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index e52ecc0738a6..2024884688f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -408,7 +408,7 @@ static void pipedmc_clock_gating_wa(struct drm_i915_private
*i915, bool enable)
}
/**
- * intel_dmc_load_program() - write the firmware from memory to register.
+ * intel_dmc_load_program - write the firmware from memory to register.
* @dev_priv: i915 drm device.
*
* DMC firmware is read from a .bin file and kept in internal memory one time.
@@ -876,7 +876,7 @@ static void dmc_load_work_fn(struct work_struct *work)
}
/**
- * intel_dmc_ucode_init() - initialize the firmware loading.
+ * intel_dmc_ucode_init - initialize the firmware loading.
* @dev_priv: i915 drm device.
*
* This function is called at the time of loading the display driver to read
@@ -973,7 +973,7 @@ void intel_dmc_ucode_init(struct drm_i915_private *dev_priv
[PATCH v3 28/37] docs: gpu: i915.rst: GuC: add more kernel-doc markups
There are several documented GuC kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 22 ++ 1 file changed, 22 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b668f36fb0a3..7f2daa1b4a8b 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -593,6 +593,28 @@ GuC .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_slpc_abi.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_log.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_huc_fw.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c + GuC Firmware Layout ~~~ -- 2.37.3
[PATCH v3 15/37] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
Preserving ascii artwork on kernel-docs is tricky, as it needs
to respect both the Sphinx rules and be properly parsed by
kernel-doc script.
The Sphinx syntax require code-blocks, which is:
::
followed by a blank line and indented lines.
But kernel-doc only works fine if the first and the last line
are indented with the same amount of spaces.
Also, a "\" at the end means that the next line should be merged
with the first one.
Change the ascii artwork to be on code-blocks, starting all
lines at the same characters and not ending with a backslash.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/intel_pm.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eb9c54bbf51f..1f5e520a6728 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -683,18 +683,20 @@ static const struct intel_watermark_params i845_wm_info =
{
* FIFO is relatively small compared to the amount of data
* fetched.
*
- * The FIFO level vs. time graph might look something like:
+ * The FIFO level vs. time graph might look something like::
*
- * |\ |\
- * | \ | \
- * __---__---__ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\ |\ ( )
+ * | | \ | \ ( )
+ * | __---__---__ (- plane active, _ blanking)
+ * +---> time
*
- * or perhaps like this:
+ * or perhaps like this::
*
- * |\|\ |\|\
- * ______ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\|\ |\|\ ( )
+ * | ______ (- plane active, _ blanking)
+ * +---> time
*
* Returns:
* The watermark in bytes
@@ -730,13 +732,14 @@ static unsigned int intel_wm_method1(unsigned int
pixel_rate,
* FIFO is relatively large compared to the amount of data
* fetched.
*
- * The FIFO level vs. time graph might look something like:
+ * The FIFO level vs. time graph might look something like::
*
- *|\___ |\___
- *|\___ |\___
- *|\ |\
- * __ --__--__--__--__--__--__ (- plane active, _ blanking)
- * -> time
+ * ^
+ * | |\___ |\___( )
+ * | |\___ |\___( )
+ * | |\ |\ ( )
+ * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
+ * +-> time
*
* Returns:
* The watermark in bytes
--
2.37.3
[PATCH v3 31/37] docs: gpu: i915.rst: GEM/TTM: add more kernel-doc markups
There are several documented GEM/TTM kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 38 ++ 1 file changed, 38 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 4ce04a457ccc..545fe630557a 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -612,6 +612,44 @@ Protected Objects .. kernel-doc:: drivers/gpu/drm/i915/pxp/intel_pxp_types.h +Table Manager (TTM) +--- + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c + +Graphics Execution Manager (GEM) + + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_create.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_domain.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_internal.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_lmem.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_mman.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_object_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_region.h + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_userptr.c + +.. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_wait.c + Microcontrollers -- 2.37.3
[PATCH v3 18/37] drm/i915: fix i915_gem_ttm_move.c DOC: markup
The doc markup should not end with ":", as it would generate a warning on Sphinx while generating the cross-reference tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 56217d324a9b..16dd4991d527 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -20,7 +20,7 @@ #include "gt/intel_migrate.h" /** - * DOC: Selftest failure modes for failsafe migration: + * DOC: Selftest failure modes for failsafe migration * * For fail_gpu_migration, the gpu blit scheduled is always a clear blit * rather than a copy blit, and then we force the failure paths as if -- 2.37.3
[PATCH v3 11/37] drm/i915: document kernel-doc trivial issues
Fix those kernel-doc warnings:
drivers/gpu/drm/i915/intel_region_ttm.c:199: warning: Function
parameter or member 'offset' not described in 'intel_region_ttm_resource_alloc'
drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function
parameter or member 'wakeref' not described in 'i915_vma_resource'
drivers/gpu/drm/i915/i915_vma.c:1703: warning: Function parameter or
member 'vma' not described in 'i915_vma_destroy_locked'
drivers/gpu/drm/i915/i915_vma.c:751: warning: Function parameter or
member 'ww' not described in 'i915_vma_insert'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:159: warning: Function
parameter or member 'gt' not described in 'intel_gt_fini_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:146: warning: Function
parameter or member 'gt' not described in 'intel_gt_init_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: expecting
prototype for intel_guc_hwconfig_init(). Prototype was for guc_hwconfig_init()
instead
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:113: warning: Function
parameter or member 'gt' not described in 'guc_hwconfig_init'
drivers/gpu/drm/i915/gt/intel_engine_types.h:276: warning: Function
parameter or member 'preempt_hang' not described in 'intel_engine_execlists'
That are due undocumented parameters.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gt/intel_engine_types.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 5 -
drivers/gpu/drm/i915/i915_vma.c | 2 ++
drivers/gpu/drm/i915/i915_vma_resource.h| 1 +
drivers/gpu/drm/i915/intel_region_ttm.c | 3 ++-
5 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 633a7e5dba3b..7c5ad9071fe7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -271,6 +271,7 @@ struct intel_engine_execlists {
*/
u8 csb_head;
+ /* private: Used only in selftests */
I915_SELFTEST_DECLARE(struct st_preempt_hang preempt_hang;)
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 4781fccc2687..76f7447302a6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -103,7 +103,8 @@ static bool has_table(struct drm_i915_private *i915)
}
/**
- * intel_guc_hwconfig_init - Initialize the HWConfig
+ * guc_hwconfig_init - Initialize the HWConfig
+ * @gt: GT structure
*
* Retrieve the HWConfig table from the GuC and save it locally.
* It can then be queried on demand by other users later on.
@@ -138,6 +139,7 @@ static int guc_hwconfig_init(struct intel_gt *gt)
/**
* intel_gt_init_hwconfig - Initialize the HWConfig if available
+ * @gt: GT structure
*
* Retrieve the HWConfig table if available on the current platform.
*/
@@ -151,6 +153,7 @@ int intel_gt_init_hwconfig(struct intel_gt *gt)
/**
* intel_gt_fini_hwconfig - Finalize the HWConfig
+ * @gt: GT structure
*
* Free up the memory allocation holding the table.
*/
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index f17c09ead7d7..946f26138381 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -731,6 +731,7 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
unsigned long color)
/**
* i915_vma_insert - finds a slot for the vma in its address space
* @vma: the vma
+ * @ww: An optional struct i915_gem_ww_ctx
* @size: requested size in bytes (can be larger than the VMA)
* @alignment: required alignment
* @flags: mask of PIN_* flags to use
@@ -1686,6 +1687,7 @@ static void release_references(struct i915_vma *vma,
struct intel_gt *gt,
/**
* i915_vma_destroy_locked - Remove all weak reference to the vma and put
* the initial reference.
+ * @vma: VMA to destroy
*
* This function should be called when it's decided the vma isn't needed
* anymore. The caller must assure that it doesn't race with another lookup
diff --git a/drivers/gpu/drm/i915/i915_vma_resource.h
b/drivers/gpu/drm/i915/i915_vma_resource.h
index e155f6f7af6f..02dd8bb89c0a 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.h
+++ b/drivers/gpu/drm/i915/i915_vma_resource.h
@@ -49,6 +49,7 @@ struct i915_page_sizes {
* @__subtree_last: Interval tree private member.
* @vm: non-refcounted pointer to the vm. This is for internal use only and
* this member is cleared after vm_resource unbind.
+ * @wakeref: wakeref used for runtime PM reference.
* @mr: The memory region of the object pointed to by the vma
[PATCH v3 09/37] drm/i915: gem: add kernel-doc description for some function parameters
There are some parameters missing at the kernel-doc markups on some gem files. Some of those are trivial enough to be added. Document them. Reviewed-by: Nirmoy Das Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 ++ 3 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c b/drivers/gpu/drm/i915/gem/i915_gem_object.c index 85482a04d158..35637e2f51f3 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -815,6 +815,8 @@ int i915_gem_object_wait_moving_fence(struct drm_i915_gem_object *obj, * in an unknown_state. This means that userspace must NEVER be allowed to touch * the pages, with either the GPU or CPU. * + * @obj: The object to check its state. + * * ONLY valid to be called after ensuring that all kernel fences have signalled * (in particular the fence for moving/clearing the object). */ diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h index e4842b4296fc..64151f40098f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.h +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.h @@ -30,6 +30,7 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo); /** * i915_ttm_to_gem - Convert a struct ttm_buffer_object to an embedding * struct drm_i915_gem_object. + * @bo: The ttm buffer object. * * Return: Pointer to the embedding struct ttm_buffer_object, or NULL * if the object was not an i915 ttm object. diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 9a7e50534b84..56217d324a9b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -237,6 +237,7 @@ static struct dma_fence *i915_ttm_accel_move(struct ttm_buffer_object *bo, * @_src_iter: Storage space for the source kmap iterator. * @dst_iter: Pointer to the destination kmap iterator. * @src_iter: Pointer to the source kmap iterator. + * @num_pages: Number of pages to copy or to be cleared. * @clear: Whether to clear instead of copy. * @src_rsgt: Refcounted scatter-gather list of source memory. * @dst_rsgt: Refcounted scatter-gather list of destination memory. @@ -541,6 +542,7 @@ __i915_ttm_move(struct ttm_buffer_object *bo, * i915_ttm_move - The TTM move callback used by i915. * @bo: The buffer object. * @evict: Whether this is an eviction. + * @ctx: Pointer to a struct ttm_operation_ctx * @dst_mem: The destination ttm resource. * @hop: If we need multihop, what temporary memory type to move to. * -- 2.37.3
[PATCH v3 19/37] drm/i915: stop using kernel-doc markups for something else
There are some occurrences of "/**" that aren't actually part of
a kernel-doc markup. Replace them by "/*", in order to make easier
to identify what i915 files contain kernel-doc markups.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/dvo_ch7017.c | 26 +++
drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 6 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dvo_dev.h | 6 +-
drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +-
drivers/gpu/drm/i915/display/intel_tv.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 69 +--
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 12 ++--
drivers/gpu/drm/i915/gt/intel_reset_types.h | 4 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 6 +-
.../drm/i915/gt/shaders/clear_kernel/hsw.asm | 4 +-
.../drm/i915/gt/shaders/clear_kernel/ivb.asm | 4 +-
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 10 +--
drivers/gpu/drm/i915/i915_drm_client.h| 2 +-
drivers/gpu/drm/i915/i915_drv.h | 24 +++
drivers/gpu/drm/i915/i915_file_private.h | 8 +--
drivers/gpu/drm/i915/i915_gpu_error.h | 4 +-
drivers/gpu/drm/i915/i915_pmu.h | 32 -
drivers/gpu/drm/i915/intel_uncore.h | 4 +-
20 files changed, 115 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
b/drivers/gpu/drm/i915/display/dvo_ch7017.c
index 0589994dde11..581e29ab77e4 100644
--- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
@@ -55,13 +55,13 @@
#define CH7017_TEST_PATTERN0x48
#define CH7017_POWER_MANAGEMENT0x49
-/** Enables the TV output path. */
+/* Enables the TV output path. */
#define CH7017_TV_EN (1 << 0)
#define CH7017_DAC0_POWER_DOWN (1 << 1)
#define CH7017_DAC1_POWER_DOWN (1 << 2)
#define CH7017_DAC2_POWER_DOWN (1 << 3)
#define CH7017_DAC3_POWER_DOWN (1 << 4)
-/** Powers down the TV out block, and DAC0-3 */
+/* Powers down the TV out block, and DAC0-3 */
#define CH7017_TV_POWER_DOWN_EN(1 << 5)
#define CH7017_VERSION_ID 0x4a
@@ -84,26 +84,26 @@
#define CH7017_UP_SCALER_HORIZONTAL_INC_1 0x5e
#define CH7017_HORIZONTAL_ACTIVE_PIXEL_INPUT 0x5f
-/**< Low bits of horizontal active pixel input */
+/* Low bits of horizontal active pixel input */
#define CH7017_ACTIVE_INPUT_LINE_OUTPUT0x60
-/** High bits of horizontal active pixel input */
+/* High bits of horizontal active pixel input */
#define CH7017_LVDS_HAP_INPUT_MASK (0x7 << 0)
-/** High bits of vertical active line output */
+/* High bits of vertical active line output */
#define CH7017_LVDS_VAL_HIGH_MASK (0x7 << 3)
#define CH7017_VERTICAL_ACTIVE_LINE_OUTPUT 0x61
-/**< Low bits of vertical active line output */
+/* Low bits of vertical active line output */
#define CH7017_HORIZONTAL_ACTIVE_PIXEL_OUTPUT 0x62
-/**< Low bits of horizontal active pixel output */
+/* Low bits of horizontal active pixel output */
#define CH7017_LVDS_POWER_DOWN 0x63
-/** High bits of horizontal active pixel output */
+/* High bits of horizontal active pixel output */
#define CH7017_LVDS_HAP_HIGH_MASK (0x7 << 0)
-/** Enables the LVDS power down state transition */
+/* Enables the LVDS power down state transition */
#define CH7017_LVDS_POWER_DOWN_EN (1 << 6)
-/** Enables the LVDS upscaler */
+/* Enables the LVDS upscaler */
#define CH7017_LVDS_UPSCALER_EN(1 << 7)
#define CH7017_LVDS_POWER_DOWN_DEFAULT_RESERVED 0x08
@@ -116,9 +116,9 @@
#define CH7017_LVDS_ENCODING_2 0x65
#define CH7017_LVDS_PLL_CONTROL0x66
-/** Enables the LVDS panel output path */
+/* Enables the LVDS panel output path */
#define CH7017_LVDS_PANEN (1 << 0)
-/** Enables the LVDS panel backlight */
+/* Enables the LVDS panel backlight */
#define CH7017_LVDS_BKLEN (1 << 3)
#define CH7017_POWER_SEQUENCING_T1 0x67
@@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
addr, u8 val)
return i2c_transfer(dvo->i2c_bus, , 1) == 1;
}
-/** Probes for a CH7017 on the given bus and slave address. */
+/* Probes for a CH7017 on the given bus and slave address. */
static bool ch7017_init(struct intel_dvo_device *dvo,
struct i2c_adapter *adapter)
{
diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
index 54f58ba44b9f..1c1fe
[PATCH v3 03/37] drm/i915: gt: fix some Kernel-doc issues
in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'size' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'sampled_write_ptr' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'wrap_offset' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'flush_to_file' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'buffer_full_cnt' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'reserved' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'flags' not described in 'guc_log_buffer_state'
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function
parameter or member 'version' not described in 'guc_log_buffer_state'
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gt/intel_context.h | 6 +++---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_gtt.h | 6 +++---
drivers/gpu/drm/i915/gt/intel_rps.c | 4 ++--
drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 14 +++---
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 +-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 8e2d70630c49..91c092d5deae 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -96,7 +96,7 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
/**
* intel_context_lock_pinned - Stablises the 'pinned' status of the HW context
- * @ce - the context
+ * @ce: the context
*
* Acquire a lock on the pinned status of the HW context, such that the context
* can neither be bound to the GPU or unbound whilst the lock is held, i.e.
@@ -110,7 +110,7 @@ static inline int intel_context_lock_pinned(struct
intel_context *ce)
/**
* intel_context_is_pinned - Reports the 'pinned' status
- * @ce - the context
+ * @ce: the context
*
* While in use by the GPU, the context, along with its ring and page
* tables is pinned into memory and the GTT.
@@ -132,7 +132,7 @@ static inline void intel_context_cancel_request(struct
intel_context *ce,
/**
* intel_context_unlock_pinned - Releases the earlier locking of 'pinned'
status
- * @ce - the context
+ * @ce: the context
*
* Releases the lock earlier acquired by intel_context_unlock_pinned().
*/
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..da9cd41c45f1 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1197,7 +1197,7 @@ create_kernel_context(struct intel_engine_cs *engine)
}
/**
- * intel_engines_init_common - initialize cengine state which might require hw
access
+ * engine_init_common - initialize cengine state which might require hw access
* @engine: Engine to initialize.
*
* Initializes @engine@ structure members shared between legacy and execlists
@@ -1278,7 +1278,7 @@ int intel_engines_init(struct intel_gt *gt)
}
/**
- * intel_engines_cleanup_common - cleans up the engine state created by
+ * intel_engine_cleanup_common - cleans up the engine state created by
*the common initiailizers.
* @engine: Engine to cleanup.
*
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e639434e97fd..fca8eedee1d8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -503,7 +503,7 @@ static inline void i915_vm_put(struct i915_address_space
*vm)
/**
* i915_vm_resv_put - Release a reference on the vm's reservation lock
- * @resv: Pointer to a reservation lock obtained from i915_vm_resv_get()
+ * @vm: The vm whose reservation lock was obtained from i915_vm_resv_get()
*/
static inline void i915_vm_resv_put(struct i915_address_space *vm)
{
@@ -604,8 +604,8 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt);
/**
* i915_ggtt_mark_pte_lost - Mark ggtt ptes as lost or clear such a marking
- * @i915 The device private.
- * @val whether the ptes should be marked as lost.
+ * @i915: The device private.
+ * @val: whether the ptes should be marked as lost.
*
* In some cases pte content is retained across
[PATCH v3 30/37] docs: gpu: i915.rst: PM: add more kernel-doc markups
Both intel_runtime_pm.h and intel_pm.c contains kAPI for runtime PM. So, add them to the documentation. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index da64ebdaa9e0..4ce04a457ccc 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -25,6 +25,10 @@ Runtime Power Management .. kernel-doc:: drivers/gpu/drm/i915/intel_uncore.c :internal: +.. kernel-doc:: drivers/gpu/drm/i915/intel_runtime_pm.h + +.. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c + Interrupt Handling -- -- 2.37.3
[PATCH v3 34/37] drm/i915: document struct drm_i915_gem_object
This is a large struct used to describe gem objects. It is
currently partially documented. Finish its documentation, filling
the gaps from git logs.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
.../gpu/drm/i915/gem/i915_gem_object_types.h | 200 ++
1 file changed, 158 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 35746cf268ea..577f02b16b23 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -233,6 +233,9 @@ struct i915_gem_object_page_iter {
struct mutex lock; /* protects this cache */
};
+/**
+ * struct drm_i915_gem_object - describes an i915 GEM object
+ */
struct drm_i915_gem_object {
/*
* We might have reason to revisit the below since it wastes
@@ -241,12 +244,16 @@ struct drm_i915_gem_object {
* when accessing it.
*/
union {
+ /** @base: GEM base object */
struct drm_gem_object base;
+ /** @__do_not_access: TTM buffer object */
struct ttm_buffer_object __do_not_access;
};
+ /** @ops: pointer to GEM object ops */
const struct drm_i915_gem_object_ops *ops;
+ /** @vma: struct containing VMA list, tree and lock */
struct {
/**
* @vma.lock: protect the list/tree of vmas
@@ -280,10 +287,12 @@ struct drm_i915_gem_object {
*
* If this object is closed, we need to remove all of its VMA from
* the fast lookup index in associated contexts; @lut_list provides
-* this translation from object to context->handles_vma.
+* this translation from object to ``context->handles_vma``.
*/
struct list_head lut_list;
- spinlock_t lut_lock; /* guards lut_list */
+
+ /** @lut_lock: guards @lut_list */
+ spinlock_t lut_lock;
/**
* @obj_link: Link into @i915_gem_ww_ctx.obj_list
@@ -294,42 +303,88 @@ struct drm_i915_gem_object {
*/
struct list_head obj_link;
/**
-* @shared_resv_from: The object shares the resv from this vm.
+* @shares_resv_from: The object shares the resv from this vm.
*/
struct i915_address_space *shares_resv_from;
union {
+ /** @rcu: head used when freeing objects with RCU */
struct rcu_head rcu;
+ /** @freed: list of GEM freed objects */
struct llist_node freed;
};
/**
-* Whether the object is currently in the GGTT mmap.
+* @userfault_count: a value bigger than zero means that the object
+* was mmapped into userspace.
+*
+* Used when the object is currently in the GGTT mmap.
*/
unsigned int userfault_count;
+ /**
+* @userfault_link: list of all objects that were
+* mmapped into userspace.
+*
+* Used when the object is currently in the GGTT mmap.
+*/
struct list_head userfault_link;
+ /** @mmo: struct containing mmo offsets and lock */
struct {
- spinlock_t lock; /* Protects access to mmo offsets */
+ /** @mmo.lock: protects access to @mmo.offsets */
+ spinlock_t lock;
+ /** @mmo.offsets: rbtree list of mmo offsets */
struct rb_root offsets;
} mmo;
+ /* private: used on selftest only */
I915_SELFTEST_DECLARE(struct list_head st_link);
+ /* public: */
+ /**
+* @flags: object flags. Current flags are:
+*
+* %I915_BO_ALLOC_CONTIGUOUS:
+* Object requires to be allocated as a contiguous block
+* %I915_BO_ALLOC_VOLATILE:
+* Volatile objects are marked as %DONTNEED while pinned, therefore
+* once unpinned the backing store can be discarded.
+* This is limited to kernel internal objects.
+* %I915_BO_ALLOC_CPU_CLEAR:
+* Some internal device local-memory objects may have an option
+* to CPU clear the pages upon gathering the backing store.
+* Note that this might be before the blitter is usable, which
+* is the case for some internal GuC objects.
+* %I915_BO_ALLOC_USER:
+* Make sure the object is cleared before any user access.
+* %I915_BO_ALLOC_PM_VOLATILE:
+* Object is allowed to lose its contents on suspend / resume,
+* even if pinned
+* %I915_BO_ALLOC_PM_EARLY:
+* Object needs to be restored early using memcpy during
[PATCH v3 29/37] docs: gpu: i915.rst: GVT: add more kernel-doc markups
There are several documented GVT kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 41 ++ 1 file changed, 41 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 7f2daa1b4a8b..da64ebdaa9e0 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -58,6 +58,47 @@ Intel GVT-g Host Support(vGPU device model) .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c :internal: +Other Intel GVT-g interfaces + + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gvt.h + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/aperture_gm.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/cfg_space.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/debugfs.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/display.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/edid.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/fb_decoder.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/firmware.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/gtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/handlers.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/interrupt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/kvmgt.c + +.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt_mmio_table.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/mmio_context.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/opregion.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/page_track.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/scheduler.c + +.. kernel-doc:: drivers/gpu/drm/i915/gvt/vgpu.c + Workarounds --- -- 2.37.3
[PATCH v3 23/37] drm/i915: i915_gem.c fix a kernel-doc issue
Prevent this Sphinx warning: Documentation/foo/i915:728: ./drivers/gpu/drm/i915/i915_gem.c:447: WARNING: Inline emphasis start-string without end-string. By using @data to identify the data field, as expected by kernel-doc. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f68fa0732363..2b5b2be91a24 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -444,7 +444,7 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj, * @data: ioctl data blob * @file: drm file pointer * - * On error, the contents of *data are undefined. + * On error, the contents of @data is undefined. */ int i915_gem_pread_ioctl(struct drm_device *dev, void *data, -- 2.37.3
[PATCH v3 27/37] docs: gpu: i915.rst: gt: add more kernel-doc markups
There are several documented GT kAPI that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 40 +- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 2ad7941a79f2..b668f36fb0a3 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -149,7 +149,6 @@ Misc display functions .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c - Plane Configuration --- @@ -308,6 +307,45 @@ Multicast/Replicated (MCR) Registers .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c :internal: +GT engine +- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c + +Graphics Translation Tables +--- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h + +Other GT functionality +-- + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c + +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c + Memory Management and Command Submission -- 2.37.3
[PATCH v3 33/37] drm/i915 i915_gem_object_types.h: document struct i915_lut_handle
commit d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
added a rbtree list to allow searching for obj/ctx.
Document it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..35746cf268ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -21,9 +21,15 @@ struct drm_i915_gem_object;
struct intel_fronbuffer;
struct intel_memory_region;
-/*
- * struct i915_lut_handle tracks the fast lookups from handle to vma used
- * for execbuf. Although we use a radixtree for that mapping, in order to
+/**
+ * struct i915_lut_handle - tracks the fast lookups from handle to vma used
+ * for execbuf.
+ *
+ * @obj_link: link to the object associated with the @handle.
+ * @ctx: context associated with the @handle.
+ * @handle: a rbtree handle to lookup context for specific obj/vma.
+ *
+ * Although we use a radixtree for that mapping, in order to
* remove them as the object or context is closed, we need a secondary list
* and a translation entry (i915_lut_handle).
*/
--
2.37.3
[PATCH v3 22/37] drm/i915: i915_vma_resource.c: fix some kernel-doc markups
Building docs currently produces two warnings: Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:286: WARNING: Inline strong start-string without end-string. Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:370: WARNING: Inline strong start-string without end-string. That's because @foo evaluates into **foo**, and placing anything after it without spaces cause Sphinx to warn and do the wrong thing.. So, replace them by a different Sphinx-compatible tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_vma_resource.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c b/drivers/gpu/drm/i915/i915_vma_resource.c index de1342dbfa12..e758e0530175 100644 --- a/drivers/gpu/drm/i915/i915_vma_resource.c +++ b/drivers/gpu/drm/i915/i915_vma_resource.c @@ -290,7 +290,7 @@ i915_vma_resource_color_adjust_range(struct i915_address_space *vm, * * The function needs to be called with the vm lock held. * - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true`` */ int i915_vma_resource_bind_dep_sync(struct i915_address_space *vm, u64 offset, @@ -374,7 +374,7 @@ void i915_vma_resource_bind_dep_sync_all(struct i915_address_space *vm) * this means that during heavy memory pressure, we will sync in this * function. * - * Return: Zero on success, -ERESTARTSYS if interrupted and @intr==true + * Return: Zero on success, -ERESTARTSYS if interrupted and ``intr==true`` */ int i915_vma_resource_bind_dep_await(struct i915_address_space *vm, struct i915_sw_fence *sw_fence, -- 2.37.3
[PATCH v3 14/37] drm/i915: skl_scaler: fix return value kernel-doc markup
The way it is, it produces this warning: Documentation/gpu/i915:150: ./drivers/gpu/drm/i915/display/skl_scaler.c:213: WARNING: Block quote ends without a blank line; unexpected unindent. Use list markups to suppress the warning. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/skl_scaler.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c b/drivers/gpu/drm/i915/display/skl_scaler.c index 4092679be21e..59099f793d3e 100644 --- a/drivers/gpu/drm/i915/display/skl_scaler.c +++ b/drivers/gpu/drm/i915/display/skl_scaler.c @@ -208,9 +208,9 @@ int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state) * @crtc_state: crtc's scaler state * @plane_state: atomic plane state to update * - * Return - * 0 - scaler_usage updated successfully - *error - requested scaling cannot be supported or other error condition + * Return: + * * 0 - scaler_usage updated successfully + * * error - requested scaling cannot be supported or other error condition */ int skl_update_scaler_plane(struct intel_crtc_state *crtc_state, struct intel_plane_state *plane_state) -- 2.37.3
[PATCH v3 21/37] drm/i915: dvo_sil164.c: use SPDX header
This file is licensed with MIT license. Change its license text to use SPDX. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +-- 1 file changed, 6 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/i915/display/dvo_sil164.c b/drivers/gpu/drm/i915/display/dvo_sil164.c index 0dfa0a0209ff..12974f7c9dc1 100644 --- a/drivers/gpu/drm/i915/display/dvo_sil164.c +++ b/drivers/gpu/drm/i915/display/dvo_sil164.c @@ -1,30 +1,10 @@ -/** +// SPDX-License-Identifier: MIT -Copyright © 2006 Dave Airlie - -All Rights Reserved. - -Permission is hereby granted, free of charge, to any person obtaining a -copy of this software and associated documentation files (the -"Software"), to deal in the Software without restriction, including -without limitation the rights to use, copy, modify, merge, publish, -distribute, sub license, and/or sell copies of the Software, and to -permit persons to whom the Software is furnished to do so, subject to -the following conditions: - -The above copyright notice and this permission notice (including the -next paragraph) shall be included in all copies or substantial portions -of the Software. - -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. -IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR -ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, -TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE -SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - -**/ +/* + * Copyright © 2006 Dave Airlie + * + * All Rights Reserved. + */ #include "intel_display_types.h" #include "intel_dvo_dev.h" -- 2.37.3
[PATCH v3 07/37] drm/i915: i915_gem_ttm: fix a kernel-doc markup
Two new fields were added to __i915_gem_ttm_object_init() without
their corresponding documentation.
Document them.
Fixes: 9b78b5dade2d ("drm/i915: add i915_gem_object_create_region_at()")
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index f64a3deb12fc..f5fb06d74f13 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1148,7 +1148,9 @@ void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
* __i915_gem_ttm_object_init - Initialize a ttm-backed i915 gem object
* @mem: The initial memory region for the object.
* @obj: The gem object.
+ * @offset: The range start.
* @size: Object size in bytes.
+ * @page_size: The requested page size in bytes for this object.
* @flags: gem object flags.
*
* Return: 0 on success, negative error code on failure.
--
2.37.3
[PATCH v3 26/37] docs: gpu: i915.rst: display: add kernel-doc markups
There are several documented kAPI at the display side that aren't currently part of the docs. Add them, as this allows identifying issues with badly-formatted tags. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ Documentation/gpu/i915.rst | 50 ++ 1 file changed, 50 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 4e59db1cfb00..2ad7941a79f2 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -100,6 +100,56 @@ Display FIFO Underrun Reporting .. kernel-doc:: drivers/gpu/drm/i915/display/intel_fifo_underrun.c :internal: +Atomic Modeset Support +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic.c + +Display Power Domain + + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_map.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_power_well.c + +Misc display functions +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_backlight.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_crtc.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_connector.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display_debugfs.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dp_link_training.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpll.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpt.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_fb_pin.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_gmbus.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_lvds.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_opregion.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_snps_phy.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_tc.c + +.. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c + + Plane Configuration --- -- 2.37.3
[PATCH v3 00/37] drm/i915: fix kernel-doc issues
There are several kernel-doc markups along the i915 driver that aren't part of the i915.rst file, nor are included on any other file under Documentation. Maybe due to that, there are several kernel-doc markups that report problems when checked with scripts/kernel-doc. More than that, some of them also have problems when actually integrated at the building system, as reported by Sphinx. Along the issues we have: - renamed symbols where the prototype doesn't match the kernel-doc name; - some markups doesn't have the symbol name on it; - typos when defining parameter; - some parameters are missing; - some ascii artwork aren't properly displayed after parsed by Sphinx; - some other tags produce bad results and warnings after parsed by html build; - some "/**" patterns exist on places that aren't kernel-doc markups. This series, against drm-tip, fix all the above issues and all all such files to i915.rst. This way, it will be easier to avoid other problems to be introduced. While here, I also added SPDX on two display files. Besides being the current way to indicate the license, it also makes easier to find all files with kernel-doc markups, as all it is needed is to search for "/**" at i915 files to know what of them have embedded documentation. PS.: my end goal here is to ensure that the TLB patch series I'm about to send will be properly documented. For that to happen, let's first fix all warnings when building the documentation ;-) --- v3: - Dropped patches with issues already fixed; - Addressed Rodrigo's comments. v2: - Added 3 already-existing patches form other PRs addressing some of the issues. The subjects were renamed, in order to describe what they're doing. - Fixed checkpatch warnings; - Added 4 additional patches at the end, documenting some structs at i915_gem_object_types.h and intel_gt_pm.h, plus adding intel-guc.c internal functions to the generated documentation. Mauro Carvalho Chehab (37): drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files drm/i915: display: fix kernel-doc markup warnings drm/i915: gt: fix some Kernel-doc issues drm/i915: gvt: fix kernel-doc trivial warnings drm/i915: gem: fix some Kernel-doc issues drm/i915: intel_wakeref.h: fix some kernel-doc markups drm/i915: i915_gem_ttm: fix a kernel-doc markup drm/i915: i915_gem_ttm_pm.c: fix kernel-doc markups drm/i915: gem: add kernel-doc description for some function parameters drm/i915: i915_gpu_error.c: document dump_flags drm/i915: document kernel-doc trivial issues drm/i915: intel_dp_link_training.c: fix kernel-doc markup drm/i915: intel_fb: fix a kernel-doc issue with Sphinx drm/i915: skl_scaler: fix return value kernel-doc markup drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc drm/i915: i915_gem_region.h: fix i915_gem_apply_to_region_ops doc drm/i915: i915_gem_wait.c: fix a kernel-doc markup drm/i915: fix i915_gem_ttm_move.c DOC: markup drm/i915: stop using kernel-doc markups for something else drm/i915: dvo_ch7xxx.c: use SPDX header drm/i915: dvo_sil164.c: use SPDX header drm/i915: i915_vma_resource.c: fix some kernel-doc markups drm/i915: i915_gem.c fix a kernel-doc issue drm/i915: i915_scatterlist.h: fix some kernel-doc markups drm/i915: i915_deps: use a shorter title markup docs: gpu: i915.rst: display: add kernel-doc markups docs: gpu: i915.rst: gt: add more kernel-doc markups docs: gpu: i915.rst: GuC: add more kernel-doc markups docs: gpu: i915.rst: GVT: add more kernel-doc markups docs: gpu: i915.rst: PM: add more kernel-doc markups docs: gpu: i915.rst: GEM/TTM: add more kernel-doc markups docs: gpu: i915.rst: add the remaining kernel-doc markup files drm/i915 i915_gem_object_types.h: document struct i915_lut_handle drm/i915: document struct drm_i915_gem_object drm/i915: add descriptions for some RPM macros at intel_gt_pm.h drm/i915: add GuC functions to the documentation drm/i915: be consistent with kernel-doc function declaration Documentation/gpu/i915.rst| 283 +- drivers/gpu/drm/i915/display/dvo_ch7017.c | 26 +- drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 39 +-- drivers/gpu/drm/i915/display/dvo_sil164.c | 32 +- drivers/gpu/drm/i915/display/intel_atomic.c | 2 +- drivers/gpu/drm/i915/display/intel_audio.c| 4 +- drivers/gpu/drm/i915/display/intel_crtc.c | 4 +- .../drm/i915/display/intel_display_debugfs.c | 2 +- .../drm/i915/display/intel_display_power.c| 2 +- .../drm/i915/display/intel_display_types.h| 2 +- drivers/gpu/drm/i915/display/intel_dmc.c | 10 +- .../drm/i915/display/intel_dp_link_training.c | 2 + drivers/gpu/drm/i915/display/intel_dsb.c | 10 +- drivers/gpu/drm/i915/display/intel_dvo_dev.h | 6 +- drivers/gpu/drm/i915/display/intel_fb.c | 2 +- .../gpu/drm/i915/display/intel_lpe_audio.c| 8 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 4 +-
[PATCH v3 13/37] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx
We can't use %foo[] as this produces a bad markup. Use instead, the emphasis markup directly. Fix this issue: Documentation/gpu/i915:136: ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong start-string without end-string. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/display/intel_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c index eefa33c555ac..ba413e38033d 100644 --- a/drivers/gpu/drm/i915/display/intel_fb.c +++ b/drivers/gpu/drm/i915/display/intel_fb.c @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info formats[], * @cmd: FB add command structure * * Returns: - * Returns the format information for @cmd->pixel_format specific to @cmd->modifier[0], + * Returns the format information for @cmd->pixel_format specific to ``cmd->modifier[0]``, * or %NULL if the modifier doesn't override the format. */ const struct drm_format_info * -- 2.37.3
[PATCH v3 06/37] drm/i915: intel_wakeref.h: fix some kernel-doc markups
Two documented functions don't match the kernel-doc comments, as reported by kernel-doc: drivers/gpu/drm/i915/intel_wakeref.h:117: warning: expecting prototype for intel_wakeref_get_if_in_use(). Prototype was for intel_wakeref_get_if_active() instead drivers/gpu/drm/i915/intel_wakeref.h:149: warning: expecting prototype for intel_wakeref_put_flags(). Prototype was for __intel_wakeref_put() instead Fix them. Additionally, improve title for intel_wakeref_get_if_active(). Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/intel_wakeref.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wakeref.h b/drivers/gpu/drm/i915/intel_wakeref.h index 4f4c2e15e736..63e539c9b1f3 100644 --- a/drivers/gpu/drm/i915/intel_wakeref.h +++ b/drivers/gpu/drm/i915/intel_wakeref.h @@ -104,7 +104,7 @@ __intel_wakeref_get(struct intel_wakeref *wf) } /** - * intel_wakeref_get_if_in_use: Acquire the wakeref + * intel_wakeref_get_if_active: Acquire the wakeref if active * @wf: the wakeref * * Acquire a hold on the wakeref, but only if the wakeref is already @@ -130,7 +130,7 @@ intel_wakeref_might_get(struct intel_wakeref *wf) } /** - * intel_wakeref_put_flags: Release the wakeref + * __intel_wakeref_put: Release the wakeref * @wf: the wakeref * @flags: control flags * -- 2.37.3
[PATCH v3 24/37] drm/i915: i915_scatterlist.h: fix some kernel-doc markups
Building docs currently produces this warning: Documentation/foo/i915:159: ./drivers/gpu/drm/i915/i915_scatterlist.h:73: WARNING: Inline strong start-string without end-string. That's because @foo evaluates into **foo**, and placing anything after it without spaces cause Sphinx to warn and do the wrong thing.. So, replace them by a different Sphinx-compatible tag. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/i915_scatterlist.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_scatterlist.h b/drivers/gpu/drm/i915/i915_scatterlist.h index 79b70ae2e766..ac77f2668544 100644 --- a/drivers/gpu/drm/i915/i915_scatterlist.h +++ b/drivers/gpu/drm/i915/i915_scatterlist.h @@ -70,7 +70,7 @@ static inline struct scatterlist *sg_next(struct scatterlist *sg) * * Description: * If the entry is the last, return NULL; otherwise, step to the next - * element in the array (@sg@+1). If that's a chain pointer, follow it; + * element in the array (``sg@+1``). If that's a chain pointer, follow it; * otherwise just return the pointer to the current element. **/ static inline struct scatterlist *__sg_next(struct scatterlist *sg) -- 2.37.3
[PATCH v3 17/37] drm/i915: i915_gem_wait.c: fix a kernel-doc markup
The return codes for i915_gem_wait_ioctl() have identation issues, and will be displayed on a very confusing way. Use lists to improve its output. Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_wait.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c b/drivers/gpu/drm/i915/gem/i915_gem_wait.c index 4a33ad2d122b..1fd5cff552ed 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c @@ -210,23 +210,25 @@ static unsigned long to_wait_timeout(s64 timeout_ns) * @data: ioctl data blob * @file: drm file pointer * - * Returns 0 if successful, else an error is returned with the remaining time in - * the timeout parameter. - * -ETIME: object is still busy after timeout - * -ERESTARTSYS: signal interrupted the wait - * -ENONENT: object doesn't exist - * Also possible, but rare: - * -EAGAIN: incomplete, restart syscall - * -ENOMEM: damn - * -ENODEV: Internal IRQ fail - * -E?: The add request failed - * * The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any * non-zero timeout parameter the wait ioctl will wait for the given number of * nanoseconds on an object becoming unbusy. Since the wait itself does so * without holding struct_mutex the object may become re-busied before this * function completes. A similar but shorter * race condition exists in the busy * ioctl + * + * Returns: + * 0 if successful, else an error is returned with the remaining time in + * the timeout parameter. + * * -ETIME: object is still busy after timeout + * * -ERESTARTSYS: signal interrupted the wait + * * -ENONENT: object doesn't exist + * + * Also possible, but rare: + * * -EAGAIN: incomplete, restart syscall + * * -ENOMEM: damn + * * -ENODEV: Internal IRQ fail + * * -E?: The add request failed */ int i915_gem_wait_ioctl(struct drm_device *dev, void *data, struct drm_file *file) -- 2.37.3
[PATCH v3 12/37] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
The return code table is not properly marked, causing warnings
and being badly parsed by Sphinx:
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
Definition list ends without a blank line; unexpected unindent.
Use table markups to fix it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index d213d8ad1ea5..27c3b9f39c8b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp *intel_dp,
const u8 dpcd[DP_RECEI
* transparent mode link training mode.
*
* Returns:
+ * =
* >0 if LTTPRs were detected and the non-transparent LT mode was set. The
* DPRX capabilities are read out.
*0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
* detection failure and the transparent LT mode was set. The DPRX
* capabilities are read out.
* <0 Reading out the DPRX capabilities failed.
+ * =
*/
int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
{
--
2.37.3
[PATCH v3 04/37] drm/i915: gvt: fix kernel-doc trivial warnings
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting
prototype for inte_gvt_free_vgpu_resource(). Prototype was for
intel_vgpu_free_resource() instead
drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting
prototype for intel_alloc_vgpu_resource(). Prototype was for
intel_vgpu_alloc_resource() instead
drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype
for intel_vgpu_emulate_cfg_read(). Prototype was for
intel_vgpu_emulate_cfg_write() instead
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'info' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'kref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'initref' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or
member 'list' not described in 'intel_vgpu_dmabuf_obj'
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
for intel_t_default_mmio_write(). Prototype was for
intel_vgpu_default_mmio_write() instead
drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
prototype for intel_gvt_switch_render_mmio(). Prototype was for
intel_gvt_switch_mmio() instead
drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype
for intel_vgpu_enable_page_track(). Prototype was for
intel_vgpu_disable_page_track() instead
drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for
intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for
intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() instead
drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for
intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu()
instead
Reviewed-by: Rodrigo Vivi
Acked-by: Zhenyu Wang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/
drivers/gpu/drm/i915/gvt/cfg_space.c | 2 +-
drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index eef3bba8a41b..bff63babacd5 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -244,7 +244,7 @@ static void emulate_pci_bar_write(struct intel_vgpu *vgpu,
unsigned int offset,
}
/**
- * intel_vgpu_emulate_cfg_read - emulate vGPU configuration space write
+ * intel_vgpu_emulate_cfg_write - emulate vGPU configuration space write
* @vgpu: target vgpu
* @offset: offset
* @p_data: write data ptr
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h
b/drivers/gpu/drm/i915/gvt/dmabuf.h
index 5f8f03fb1d1b..3dcdb6570eda 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.h
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
@@ -48,7 +48,7 @@ struct intel_vgpu_fb_info {
struct intel_vgpu_dmabuf_obj *obj;
};
-/**
+/*
* struct intel_vgpu_dmabuf_obj- Intel vGPU device buffer object
*/
struct intel_vgpu_dmabuf_obj {
diff --git a/drivers/gpu/drm/i915/gvt/page_track.c
b/drivers/gpu/drm/i915/gvt/page_track.c
index 3375b51c75f1..df34e73cba41 100644
--- a/drivers/gpu/drm/i915/gvt/page_track.c
+++ b/drivers/gpu/drm/i915/gvt/page_track.c
@@ -120,7 +120,7 @@ int intel_vgpu_enable_page_track(struct intel_vgpu *vgpu,
unsigned long gfn)
}
/**
- * intel_vgpu_enable_page_track - cancel write-protection on guest page
+ * intel_vgpu_disable_page_track - cancel write-protection on guest page
* @vgpu: a vGPU
* @gfn: the gfn of guest page
*
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 46da19b3225d..8e71cda19995 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -205,7 +205,7 @@ static void intel_gvt_update_vgpu_types(struct intel_gvt
*gvt)
}
/**
- * intel_gvt_active_vgpu - activate a virtual GPU
+ * intel_gvt_activate_vgpu - activate a virtual GPU
* @vgpu: virtual GPU
*
* This function is called when user
[PATCH v3 01/37] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files
There are several trivial warnings there, due to trivial things: - lack of function name at the kerneldoc markup; - renamed functions; - wrong parameter syntax. Fix such warnings: drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'active' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fence' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or member 'fn' not described in '__i915_active_fence_init' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'active' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or member 'rq' not described in 'i915_active_fence_set' drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or member 'active' not described in 'i915_active_fence_get' drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or member 'active' not described in 'i915_active_fence_isset' drivers/gpu/drm/i915/i915_gem.c:443: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Reads data from the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:532: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * This is the fast pwrite path, where we copy the data directly from the drivers/gpu/drm/i915/i915_gem.c:717: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Writes data to the object referenced by handle. drivers/gpu/drm/i915/i915_gem.c:802: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Called when user space has done writes to this buffer drivers/gpu/drm/i915/i915_pmu.h:22: warning: cannot understand function prototype: 'enum i915_pmu_tracked_events ' drivers/gpu/drm/i915/i915_pmu.h:33: warning: cannot understand function prototype: 'enum ' drivers/gpu/drm/i915/i915_pmu.h:42: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * How many different events we track in the global PMU mask. drivers/gpu/drm/i915/i915_request.h:177: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Request queue structure. drivers/gpu/drm/i915/i915_request.h:473: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Returns true if seq1 is later than seq2. drivers/gpu/drm/i915/i915_scatterlist.c:63: warning: Function parameter or member 'size' not described in 'i915_refct_sgt_init' drivers/gpu/drm/i915/i915_scatterlist.h:153: warning: Incorrect use of kernel-doc format: * release() - Free the memory of the struct i915_refct_sgt drivers/gpu/drm/i915/i915_scatterlist.h:157: warning: Function parameter or member 'release' not described in 'i915_refct_sgt_ops' drivers/gpu/drm/i915/i915_scatterlist.h:180: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_put' drivers/gpu/drm/i915/i915_scatterlist.h:191: warning: Function parameter or member 'rsgt' not described in 'i915_refct_sgt_get' drivers/gpu/drm/i915/i915_scatterlist.h:207: warning: Function parameter or member 'rsgt' not described in '__i915_refct_sgt_init' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'OP' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'COND' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'US' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmin' not described in '__wait_for' drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or member 'Wmax' not described in '__wait_for' drivers/gpu/drm/i915/i915_vma_resource.h:88: warning: Incorrect use of kernel-doc format: * struct i915_vma_bindinfo - Information needed for async bind drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function parameter or member 'bi' not described in 'i915_vma_resource' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche
[PATCH v3 08/37] drm/i915: i915_gem_ttm_pm.c: fix kernel-doc markups
The documentation for the flags field is missing there. It sounds that some last-time change converted some bools into flags, but the kernel-doc change didn't follow it. Fix those warnings: drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Function parameter or member 'flags' not described in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Excess function parameter 'backup_pinned' description in 'i915_ttm_backup_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Function parameter or member 'flags' not described in 'i915_ttm_restore_region' drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:199: warning: Excess function parameter 'allow_gpu' description in 'i915_ttm_restore_region' Reviewed-by: Rodrigo Vivi Signed-off-by: Mauro Carvalho Chehab --- To avoid mailbombing on a large number of people, only mailing lists were C/C on the cover. See [PATCH v3 00/37] at: https://lore.kernel.org/all/cover.1662708705.git.mche...@kernel.org/ drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c index 07e49f22f2de..03256ebbeb5f 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c @@ -128,8 +128,9 @@ void i915_ttm_recover_region(struct intel_memory_region *mr) /** * i915_ttm_backup_region - Back up all objects of a region to smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter for this backup. - * @backup_pinned: Backup also pinned objects. + * @flags: Bitmap field with the following flags: + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; + * %I915_TTM_BACKUP_PINNED: backup also pinned objects. * * Loops over all objects of a region and either evicts them if they are * evictable or backs them up using a backup object if they are pinned. @@ -193,7 +194,8 @@ static int i915_ttm_restore(struct i915_gem_apply_to_region *apply, /** * i915_ttm_restore_region - Restore backed-up objects of a region from smem. * @mr: The memory region - * @allow_gpu: Whether to allow the gpu blitter to recover. + * @flags: Bitmap field with the following flags: + * %I915_TTM_BACKUP_ALLOW_GPU: allow the gpu blitter for this backup; * * Loops over all objects of a region and if they are backed-up, restores * them from smem. -- 2.37.3
Re: [Intel-gfx] [PATCH v2 30/39] docs: gpu: i915.rst: gt: add more kernel-doc markups
On Tue, 9 Aug 2022 06:01:53 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:18AM +0100, Mauro Carvalho Chehab wrote: > > There are several documented GT kAPI that aren't currently part > > of the docs. Add them, as this allows identifying issues with > > badly-formatted tags. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 43 +- > > 1 file changed, 42 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 2ad7941a79f2..afd8c0e3c689 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -149,7 +149,6 @@ Misc display functions > > > > .. kernel-doc:: drivers/gpu/drm/i915/display/skl_scaler.c > > > > - > > Plane Configuration > > --- > > > > @@ -308,6 +307,48 @@ Multicast/Replicated (MCR) Registers > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_mcr.c > > :internal: > > > > +GT engine > > +- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_cs.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_engine_pm.c > > + > > +GT context > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_context.h > > why does the context deserves a separated section and the > many others below no? Good question. The patches adding stuff to i915.rst are the hardest ones to produce, in the sense that it is not easy to have a common criteria about when creating or not a new section. I tried to follow the same as other things for the same type, but it is hard to classify. The main point is that they should be somewhere there, in order to start producing errors when building the docs. Reorganizing those markups should be easily done once all files with kernel-docs gets added there. Anyway, I'll keep this under: Other GT functionality Section. We can shift things later on as needed. > > + > > +Graphics Translation Tables > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_ggtt.c > > + > > +Other GT functionality > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gsc.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gtt.h > > Why aren't these gtt ones in the above block? why only > having the global gtt there? Makes sense. I'll place GTT together with GGTT. > > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_migrate.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_mocs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rc6.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_reset.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps_types.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_rps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_sseu.c > > + > > Memory Management and Command Submission > > > > > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 35/39] docs: gpu: i915.rst: add the remaining kernel-doc markup files
On Tue, 9 Aug 2022 06:20:57 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:23AM +0100, Mauro Carvalho Chehab wrote: > > There are other files with kernel-doc markups: > > > > $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/) > > >kernel-doc-files > > $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i > > Documentation/)" == "" ]; then echo "$i"; fi; done >aaa > > > > Add them to i915.rst as well. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > Documentation/gpu/i915.rst | 87 ++ > > 1 file changed, 87 insertions(+) > > > > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst > > index 974754586be8..6bb50edc6d79 100644 > > --- a/Documentation/gpu/i915.rst > > +++ b/Documentation/gpu/i915.rst > > @@ -13,6 +13,11 @@ Core Driver Infrastructure > > This section covers core driver infrastructure used by both the display > > and the GEM parts of the driver. > > > > +Core driver > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_driver.c > > + > > Runtime Power Management > > > > > > @@ -29,6 +34,10 @@ Runtime Power Management > > > > .. kernel-doc:: drivers/gpu/drm/i915/intel_pm.c > > > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wakeref.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_active.h > > not sure if this belongs to this group... > > > + > > Interrupt Handling > > -- > > > > @@ -44,6 +53,28 @@ Interrupt Handling > > .. kernel-doc:: drivers/gpu/drm/i915/i915_irq.c > > :functions: intel_runtime_pm_enable_interrupts > > > > +Error handling > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_gpu_error.c > > not sure if this gt hang stuff deserves a separated section > alone and if the name is the best one > > > + > > +Memory Handling > > +--- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma_resource.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_vma.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_mm.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_memory_region.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_memcpy.c > > + > > Intel GVT-g Guest Support(vGPU) > > ^ missing space > > > --- > > > > @@ -109,6 +140,54 @@ Workarounds > > .. kernel-doc:: drivers/gpu/drm/i915/gt/intel_workarounds.c > > :doc: Hardware workarounds > > > > +32-bits compatible ioctl Logic > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_ioc32.c > > + > > +Scatterlist handling > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scatterlist.c > > + > > +i915 request > > + > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_request.c > > + > > +Ancillary routines > > maybe simply have an "Others" section and put everything > that has only one item like the gpu hang one? OK! > > > +-- > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_deps.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_device_info.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_params.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_sw_fence_work.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_syncmap.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_pcode.c > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/i915_reg_defs.h > > + > > +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.h > > + > > + > > +PXP > > Protected Xe Path (PXP) >
Re: [Intel-gfx] [PATCH v2 18/39] drm/i915: intel_pm.c: fix some ascii artwork at kernel-doc
On Tue, 9 Aug 2022 05:55:10 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:06AM +0100, Mauro Carvalho Chehab wrote:
> > Preserving ascii artwork on kernel-docs is tricky, as it needs
> > to respect both the Sphinx rules and be properly parsed by
> > kernel-doc script.
> >
> > The Sphinx syntax require code-blocks, which is:
> >
> > ::
> >
> > followed by a blank line and indented lines.
> >
> > But kernel-doc only works fine if the first and the last line
> > are indented with the same amount of spaces.
> >
> > Also, a "\" at the end means that the next line should be merged
> > with the first one.
>
> my first reaction was: "do we really need those new empty ( ) blocks?"
>
> Then I read this ;)
Yeah, it is tricky to get it right, due to kernel-doc + Sphinx here.
Also, I bet that this would be needed even for ReST files with
C code on it, as it is likely the C domain encoding at Sphinx that
handles continuation lines with "\" at the end...
>
> Reviewed-by: Rodrigo Vivi
>
> >
> > Change the ascii artwork to be on code-blocks, starting all
> > lines at the same characters and not ending with a backslash.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/intel_pm.c | 33 ++---
> > 1 file changed, 18 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index f06babdb3a8c..d3393752b04b 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -684,18 +684,20 @@ static const struct intel_watermark_params
> > i845_wm_info = {
> > * FIFO is relatively small compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - * |\ |\
> > - * | \ | \
> > - * __---__---__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\ |\ ( )
> > + * | | \ | \ ( )
> > + * | __---__---__ (- plane active, _ blanking)
> > + * +---> time
> > *
> > - * or perhaps like this:
> > + * or perhaps like this::
> > *
> > - * |\|\ |\|\
> > - * ______ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\|\ |\|\ ( )
> > + * | ______ (- plane active, _ blanking)
> > + * +---> time
> > *
> > * Returns:
> > * The watermark in bytes
> > @@ -731,13 +733,14 @@ static unsigned int intel_wm_method1(unsigned int
> > pixel_rate,
> > * FIFO is relatively large compared to the amount of data
> > * fetched.
> > *
> > - * The FIFO level vs. time graph might look something like:
> > + * The FIFO level vs. time graph might look something like::
> > *
> > - *|\___ |\___
> > - *|\___ |\___
> > - *|\ |\
> > - * __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > - * -> time
> > + * ^
> > + * | |\___ |\___( )
> > + * | |\___ |\___( )
> > + * | |\ |\ ( )
> > + * | __ --__--__--__--__--__--__ (- plane active, _ blanking)
> > + * +-> time
> > *
> > * Returns:
> > * The watermark in bytes
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 16/39] drm/i915: intel_fb: fix a kernel-doc issue with Sphinx
On Fri, 15 Jul 2022 17:40:25 -0400 Rodrigo Vivi wrote: > On Wed, Jul 13, 2022 at 09:12:04AM +0100, Mauro Carvalho Chehab wrote: > > We can't use %foo[] as this produces a bad markup. > > Use instead, the emphasis markup directly. > > > > Fix this issue: > > Documentation/gpu/i915:136: > > ./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong > > start-string without end-string. > > > > Signed-off-by: Mauro Carvalho Chehab > > Just trying to understand as well on why in a few you had chosen ```foo``` > and here **foo**. why? > No particular reason. I'll use ``foo`` here too, keeping your reviewed-by. > anyway, not a blocker: > > Reviewed-by: Rodrigo Vivi > > > > > --- > > > > To avoid mailbombing on a large number of people, only mailing lists were > > C/C on the cover. > > See [PATCH v2 00/39] at: > > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/ > > > > drivers/gpu/drm/i915/display/intel_fb.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c > > b/drivers/gpu/drm/i915/display/intel_fb.c > > index b191915ab351..fe72c75a9c79 100644 > > --- a/drivers/gpu/drm/i915/display/intel_fb.c > > +++ b/drivers/gpu/drm/i915/display/intel_fb.c > > @@ -276,7 +276,7 @@ lookup_format_info(const struct drm_format_info > > formats[], > > * @cmd: FB add command structure > > * > > * Returns: > > - * Returns the format information for @cmd->pixel_format specific to > > @cmd->modifier[0], > > + * Returns the format information for @cmd->pixel_format specific to > > **cmd->modifier[0]**, > > * or %NULL if the modifier doesn't override the format. > > */ > > const struct drm_format_info * > > -- > > 2.36.1 > >
Re: [Intel-gfx] [PATCH v2 15/39] drm/i915: intel_dp_link_training.c: fix kernel-doc markup
On Tue, 9 Aug 2022 05:51:39 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:03AM +0100, Mauro Carvalho Chehab wrote:
> > The return code table is not properly marked, causing warnings
> > and being badly parsed by Sphinx:
> >
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
> > quote ends without a blank line; unexpected unindent.
> > Documentation/gpu/i915:130:
> > ./drivers/gpu/drm/i915/display/intel_dp_link_training.c:186: WARNING:
> > Definition list ends without a blank line; unexpected unindent.
> >
> > Use table markups to fix it.
>
> cool, I didn't know that
Yeah, you can use almost all Sphinx tags inside a kernel-doc markup,
taking some care with indents and not conflicting with the things
that kernel-doc itself parses.
The same is also valid for uAPI stuff inside Documentation/ABI.
Regards,
Mauro
>
> Reviewed-by: Rodrigo Vivi
>
>
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > index 9feaf1a589f3..23a269fcf6ca 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> > @@ -177,12 +177,14 @@ static int intel_dp_init_lttpr(struct intel_dp
> > *intel_dp, const u8 dpcd[DP_RECEI
> > * transparent mode link training mode.
> > *
> > * Returns:
> > + *
> > =
> > * >0 if LTTPRs were detected and the non-transparent LT mode was set.
> > The
> > * DPRX capabilities are read out.
> > *0 if no LTTPRs or more than 8 LTTPRs were detected or in case of a
> > * detection failure and the transparent LT mode was set. The DPRX
> > * capabilities are read out.
> > * <0 Reading out the DPRX capabilities failed.
> > + *
> > =
> > */
> > int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
> > {
> > --
> > 2.36.1
> >
Re: [Intel-gfx] [PATCH v2 38/39] drm/i915: add descriptions for some RPM macros at intel_gt_pm.h
On Tue, 9 Aug 2022 06:12:06 -0400
Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:12:26AM +0100, Mauro Carvalho Chehab wrote:
> > The intel_gt_pm.h file contains some convenient macros to be used
> > in GT code in order to get/put runtime PM references and for
> > checking them.
> >
> > Add descriptions based on the ones at intel_wakeref.h and
> > intel_runtime_pm.c.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH v2 00/39] at:
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> >
> > Documentation/gpu/i915.rst| 2 +
> > drivers/gpu/drm/i915/gt/intel_gt_pm.h | 62 +++
> > 2 files changed, 64 insertions(+)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 6bb50edc6d79..9862d504df4d 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -709,6 +709,8 @@ Table Manager (TTM)
> >
> > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> >
> > +.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_gt_pm.h
>
> I don't believe this is the right placement for this.
I'll add it then at:
Other GT functionality
Section.
Regards,
Mauro
>
> the rest lgtm
>
> > +
> > Graphics Execution Manager (GEM)
> >
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > index bc898df7a48c..a8ea6846980a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > @@ -11,21 +11,57 @@
> > #include "intel_gt_types.h"
> > #include "intel_wakeref.h"
> >
> > +/**
> > + * intel_gt_pm_is_awake: Query whether the runtime PM is awake held
> > + *
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Returns: true if a runtime pm reference is currently held and the GT is
> > + * awake.
> > + */
> > static inline bool intel_gt_pm_is_awake(const struct intel_gt *gt)
> > {
> > return intel_wakeref_is_active(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get: grab a runtime PM reference ensuring that GT is
> > powered up
> > + * @gt: pointer to the graphics engine
> > + *
> > + * Any runtime pm reference obtained by this function must have a symmetric
> > + * call to intel_gt_pm_put() to release the reference again.
> > + *
> > + * Note that this is allowed to fail, in which case the runtime-pm wakeref
> > + * will be released and the acquisition unwound.
> > + */
> > static inline void intel_gt_pm_get(struct intel_gt *gt)
> > {
> > intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * __intel_gt_pm_get: Acquire the runtime PM reference again
> > + * @gt: pointer to the graphics engine which contains the wakeref
> > + *
> > + * Increment the PM reference counter, only valid if it is already held by
> > + * the caller.
> > + *
> > + * See intel_gt_pm_get().
> > + */
> > static inline void __intel_gt_pm_get(struct intel_gt *gt)
> > {
> > __intel_wakeref_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_get_if_awake: Acquire the runtime PM reference if active
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Acquire a hold on the PM reference, but only if the GT is already
> > + * active.
> > + *
> > + * Returns: true if the wakeref was acquired, false otherwise.
> > + */
> > static inline bool intel_gt_pm_get_if_awake(struct intel_gt *gt)
> > {
> > return intel_wakeref_get_if_active(>wakeref);
> > @@ -36,6 +72,14 @@ static inline void intel_gt_pm_might_get(struct intel_gt
> > *gt)
> > intel_wakeref_might_get(>wakeref);
> > }
> >
> > +/**
> > + * intel_gt_pm_put: Release the runtime PM reference
> > + * @gt: pointer to the graphics engine which contains the PM reference
> > + *
> > + * Release our hold on the runtime PM for GT.
> > + *
> > + * It might power down the GT right away if this is the last reference.
> > + */
> > static inline void intel_gt_pm_put(struct intel_gt *gt)
> > {
> > intel_wakeref_put(>wakeref);
> > @@ -51,10 +95,28 @@ static inline void intel_gt_pm_might_put(struct
> > int
Re: [PATCH v2 1/3] media: vsp1: add premultiplied alpha support
Em Fri, 19 Aug 2022 05:38:28 +0300 Laurent Pinchart escreveu: > Mauro, would you be fine with this patch going through the DRM tree for > v6.1 ? I don't foresee any risk of conflict with other changes to the > VSP driver scheduled for the next kernel version. If that's fine with > you, could you give an Acked-by ? Otherwise I can send you a pull > request to create an immutable branch and base the rest on it in my pull > request for DRM, but given how small this change is, it seems a bit > overkill. Please, don't top-post. > > On Fri, Aug 19, 2022 at 05:01:10AM +0300, Laurent Pinchart wrote: > > Hi Hayama-san, > > > > Thank you for the patch. > > > > On Wed, Aug 10, 2022 at 05:37:09PM +0900, Takanari Hayama wrote: > > > To support DRM blend mode in R-Car DU driver, we must be able to pass > > > a plane with the premultiplied alpha. Adding a new property to > > > vsp1_du_atomic_config allows the R-Car DU driver to pass the > > > premultiplied alpha plane. > > > > > > Signed-off-by: Takanari Hayama Sure, this can be merged via DRM tree. > > > --- > > > drivers/media/platform/renesas/vsp1/vsp1_drm.c | 2 ++ > > > include/media/vsp1.h | 2 ++ > > > 2 files changed, 4 insertions(+) > > > > > > diff --git a/drivers/media/platform/renesas/vsp1/vsp1_drm.c > > > b/drivers/media/platform/renesas/vsp1/vsp1_drm.c > > > index 0c2507dc03d6..019e18976bd8 100644 > > > --- a/drivers/media/platform/renesas/vsp1/vsp1_drm.c > > > +++ b/drivers/media/platform/renesas/vsp1/vsp1_drm.c > > > @@ -856,6 +856,8 @@ int vsp1_du_atomic_update(struct device *dev, > > > unsigned int pipe_index, > > > rpf->mem.addr[1] = cfg->mem[1]; > > > rpf->mem.addr[2] = cfg->mem[2]; > > > > > > + rpf->format.flags = (cfg->premult) ? V4L2_PIX_FMT_FLAG_PREMUL_ALPHA : > > > 0; > > > > I'll drop the parentheses when applying. > > > > Reviewed-by: Laurent Pinchart With this change: Reviewed-by: Mauro Carvalho Chehab Regards, Mauro
[PATCH 10/13] docs: leds: add leds-qcom-lpg.rst to the index file
Address this warning:
Documentation/leds/leds-qcom-lpg.rst: WARNING: o documento não está
incluído em nenhum toctree
Signed-off-by: Mauro Carvalho Chehab
---
See [PATCH 00/13] at:
https://lore.kernel.org/all/cover.1660829433.git.mche...@kernel.org/
Documentation/leds/index.rst | 1 +
drivers/gpu/drm/scheduler/sched_main.c | 1 +
include/drm/gpu_scheduler.h| 1 +
3 files changed, 3 insertions(+)
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index e5d63b940045..014e009b0761 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -25,4 +25,5 @@ LEDs
leds-lp5562
leds-lp55xx
leds-mlxcpld
+ leds-qcom-lpg
leds-sc27xx
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 68317d3a7a27..56c53a616816 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -994,6 +994,7 @@ static int drm_sched_main(void *param)
* used
* @score: optional score atomic shared with other schedulers
* @name: name used for debugging
+ * @dev: Device structure
*
* Return 0 on success, otherwise error code.
*/
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index addb135eeea6..f31988e03256 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -435,6 +435,7 @@ struct drm_sched_backend_ops {
* @_score: score used when the driver doesn't provide one
* @ready: marks if the underlying HW is ready to work
* @free_guilty: A hit to time out handler to free the guilty job.
+ * @dev: Device structure
*
* One scheduler is implemented for each hardware ring.
*/
--
2.37.1
[PATCH 00/13] Fix documentation build warnings against 6.0-rc1
Hi Jon, This series is against 6.0-rc1, so it should apply fine on the top of your tree. After applying one fix sent to ACPI: https://lore.kernel.org/linux-acpi/20220818055156.7456-1-sakari.ai...@linux.intel.com/T/#u make htmldocs (with Sphinx 2.4.4) produces a very clean result: : Warning: Documentation/devicetree/bindings/regulator/siliconmitus,sm5703 -regulator.yaml references a file that doesn't exist: Documentation/devicetree/b indings/mfd/siliconmitus,sm5703.yaml SPHINX htmldocs --> file:///new_devel/v4l/docs/Documentation/output PARSE include/uapi/linux/dvb/ca.h PARSE include/uapi/linux/dvb/dmx.h PARSE include/uapi/linux/dvb/frontend.h PARSE include/uapi/linux/dvb/net.h PARSE include/uapi/linux/videodev2.h PARSE include/uapi/linux/media.h PARSE include/uapi/linux/cec.h PARSE include/uapi/linux/lirc.h Using sphinx_rtd_theme theme The only warning is due to a driver that got its upstream way for MFD, but it seems that the corresponding regulator driver has lost its way. If we can fix such warning, we could add a sort of "Werror" for: - some ABI issues; - kernel-doc warnings/errors; - broken kernel-doc warnings. Although there will still have Sphinx warnings that can come up from various sources, this could help to keep documentation on a better shape, as time goes by. Regards, Mauro Mauro Carvalho Chehab (13): scripts: kernel-doc: add support for EXPORT_SYMBOL variants docs: update vmemmap_dedup.rst reference docs: ja_JP: remove SubmittingPatches docs: zh_CN: remove references to rust documentation dt-bindings: arm: update arm,coresight-cpu-debug.yaml reference Documentation: coresight: fix a documentation build warning MAINTAINERS: fix wildcard for mfd da90* files MAINTAINERS: fix a typo for hpe,gxp-spifi.yaml ABI: sysfs-bus-nvdimm: fix a doc build warning docs: leds: add leds-qcom-lpg.rst to the index file fscache: fix kernel-doc markup on two functions serial: document start_rx member at struct uart_ops fs/dcache: fix a kernel-doc markup Documentation/ABI/testing/sysfs-bus-nvdimm| 2 + Documentation/leds/index.rst | 1 + .../trace/coresight/coresight-cpu-debug.rst | 2 +- Documentation/trace/coresight/coresight.rst | 2 +- .../translations/ja_JP/SubmittingPatches | 722 -- .../zh_CN/doc-guide/kernel-doc.rst| 2 - MAINTAINERS | 4 +- drivers/gpu/drm/scheduler/sched_main.c| 1 + include/drm/gpu_scheduler.h | 1 + include/linux/dcache.h| 10 +- include/linux/fscache.h | 4 +- include/linux/serial_core.h | 8 + mm/hugetlb_vmemmap.h | 2 +- scripts/kernel-doc| 8 +- 14 files changed, 33 insertions(+), 736 deletions(-) delete mode 100644 Documentation/translations/ja_JP/SubmittingPatches -- 2.37.1
