From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: "Ceraolo Spurio, Daniele" <daniele.ceraolospurio@intel.com>
Cc: igt-dev@lists.freedesktop.org,
Alexander Usyskin <alexander.usyskin@intel.com>
Subject: Re: [igt-dev] [PATCH i-g-t 1/2] lib/igt_kmod: Wait for a kmod to finish its probe before unloding it.
Date: Thu, 31 Mar 2022 18:18:40 -0700 [thread overview]
Message-ID: <87tubdha8f.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <4fffd5fe-5605-d0ad-a295-0773036f0726@intel.com>
On Thu, 31 Mar 2022 16:09:32 -0700, Ceraolo Spurio, Daniele wrote:
>
> On 3/31/2022 3:52 PM, Dixit, Ashutosh wrote:
> > On Wed, 30 Mar 2022 11:32:58 -0700, Daniele Ceraolo Spurio wrote:
> >> Modprobing i915 can result in other dependent modules being loaded
> >> automatically as a follow up. This means that by the time the i915 load
> >> function returns these modules may still be going through their init, so
> >> if we try to immediately unload i915 again we will fail with an
> >> -EBUSY.
> > Can you explain a bit where we see this happening and if any tests fail
> > because of this? My expectation would be if module A depends on module B,
> > loading A will cause B to load, but loading B will not cause A to load. So
> > what is causing these dependent modules to load when we load i915? Is there
> > e.g. something in /etc/modprobe.d or udev which is causing this to happen?
>
> This is a new scenario, introduced with the GSC series where i915 exposes
> the GSC as an aux device and the mei-gsc module binds to it (link to the
> kernel series in the cover letter). The kernel handles the addition of an
> aux device similarly to a device hot-plug, with the relevant driver
> (mei-gsc in this case) being automatically probed, without requiring an
> explicit modprobe. This aux device probe happens separately from the parent
> device probe, which means that the i915 probe can complete and return
> before the mei-gsc probe is done. The fact that mei-gsc binds to an i915
> aux device creates a dependency, even if mei-gsc doesn't actually
> explicitly use any function exported by i915, so we need to unload it to be
> able to unload i915.
>
> > Currently in IGT we maintain a list of modules depenedent on i915 which we
> > unload prior to unloading i915. An alternative approach to this patch may
> > be to maintain a similar list in igt_i915_driver_load() and load dependent
> > modules after loading i915 as long as they are present on the system. So we
> > would not need to wait for these dependent modules to complete loading when
> > we unload i915. Do you think this is feasible?
>
> No, as mentioned above the module is loaded automatically.
OK, thanks for the explanation, this corresponds to my understanding of how
these buses (in this case aux bus) work. I have a couple more questions
which let me ask separately. Thanks.
next prev parent reply other threads:[~2022-04-01 1:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-30 18:32 [igt-dev] [PATCH i-g-t 0/2] Unload mei_gsc before i915 Daniele Ceraolo Spurio
2022-03-30 18:32 ` [igt-dev] [PATCH i-g-t 1/2] lib/igt_kmod: Wait for a kmod to finish its probe before unloding it Daniele Ceraolo Spurio
2022-03-31 22:52 ` Dixit, Ashutosh
2022-03-31 23:09 ` Ceraolo Spurio, Daniele
2022-04-01 1:18 ` Dixit, Ashutosh [this message]
2022-04-01 2:03 ` Dixit, Ashutosh
2022-04-01 2:11 ` Ceraolo Spurio, Daniele
2022-04-01 2:21 ` Dixit, Ashutosh
2022-03-30 18:32 ` [igt-dev] [PATCH i-g-t 2/2] lib/igt_kmod: Unload mei modules before unloading i915 Daniele Ceraolo Spurio
2022-03-31 21:54 ` Dixit, Ashutosh
2022-04-01 1:23 ` Dixit, Ashutosh
2022-04-01 2:04 ` Ceraolo Spurio, Daniele
2022-03-30 18:51 ` [igt-dev] ✗ GitLab.Pipeline: warning for Unload mei_gsc before i915 Patchwork
2022-03-30 19:25 ` [igt-dev] ✓ Fi.CI.BAT: success " Patchwork
2022-03-30 22:33 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tubdha8f.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=alexander.usyskin@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=igt-dev@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox