On 09/16/2011 06:34 PM, Timur Tabi wrote:
Lars-Peter Clausen wrote:
You mentioned in an earlyer mail that you can switch the sysclk rate at runtime. So setting the constraints based on the current sysclk rate won't really work. I think you need some mechanism to specify the supported rates on a per machine driver basis.
Exactly. There are some other problems with getting the dynamic sysclk feature working. On the board where this is supported, the same clock is connected to adcmclk and dacmclk, so I can't support playback at 48KHz and capture at 44.1KHz. However, there's nothing stopping a customer from creating a board that has two independent clocks.
So in the meantime, I'd really just like the ability to specify in the codec driver's .startup function exactly which sample rates are supported (based on the current mclk).
You can already do this. Though you'd limit your CODEC driver to the use-case where only one fixed sysclk is used. This might be a problem if other people were using the same CODEC and want to use it without this limitation.
Machine drivers are currently best placed to set constraints if the clocking is limited.
But how is the machine driver supposed to know what those sample rates are? >
It would need to know how which dividers that codec uses. That would mean
that the machine driver has to be hard-codec with information on the internals of the codec.
How do you know which sysclk rate to select for a given sample rate, if you don't know the samples rates the CODEC can produces for a given sysclk rate?
So ideally the CODEC driver would have callback which you could pass a set of sysclk ranges the machine driver can supply and the CODEC driver would return a list of sample rates it can support for this sysclk rate range. And then you could use this updated list in your machine driver to decide which sysclk rate to select. But I'm not sure if this isn't to over-engineered and hard-coding this table into the machine driver wouldn't be better.