On Mon, Mar 15, 2021 at 08:49:00PM +0530, Sameer Pujar wrote: > On 3/15/2021 5:35 PM, Michael Walle wrote: > > Am 2021-03-12 14:46, schrieb Mark Brown: > > Sameer, it looks like the proper fix should be to add the clock > > support to your codec. > I agree that complicated clock relationships should be handled within the > codec itself, however MCLK rate setting depends on "mclk-fs" factor and this > property is specified as part of simple-card/audio-graph-card codec subnode. > Right now codec, in general, does not have a way to know this. The > set_sysclk() callback takes rate argument and not the factor. Moreover the I just don't understand what you're saying here at all. At the point where the card is setting the clock API clock rate it can just as well set a sysclk, these are equivalent operations. > same codec is used by other platform vendors too and unless a new DT > property is added for codec, runtime MCLK update based on the scaling factor > cannot be supported. This would mean that we will be having two methods to > specify "mclk-fs" factor, one from simple-card/audio-graph-card and one from > respective codec nodes, which does not seem ideal. Again I just can't follow what you're saying here at all. Again, if the card is able to set a clock API clock rate it can just as well set a clock rate via sysclk. > Yes this is a problem, unfortunately I missed checking some of the > simple-card examples. I wonder we should be specifically looking for "mclk" > clock here. That would definitely help mitigate the problem but I really think it's cleaner and safer to just push this down to set_sysclk().
Attachment:
signature.asc
Description: PGP signature
