All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: Cezary Rojewski <cezary.rojewski@intel.com>,
	Takashi Iwai <tiwai@suse.com>,
	Jie Yang <yang.jie@linux.intel.com>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v1 3/4] ASoC: Intel: bytcr_rt5651: use devm_clk_get_optional() for mclk
Date: Wed, 6 Oct 2021 11:37:24 -0500	[thread overview]
Message-ID: <015e084e-70ed-7b5c-b103-8426ef0842d4@linux.intel.com> (raw)
In-Reply-To: <YV3NZnb6mg43nUC1@smile.fi.intel.com>



On 10/6/21 11:23 AM, Andy Shevchenko wrote:
> On Wed, Oct 06, 2021 at 10:51:52AM -0500, Pierre-Louis Bossart wrote:
>> On 10/6/21 10:04 AM, Andy Shevchenko wrote:
>>> The devm_clk_get_optional() helper returns NULL when devm_clk_get()
>>> returns -ENOENT. This makes things slightly cleaner. The added benefit
>>> is mostly cosmetic.
> 
> ...
> 
>>>  	if (SND_SOC_DAPM_EVENT_ON(event)) {
>>> -		if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN) {
>>> -			ret = clk_prepare_enable(priv->mclk);
>>> -			if (ret < 0) {
>>> -				dev_err(card->dev,
>>> -					"could not configure MCLK state");
>>> -				return ret;
>>> -			}
>>> +		ret = clk_prepare_enable(priv->mclk);
>>> +		if (ret < 0) {
>>> +			dev_err(card->dev, "could not configure MCLK state");
>>> +			return ret;
>>>  		}
>>
>> I don't get why you removed the test on the BYT_RT5651_MCLK_EN quirk,
>> see below it was designed as a fall-back mode. We don't want to return
>> an error when we know the clock is not present/desired.
> 
> Why should we do a unneeded test? When we switch to the optional, there
> will be no error from these CCF APIs. Besides that it drops indentation
> level and makes code neat.

By looking at this code only one cannot really visualize that it's a
no-op. I personally prefer to see explicit intent rather than have to
dig hundreds of lines below what this clock is optional.

I am also not even sure that in real products this clock is actually
optional, the default is to make use of it:

#define BYT_RT5651_DEFAULT_QUIRKS	(BYT_RT5651_MCLK_EN | \

and the only platform without this clock is "Minnowboard Max B3" -
probably not used by anyone. I fried mine a long time ago.

We'd need to Hans to comment on this since he's really the only one
maintaining this code.

> ...
> 
>> same here, why was the quirk removed?
> 
> Same answer.
> 
> ...
> 
>> that part in the probe looks fine, but the changes above are controversial.
> 
> I didn't get. How controversial? Why? The whole point of _optional is to get
> rid of unneeded checks (since they are _anyway_ be called).

It's inconsistent since you kept the following part but no longer use it:

+		/*
+		 * Fall back to bit clock usage when clock is not
+		 * available likely due to missing dependencies.
+		 */
+		if (!priv->mclk)
+			byt_rt5651_quirk &= ~BYT_RT5651_MCLK_EN;




WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>
Cc: Mark Brown <broonie@kernel.org>,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Jie Yang <yang.jie@linux.intel.com>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>
Subject: Re: [PATCH v1 3/4] ASoC: Intel: bytcr_rt5651: use devm_clk_get_optional() for mclk
Date: Wed, 6 Oct 2021 11:37:24 -0500	[thread overview]
Message-ID: <015e084e-70ed-7b5c-b103-8426ef0842d4@linux.intel.com> (raw)
In-Reply-To: <YV3NZnb6mg43nUC1@smile.fi.intel.com>



On 10/6/21 11:23 AM, Andy Shevchenko wrote:
> On Wed, Oct 06, 2021 at 10:51:52AM -0500, Pierre-Louis Bossart wrote:
>> On 10/6/21 10:04 AM, Andy Shevchenko wrote:
>>> The devm_clk_get_optional() helper returns NULL when devm_clk_get()
>>> returns -ENOENT. This makes things slightly cleaner. The added benefit
>>> is mostly cosmetic.
> 
> ...
> 
>>>  	if (SND_SOC_DAPM_EVENT_ON(event)) {
>>> -		if (byt_rt5651_quirk & BYT_RT5651_MCLK_EN) {
>>> -			ret = clk_prepare_enable(priv->mclk);
>>> -			if (ret < 0) {
>>> -				dev_err(card->dev,
>>> -					"could not configure MCLK state");
>>> -				return ret;
>>> -			}
>>> +		ret = clk_prepare_enable(priv->mclk);
>>> +		if (ret < 0) {
>>> +			dev_err(card->dev, "could not configure MCLK state");
>>> +			return ret;
>>>  		}
>>
>> I don't get why you removed the test on the BYT_RT5651_MCLK_EN quirk,
>> see below it was designed as a fall-back mode. We don't want to return
>> an error when we know the clock is not present/desired.
> 
> Why should we do a unneeded test? When we switch to the optional, there
> will be no error from these CCF APIs. Besides that it drops indentation
> level and makes code neat.

By looking at this code only one cannot really visualize that it's a
no-op. I personally prefer to see explicit intent rather than have to
dig hundreds of lines below what this clock is optional.

I am also not even sure that in real products this clock is actually
optional, the default is to make use of it:

#define BYT_RT5651_DEFAULT_QUIRKS	(BYT_RT5651_MCLK_EN | \

and the only platform without this clock is "Minnowboard Max B3" -
probably not used by anyone. I fried mine a long time ago.

We'd need to Hans to comment on this since he's really the only one
maintaining this code.

> ...
> 
>> same here, why was the quirk removed?
> 
> Same answer.
> 
> ...
> 
>> that part in the probe looks fine, but the changes above are controversial.
> 
> I didn't get. How controversial? Why? The whole point of _optional is to get
> rid of unneeded checks (since they are _anyway_ be called).

It's inconsistent since you kept the following part but no longer use it:

+		/*
+		 * Fall back to bit clock usage when clock is not
+		 * available likely due to missing dependencies.
+		 */
+		if (!priv->mclk)
+			byt_rt5651_quirk &= ~BYT_RT5651_MCLK_EN;




  reply	other threads:[~2021-10-06 16:39 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 15:04 [PATCH v1 1/4] ASoC: Intel: bytcr_rt5651: Get platform data via dev_get_platdata() Andy Shevchenko
2021-10-06 15:04 ` Andy Shevchenko
2021-10-06 15:04 ` [PATCH v1 2/4] ASoC: Intel: bytcr_rt5651: Use temporary variable for struct device Andy Shevchenko
2021-10-06 15:04   ` Andy Shevchenko
2021-10-06 15:04 ` [PATCH v1 3/4] ASoC: Intel: bytcr_rt5651: use devm_clk_get_optional() for mclk Andy Shevchenko
2021-10-06 15:04   ` Andy Shevchenko
2021-10-06 15:51   ` Pierre-Louis Bossart
2021-10-06 15:51     ` Pierre-Louis Bossart
2021-10-06 16:23     ` Andy Shevchenko
2021-10-06 16:23       ` Andy Shevchenko
2021-10-06 16:37       ` Pierre-Louis Bossart [this message]
2021-10-06 16:37         ` Pierre-Louis Bossart
2021-10-06 16:50         ` Andy Shevchenko
2021-10-06 16:50           ` Andy Shevchenko
2021-10-06 17:06           ` Mark Brown
2021-10-06 17:06             ` Mark Brown
2021-10-06 17:11         ` Hans de Goede
2021-10-06 17:11           ` Hans de Goede
2021-10-06 17:18           ` Pierre-Louis Bossart
2021-10-06 17:18             ` Pierre-Louis Bossart
2021-10-06 17:21           ` Andy Shevchenko
2021-10-06 17:21             ` Andy Shevchenko
2021-10-06 15:04 ` [PATCH v1 4/4] ASoC: Intel: bytcr_rt5651: Utilize dev_err_probe() to avoid log saturation Andy Shevchenko
2021-10-06 15:04   ` 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=015e084e-70ed-7b5c-b103-8426ef0842d4@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tiwai@suse.com \
    --cc=yang.jie@linux.intel.com \
    /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.