All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Rob Herring <robh+dt@kernel.org>,
	linux-gpio@vger.kernel.org, tiwai@suse.de,
	Linus Walleij <linus.walleij@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Matuschek <daniel@hifiberry.com>,
	Hui Wang <hui.wang@canonical.com>,
	Matthias Reichl <hias@horus.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock
Date: Tue, 14 Apr 2020 16:02:00 -0500	[thread overview]
Message-ID: <8876c7ef-89f1-b79f-c7c4-7862b9f37db1@linux.intel.com> (raw)
In-Reply-To: <0d2aed9b-5c79-9ed2-6ca1-67b2688e4c99@linux.intel.com>


>>>> Wait, so SCLK is in the *global* namespace and the provider has to
>>>> register the same name?  That doesn't sound clever.  It might be better
>>>> to have the board register the connection from the clock provider to 
>>>> the
>>>> device rather than hard code global namespace strings like this, that
>>>> sounds like a recipie for misery.

Thinking a bit more on this, is the objection on the notion of using a 
fixed string, on the way it's registered or the lack of support for 
clocks in ACPI?

 From a quick look, the use of a fixed string is rather prevalent, see 
below. Less than 10% of codec drivers rely on a NULL string, so is it 
really a dangerous precedent so use "sclk" in this case? It seems to me 
that all clk providers need to use a unique string - what am I missing here?

adau17x1.c:	adau->mclk = devm_clk_get(dev, "mclk");
cs42l51.c:	cs42l51->mclk_handle = devm_clk_get(dev, "MCLK");
cs42xx8.c:	cs42xx8->clk = devm_clk_get(dev, "mclk");
cs53l30.c:	cs53l30->mclk = devm_clk_get(dev, "mclk");
cx2072x.c:	cx2072x->mclk = devm_clk_get(cx2072x->dev, "mclk");
da7213.c:	da7213->mclk = devm_clk_get(component->dev, "mclk");
da7218.c:	da7218->mclk = devm_clk_get(component->dev, "mclk");
da7219.c:	da7219->mclk = devm_clk_get(component->dev, "mclk");
es8316.c:	es8316->mclk = devm_clk_get_optional(component->dev, "mclk");
es8328.c:	es8328->clk = devm_clk_get(component->dev, NULL);
inno_rk3036.c:	priv->pclk = devm_clk_get(&pdev->dev, "acodec_pclk");
jz4725b.c:	icdc->clk = devm_clk_get(&pdev->dev, "aic");
jz4770.c:	codec->clk = devm_clk_get(dev, "aic");
lochnagar-sc.c:	priv->mclk = devm_clk_get(&pdev->dev, "mclk");
max98088.c:	max98088->mclk = devm_clk_get(&i2c->dev, "mclk");
max98090.c:	max98090->mclk = devm_clk_get(component->dev, "mclk");
max98095.c:	max98095->mclk = devm_clk_get(component->dev, "mclk");
max9860.c:	mclk = clk_get(dev, "mclk");
msm8916-wcd-analog.c:	priv->mclk = devm_clk_get(dev, "mclk");
msm8916-wcd-digital.c:	priv->ahbclk = devm_clk_get(dev, "ahbix-clk");
msm8916-wcd-digital.c:	priv->mclk = devm_clk_get(dev, "mclk");
msm8916-wcd-digital.c:	mclk_rate = clk_get_rate(msm8916_wcd->mclk);
nau8825.c:	nau8825->mclk = devm_clk_get(nau8825->dev, "mclk");
nau8825.c:	nau8825->mclk = devm_clk_get(dev, "mclk");
pcm3168a.c:	pcm3168a->scki = devm_clk_get(dev, "scki");
pcm512x.c:	pcm512x->sclk = devm_clk_get(dev, NULL);
rk3328_codec.c:	rk3328->mclk = devm_clk_get(&pdev->dev, "mclk");
rk3328_codec.c:	rk3328->pclk = devm_clk_get(&pdev->dev, "pclk");
rt5514.c:	rt5514->mclk = devm_clk_get(component->dev, "mclk");
rt5616.c:	rt5616->mclk = devm_clk_get(component->dev, "mclk");
rt5640.c:	rt5640->mclk = devm_clk_get(component->dev, "mclk");
rt5659.c:	rt5659->mclk = devm_clk_get(&i2c->dev, "mclk");
rt5660.c:	rt5660->mclk = devm_clk_get(&i2c->dev, "mclk");
rt5682.c:		rt5682->mclk = devm_clk_get(component->dev, "mclk");
sirf-audio-codec.c:	sirf_audio_codec->clk = devm_clk_get(&pdev->dev, NULL);
sta32x.c:	sta32x->xti_clk = devm_clk_get(dev, "xti");
tas571x.c:	priv->mclk = devm_clk_get(dev, "mclk");
tlv320aic32x4.c:	pll = devm_clk_get(component->dev, "pll");
tscs42xx.c:		tscs42xx->sysclk = devm_clk_get(&i2c->dev, src_names[src]);
tscs454.c:		freq = clk_get_rate(tscs454->sysclk);
tscs454.c:		tscs454->sysclk = devm_clk_get(&i2c->dev, src_names[src]);
wcd9335.c:	wcd->mclk = devm_clk_get(dev, "mclk");
wcd9335.c:	wcd->native_clk = devm_clk_get(dev, "slimbus");
wm2000.c:	wm2000->mclk = devm_clk_get(&i2c->dev, "MCLK");
wm8731.c:	wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
wm8731.c:	wm8731->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8904.c:	wm8904->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8960.c:	wm8960->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8962.c:	pdata->mclk = devm_clk_get(&i2c->dev, NULL);



WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, Matthias Reichl <hias@horus.com>,
	tiwai@suse.de, Linus Walleij <linus.walleij@linaro.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Daniel Matuschek <daniel@hifiberry.com>,
	linux-clk@vger.kernel.org, Hui Wang <hui.wang@canonical.com>,
	linux-gpio@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Michael Turquette <mturquette@baylibre.com>
Subject: Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock
Date: Tue, 14 Apr 2020 16:02:00 -0500	[thread overview]
Message-ID: <8876c7ef-89f1-b79f-c7c4-7862b9f37db1@linux.intel.com> (raw)
In-Reply-To: <0d2aed9b-5c79-9ed2-6ca1-67b2688e4c99@linux.intel.com>


>>>> Wait, so SCLK is in the *global* namespace and the provider has to
>>>> register the same name?  That doesn't sound clever.  It might be better
>>>> to have the board register the connection from the clock provider to 
>>>> the
>>>> device rather than hard code global namespace strings like this, that
>>>> sounds like a recipie for misery.

Thinking a bit more on this, is the objection on the notion of using a 
fixed string, on the way it's registered or the lack of support for 
clocks in ACPI?

 From a quick look, the use of a fixed string is rather prevalent, see 
below. Less than 10% of codec drivers rely on a NULL string, so is it 
really a dangerous precedent so use "sclk" in this case? It seems to me 
that all clk providers need to use a unique string - what am I missing here?

