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
