Re: [PATCH 1/4] ASoC: dt-bindings: document new symmetric-clock-role flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux