On Fri, Jun 02, 2023 at 12:42:49PM +0000, Alvin Šipraga wrote:
> Yes I see what you mean. On my platform the clock source is actually described
> by the common clock framework, so I would want to use that. If it were a
> component driver then it would most likely be a codec that is part of the
> dai-link anyway. So what about having two struct clk pointers in struct
> snd_soc_dai?
>
> struct snd_soc_dai {
> /* ... */
> struct clk *bitclock_provider;
> struct clk *frameclock_provider;
> /* ... */
> };
> If non-NULL I could then have the ASoC core enable/disable the clocks on demand?
> I would say in hw_params/hw_free, albeit that runs after set_fmt.
hw_params() can be called repeatedly so that's not a good fit but
broadly yes.
> Having said that, I see ASoC doesn't really use the CCF much... am I way off?
Ideally we'd be representing more of the clocking via the clock
framework but at present yes.
> I don't think it's feasible to modify every component driver to explicitly
> handle this and then ignore any CBP_CFP bits set in its call to set_fmt - this
> is why I want help from the ASoC core.
Sure, but that's not going to impact the DT bindings. All these things
are driven from the machine driver.
> > If simple-card can't be made to work that's fine, it's deprecated
> > anyway.
> Ah OK, I didn't know that. Right now I'm using graph-card2, that's not
> deprecated, right?
Yes, audio-graph-card replaces simple-card.
Attachment:
signature.asc
Description: PGP signature
