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.