adau17x1.c:	adau->mclk = devm_clk_get(dev, "mclk");
cs42l51.c:	cs42l51->mclk_handle = devm_clk_get(dev, "MCLK");
cs42xx8.c:	cs42xx8->clk = devm_clk_get(dev, "mclk");
cs53l30.c:	cs53l30->mclk = devm_clk_get(dev, "mclk");
cx2072x.c:	cx2072x->mclk = devm_clk_get(cx2072x->dev, "mclk");
da7213.c:	da7213->mclk = devm_clk_get(component->dev, "mclk");
da7218.c:	da7218->mclk = devm_clk_get(component->dev, "mclk");
da7219.c:	da7219->mclk = devm_clk_get(component->dev, "mclk");
es8316.c:	es8316->mclk = devm_clk_get_optional(component->dev, "mclk");
es8328.c:	es8328->clk = devm_clk_get(component->dev, NULL);
inno_rk3036.c:	priv->pclk = devm_clk_get(&pdev->dev, "acodec_pclk");
jz4725b.c:	icdc->clk = devm_clk_get(&pdev->dev, "aic");
jz4770.c:	codec->clk = devm_clk_get(dev, "aic");
lochnagar-sc.c:	priv->mclk = devm_clk_get(&pdev->dev, "mclk");
max98088.c:	max98088->mclk = devm_clk_get(&i2c->dev, "mclk");
max98090.c:	max98090->mclk = devm_clk_get(component->dev, "mclk");
max98095.c:	max98095->mclk = devm_clk_get(component->dev, "mclk");
max9860.c:	mclk = clk_get(dev, "mclk");
msm8916-wcd-analog.c:	priv->mclk = devm_clk_get(dev, "mclk");
msm8916-wcd-digital.c:	priv->ahbclk = devm_clk_get(dev, "ahbix-clk");
msm8916-wcd-digital.c:	priv->mclk = devm_clk_get(dev, "mclk");
msm8916-wcd-digital.c:	mclk_rate = clk_get_rate(msm8916_wcd->mclk);
nau8825.c:	nau8825->mclk = devm_clk_get(nau8825->dev, "mclk");
nau8825.c:	nau8825->mclk = devm_clk_get(dev, "mclk");
pcm3168a.c:	pcm3168a->scki = devm_clk_get(dev, "scki");
pcm512x.c:	pcm512x->sclk = devm_clk_get(dev, NULL);
rk3328_codec.c:	rk3328->mclk = devm_clk_get(&pdev->dev, "mclk");
rk3328_codec.c:	rk3328->pclk = devm_clk_get(&pdev->dev, "pclk");
rt5514.c:	rt5514->mclk = devm_clk_get(component->dev, "mclk");
rt5616.c:	rt5616->mclk = devm_clk_get(component->dev, "mclk");
rt5640.c:	rt5640->mclk = devm_clk_get(component->dev, "mclk");
rt5659.c:	rt5659->mclk = devm_clk_get(&i2c->dev, "mclk");
rt5660.c:	rt5660->mclk = devm_clk_get(&i2c->dev, "mclk");
rt5682.c:		rt5682->mclk = devm_clk_get(component->dev, "mclk");
sirf-audio-codec.c:	sirf_audio_codec->clk = devm_clk_get(&pdev->dev, NULL);
sta32x.c:	sta32x->xti_clk = devm_clk_get(dev, "xti");
tas571x.c:	priv->mclk = devm_clk_get(dev, "mclk");
tlv320aic32x4.c:	pll = devm_clk_get(component->dev, "pll");
tscs42xx.c:		tscs42xx->sysclk = devm_clk_get(&i2c->dev, src_names[src]);
tscs454.c:		freq = clk_get_rate(tscs454->sysclk);
tscs454.c:		tscs454->sysclk = devm_clk_get(&i2c->dev, src_names[src]);
wcd9335.c:	wcd->mclk = devm_clk_get(dev, "mclk");
wcd9335.c:	wcd->native_clk = devm_clk_get(dev, "slimbus");
wm2000.c:	wm2000->mclk = devm_clk_get(&i2c->dev, "MCLK");
wm8731.c:	wm8731->mclk = devm_clk_get(&spi->dev, "mclk");
wm8731.c:	wm8731->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8904.c:	wm8904->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8960.c:	wm8960->mclk = devm_clk_get(&i2c->dev, "mclk");
wm8962.c:	pdata->mclk = devm_clk_get(&i2c->dev, NULL);



  reply	other threads:[~2020-04-14 21:02 UTC|newest]

