Re: [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

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