alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: tiwai@suse.de, alsa-devel@alsa-project.org,
	Mark Brown <broonie@kernel.org>,
	Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: [RFC PATCH 2/3] ASoC: Intel: bdw-rt5677: fix module load/unload issues
Date: Thu, 5 Mar 2020 16:27:23 +0200	[thread overview]
Message-ID: <20200305142723.GM1224808@smile.fi.intel.com> (raw)
In-Reply-To: <13857c7b-f7d2-9be2-c1e1-a577a774773e@linux.intel.com>

On Thu, Mar 05, 2020 at 07:47:47AM -0600, Pierre-Louis Bossart wrote:
> On 3/5/20 7:36 AM, Mark Brown wrote:
> > On Thu, Mar 05, 2020 at 07:06:15AM -0600, Pierre-Louis Bossart wrote:
> > > The use of devm_gpiod_get() in a dailink .init() callback generates issues
> > > when unloading modules. The dependencies between modules are not well
> > > handled and the snd_soc_rt5677 module cannot be removed:
> > 
> > In what way are the dependencies not well managed and why aren't we
> > requesting the GPIO on device model probe anyway?
> 
> there are a couple of machine drivers where the gpios are requested from the
> machine driver. I have no idea what it is done this way, maybe the codec
> exposes a gpiochip that's used later? I was hoping that Andy can help,

I don't know the codebase, so, I was suggested this solution based on my experience.
I can't answer right now why that had been done that way (especially that it
had been done not by me or any my involvement at the time).

> I don't fully get the acpi mapping and all.

This one is easy to explain. ACPI lacks of the proper labeling / mapping GPIO
resources. _DSD() method helps there, but there are no Wintel firmware that
supports it (Google basically is the first who utilizes it).

That's why the board code has mapping table to allow request GPIOs by label
(connection ID in terms of GPIO suybsystem).

> see the code here for reference:
> 
> https://elixir.bootlin.com/linux/v5.6-rc4/source/sound/soc/intel/boards/bdw-rt5677.c#L250
> 
> The issue happens when running our test scripts, which do a set a rmmod in a
> specific order: rmmod of the machine driver, then doing an rmmod of the
> codec driver. Somehow the second fails with the 'module in use error'.
> 
> It's probably because the devm_ release does not happen when the card is
> unregistered and the machine driver resources released since we use the
> component device. There might very well be a bug somewhere in the devm_
> handling, I just don't have a clue how to debug this - and the .exit() makes
> sense regardless in other cases unrelated to GPIOs.

Yes.

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2020-03-05 14:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 13:06 [RFC PATCH 0/3] ASoC: add dailink .exit() callback Pierre-Louis Bossart
2020-03-05 13:06 ` [RFC PATCH 1/3] ASoC: soc-core: introduce exit() callback for dailinks Pierre-Louis Bossart
2020-03-05 18:15   ` Mark Brown
2020-03-05 13:06 ` [RFC PATCH 2/3] ASoC: Intel: bdw-rt5677: fix module load/unload issues Pierre-Louis Bossart
2020-03-05 13:25   ` Andy Shevchenko
2020-03-05 13:37     ` Pierre-Louis Bossart
2020-03-05 13:36   ` Mark Brown
2020-03-05 13:47     ` Pierre-Louis Bossart
2020-03-05 13:59       ` Mark Brown
2020-03-05 14:51         ` Pierre-Louis Bossart
2020-03-05 17:43           ` Mark Brown
2020-03-05 18:08             ` Pierre-Louis Bossart
2020-03-05 18:33               ` Mark Brown
2020-03-05 19:10                 ` Mark Brown
2020-03-05 21:00                   ` Curtis Malainey
2020-03-05 21:48                   ` Pierre-Louis Bossart
2020-03-06 13:12                     ` Mark Brown
2020-03-05 14:06       ` Amadeusz Sławiński
2020-03-05 14:11         ` Mark Brown
2020-03-05 14:27       ` Andy Shevchenko [this message]
2020-03-05 17:58         ` Mark Brown
2020-03-05 13:06 ` [RFC PATCH 3/3] ASoC: Intel: kbl-rt5660: use .exit() dailink callback to release gpiod Pierre-Louis Bossart
2020-03-05 13:27   ` Andy Shevchenko

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=20200305142723.GM1224808@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).