Thread overview: 136+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09 19:58 [RFC PATCH 00/16] ASoC/SOF/clk/gpio/dt: add Hifiberry DAC+ PRO support Pierre-Louis Bossart
2020-04-09 19:58 ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 01/16] ASoC: pcm512x: expose 6 GPIOs Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:09   ` Andy Shevchenko
2020-04-14 17:09     ` Andy Shevchenko
2020-04-14 17:52     ` Pierre-Louis Bossart
2020-04-14 17:52       ` Pierre-Louis Bossart
2020-04-15  9:49       ` Andy Shevchenko
2020-04-15  9:49         ` Andy Shevchenko
2020-04-16 11:42     ` Linus Walleij
2020-04-16 11:42       ` Linus Walleij
2020-04-16 14:25       ` Pierre-Louis Bossart
2020-04-16 14:25         ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:11   ` Andy Shevchenko
2020-04-14 17:11     ` Andy Shevchenko
2020-04-14 17:54     ` Pierre-Louis Bossart
2020-04-14 17:54       ` Pierre-Louis Bossart
2020-04-15  9:52       ` Andy Shevchenko
2020-04-15  9:52         ` Andy Shevchenko
2020-04-15 14:19         ` Pierre-Louis Bossart
2020-04-15 14:19           ` Pierre-Louis Bossart
2020-04-15 15:10           ` Andy Shevchenko
2020-04-15 15:10             ` Andy Shevchenko
2020-04-14 17:45   ` Mark Brown
2020-04-14 17:45     ` Mark Brown
2020-04-14 18:14     ` Pierre-Louis Bossart
2020-04-14 18:14       ` Pierre-Louis Bossart
2020-04-14 18:27       ` Mark Brown
2020-04-14 18:27         ` Mark Brown
2020-04-14 19:15         ` Pierre-Louis Bossart
2020-04-14 19:15           ` Pierre-Louis Bossart
2020-04-14 19:50           ` Mark Brown
2020-04-14 19:50             ` Mark Brown
2020-04-14 20:13             ` Pierre-Louis Bossart
2020-04-14 20:13               ` Pierre-Louis Bossart
2020-04-14 21:02               ` Pierre-Louis Bossart [this message]
2020-04-14 21:02                 ` Pierre-Louis Bossart
2020-04-15 11:07                 ` Mark Brown
2020-04-15 11:07                   ` Mark Brown
2020-04-15 11:36               ` Mark Brown
2020-04-15 11:36                 ` Mark Brown
2020-04-15 14:44                 ` Pierre-Louis Bossart
2020-04-15 14:44                   ` Pierre-Louis Bossart
2020-04-15 16:22                   ` Mark Brown
2020-04-15 16:22                     ` Mark Brown
2020-04-15 17:26                     ` Pierre-Louis Bossart
2020-04-15 17:26                       ` Pierre-Louis Bossart
2020-04-15 19:50                       ` Mark Brown
2020-04-15 19:50                         ` Mark Brown
2020-04-15 20:22                         ` Pierre-Louis Bossart
2020-04-15 20:22                           ` Pierre-Louis Bossart
2020-04-15 20:39                           ` Mark Brown
2020-04-15 20:39                             ` Mark Brown
2020-04-09 19:58 ` [RFC PATCH 03/16] ASoC: Intel: sof-pcm512x: use gpiod for LED Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:17   ` Andy Shevchenko
2020-04-14 17:17     ` Andy Shevchenko
2020-04-14 17:52     ` Mark Brown
2020-04-14 17:52       ` Mark Brown
2020-04-14 17:57     ` Pierre-Louis Bossart
2020-04-14 17:57       ` Pierre-Louis Bossart
2020-04-15  9:51       ` Andy Shevchenko
2020-04-15  9:51         ` Andy Shevchenko
2020-04-09 19:58 ` [RFC PATCH 04/16] ASoC: Intel: sof-pcm512x: detect Hifiberry DAC+ PRO Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:20   ` Andy Shevchenko
2020-04-14 17:20     ` Andy Shevchenko
2020-04-14 18:02     ` Pierre-Louis Bossart
2020-04-14 18:02       ` Pierre-Louis Bossart
2020-04-15  9:55       ` Andy Shevchenko
2020-04-15  9:55         ` Andy Shevchenko
2020-04-15 14:07         ` Pierre-Louis Bossart
2020-04-15 14:07           ` Pierre-Louis Bossart
2020-04-15 15:05           ` Andy Shevchenko
2020-04-15 15:05             ` Andy Shevchenko
2020-04-09 19:58 ` [RFC PATCH 05/16] ASoC: Intel: sof-pcm512x: reconfigure sclk in hw_params if needed Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:24   ` Andy Shevchenko
2020-04-14 17:24     ` Andy Shevchenko
2020-04-14 18:06     ` Pierre-Louis Bossart
2020-04-14 18:06       ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 06/16] ASoC: Intel: sof-pcm512x: select HIFIBERRY_DACPRO clk Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 07/16] clk: hifiberry-dacpro: initial import Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:31   ` Andy Shevchenko
2020-04-14 17:31     ` Andy Shevchenko
2020-04-14 18:09     ` Pierre-Louis Bossart
2020-04-14 18:09       ` Pierre-Louis Bossart
2020-04-15 10:00       ` Andy Shevchenko
2020-04-15 10:00         ` Andy Shevchenko
2020-04-09 19:58 ` [RFC PATCH 08/16] clk: hifiberry-dacpro: update SDPX/copyright Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 09/16] clk: hifiberry-dacpro: style cleanups, use devm_ Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 10/16] clk: hifiberry-dacpro: add OF dependency Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 11/16] clk: hifiberry-dacpro: transition to _hw functions Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 12/16] clk: hifiberry-dacpro: add ACPI support Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-22  9:32   ` Stephen Boyd
2020-04-22  9:32     ` Stephen Boyd
2020-04-22  9:47     ` Andy Shevchenko
2020-04-22  9:47       ` Andy Shevchenko
2020-04-22  9:54     ` Pierre-Louis Bossart
2020-04-22  9:54       ` Pierre-Louis Bossart
2020-04-22 20:52       ` Stephen Boyd
2020-04-22 20:52         ` Stephen Boyd
2020-04-22 21:08         ` Pierre-Louis Bossart
2020-04-22 21:08           ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 13/16] clk: hifiberry-dacpro: add "sclk" lookup Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-22  9:35   ` Stephen Boyd
2020-04-22  9:35     ` Stephen Boyd
2020-04-22  9:51     ` Pierre-Louis Bossart
2020-04-22  9:51       ` Pierre-Louis Bossart
2020-04-22 11:54       ` Andy Shevchenko
2020-04-22 11:54         ` Andy Shevchenko
2020-04-09 19:58 ` [RFC PATCH 14/16] clk: hifiberry-dacpro: toggle GPIOs on prepare/unprepare Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 15/16] clk: hifiberry-dacpro: add delay on clock prepare/deprepare Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-09 19:58 ` [RFC PATCH 16/16] ASoC: dt-bindings: add document for Hifiberry DAC+ PRO clock Pierre-Louis Bossart
2020-04-09 19:58   ` Pierre-Louis Bossart
2020-04-14 17:27   ` Andy Shevchenko
2020-04-14 17:27     ` Andy Shevchenko
2020-04-14 18:10     ` Pierre-Louis Bossart
2020-04-14 18:10       ` Pierre-Louis Bossart
2020-04-14 16:50 ` [RFC PATCH 00/16] ASoC/SOF/clk/gpio/dt: add Hifiberry DAC+ PRO support Andy Shevchenko
2020-04-14 16:50   ` Andy Shevchenko
2020-04-14 16:57   ` Pierre-Louis Bossart
2020-04-14 16:57     ` Pierre-Louis Bossart

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=8876c7ef-89f1-b79f-c7c4-7862b9f37db1@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=daniel@hifiberry.com \
    --cc=hias@horus.com \
    --cc=hui.wang@canonical.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --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 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.