[RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Wed Apr 15 17:10:42 CEST 2020
On Wed, Apr 15, 2020 at 09:19:10AM -0500, Pierre-Louis Bossart wrote:
> On 4/15/20 4:52 AM, Andy Shevchenko wrote:
> > On Tue, Apr 14, 2020 at 12:54:25PM -0500, Pierre-Louis Bossart wrote:
> > > On 4/14/20 12:11 PM, Andy Shevchenko wrote:
> > > > On Thu, Apr 09, 2020 at 02:58:27PM -0500, Pierre-Louis Bossart wrote:
> > > > > Using devm_clk_get() with a NULL string fails on ACPI platforms, use
> > > > > the "sclk" string as a fallback.
> > > >
> > > > This is fishy a bit.
> > >
> > > I didn't find a single example where we use a NULL string in ACPI cases?
> >
> > ...
> >
> > > > If no, why not simple switch to devm_clk_get_optional()?
> > >
> > > Not sure what that would change?
> >
> > Hmm... Who is the provider of this clock?
>
> Well, at the hardware level, the clock is provided by two local oscillators
> controlled by the codec GPIOs. So you could consider that the codec is both
> the provider and consumer of the clock.
Is it internal component to the codec or discrete (outside of codec chip)?
I bet it is the latter. Thus, codec is not provider. Board, where this
configuration is used, *is* provider of the clock(s).
> In the Linux world, the PCM512x codec driver creates a gpiochip. And the clk
> driver uses the gpios to expose a clk used by the PCM512x codec driver.
Yeah, hardware cyclic dependency :-)
> I am not fully happy with this design because it creates a double dependency
> which makes it impossible to remove modules. But I don't know how to model
> it otherwise.
I guess it should be clock provider which uses GPIO as a parameter to switch
clock rates, and codec driver, which provides GPIO chip and instantiates
(after) the clock provider instance. One module or several, is an
implementation detail.
> But to go back to your question, the two parts are really joined at the hip
> since the same gpios exposed by one is used by the other.
I got it, thanks for explanation.
--
With Best Regards,
Andy Shevchenko
More information about the Alsa-devel
mailing list