All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Brunet <jbrunet@baylibre.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Mark Brown <broonie@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/5] ASoC: da7219: properly get clk from the provider
Date: Mon, 26 Apr 2021 21:35:13 +0200	[thread overview]
Message-ID: <1j7dkon8jy.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <69eaa840-ed77-fc01-2925-7e5e9998e80f@linux.intel.com>


On Mon 26 Apr 2021 at 20:10, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> wrote:

> On 4/21/21 7:05 AM, Jerome Brunet wrote:
>> Instead of using the clk embedded in the clk_hw (which is meant to go
>> away), a clock provider which need to interact with its own clock should
>> request clk reference through the clock provider API.
>> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>
> This patch seems to introduce a regression in our modprobe/rmmod tests

Really sorry about that :/

>
> https://github.com/thesofproject/linux/pull/2870
>
> RMMOD	snd_soc_da7219
> rmmod: ERROR: Module snd_soc_da7219 is in use
>
> Reverting this patch restores the ability to remove the module.
>
> Wondering if devm_ increases a module/device refcount somehow?

The driver is the provider and consumer, so it is consuming itself.
This was the intent, I think the patch should be correct like
this. Maybe I overlooked something on the clock side. I'll check.

I'm not sure the problem is devm_ variant, it might be 
clk_hw_get_clk() simpler variant which also plays with module ref counts.

I don't have this particular HW to check but I'll try to replicate the
test with a dummy module and report ASAP.

Of course, I suppose the same problem applies to PATCH 1 of the series

>
>> ---
>>   sound/soc/codecs/da7219.c | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
>> index 13009d08b09a..bd3c523a8617 100644
>> --- a/sound/soc/codecs/da7219.c
>> +++ b/sound/soc/codecs/da7219.c
>> @@ -2181,7 +2181,10 @@ static int da7219_register_dai_clks(struct snd_soc_component *component)
>>   				 ret);
>>   			goto err;
>>   		}
>> -		da7219->dai_clks[i] = dai_clk_hw->clk;
>> +
>> +		da7219->dai_clks[i] = devm_clk_hw_get_clk(dev, dai_clk_hw, NULL);
>> +		if (IS_ERR(da7219->dai_clks[i]))
>> +			return PTR_ERR(da7219->dai_clks[i]);
>>     		/* For DT setup onecell data, otherwise create lookup */
>>   		if (np) {
>> 


  parent reply	other threads:[~2021-04-26 19:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21 12:05 [PATCH v2 0/5] ASoC: clock provider clean-up Jerome Brunet
2021-04-21 12:05 ` Jerome Brunet
2021-04-21 12:05 ` [PATCH v2 1/5] ASoC: stm32: properly get clk from the provider Jerome Brunet
2021-04-21 12:05   ` Jerome Brunet
2021-04-21 12:05 ` [PATCH v2 2/5] ASoC: wcd934x: use the clock provider API Jerome Brunet
2021-04-21 12:05   ` Jerome Brunet
2021-04-21 12:05 ` [PATCH v2 3/5] ASoC: rt5682: clock driver must " Jerome Brunet
2021-04-21 12:05   ` Jerome Brunet
2021-04-21 12:05 ` [PATCH v2 4/5] ASoC: lpass: " Jerome Brunet
2021-04-21 12:05   ` Jerome Brunet
2021-04-21 12:05 ` [PATCH v2 5/5] ASoC: da7219: properly get clk from the provider Jerome Brunet
2021-04-21 12:05   ` Jerome Brunet
2021-04-26 18:10   ` Pierre-Louis Bossart
2021-04-26 18:39     ` Pierre-Louis Bossart
2021-04-26 19:35     ` Jerome Brunet [this message]
2021-04-27  9:16       ` Jerome Brunet
2021-04-27 10:27         ` Mark Brown
2021-04-27 10:27           ` Mark Brown
2021-04-27 11:33           ` Jerome Brunet
2021-04-27 11:33             ` Jerome Brunet
2021-04-23 18:06 ` [PATCH v2 0/5] ASoC: clock provider clean-up Mark Brown
2021-04-23 18:06   ` Mark Brown

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=1j7dkon8jy.fsf@starbuckisacylon.baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sboyd@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.