From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.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>,
Hans de Goede <hdegoede@redhat.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 19:50:45 +0300 [thread overview]
Message-ID: <YV3T5evF+hghuwge@smile.fi.intel.com> (raw)
In-Reply-To: <015e084e-70ed-7b5c-b103-8426ef0842d4@linux.intel.com>
On Wed, Oct 06, 2021 at 11:37:24AM -0500, Pierre-Louis Bossart wrote:
> 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:
...
> >>> 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 code tells that it's optional. If it's not the case, the code has
to be fixed accordingly.
> 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.
Additional pair of eyes and a brain is always good to have!
...
> >> 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:
It's used in some cases, but not with CLK APIs where it's redundant.
Otherwise I would remove it completely (actually it's possible to replace
it with the !priv->mclk test.
> + /*
> + * 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;
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
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 19:50:45 +0300 [thread overview]
Message-ID: <YV3T5evF+hghuwge@smile.fi.intel.com> (raw)
In-Reply-To: <015e084e-70ed-7b5c-b103-8426ef0842d4@linux.intel.com>
On Wed, Oct 06, 2021 at 11:37:24AM -0500, Pierre-Louis Bossart wrote:
> 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:
...
> >>> 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 code tells that it's optional. If it's not the case, the code has
to be fixed accordingly.
> 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.
Additional pair of eyes and a brain is always good to have!
...
> >> 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:
It's used in some cases, but not with CLK APIs where it's redundant.
Otherwise I would remove it completely (actually it's possible to replace
it with the !priv->mclk test.
> + /*
> + * 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;
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-10-06 16:57 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
2021-10-06 16:37 ` Pierre-Louis Bossart
2021-10-06 16:50 ` Andy Shevchenko [this message]
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=YV3T5evF+hghuwge@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--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=pierre-louis.bossart@linux.intel.com \
--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.