On Thu, Sep 15, 2011 at 11:06:53PM +0000, Tabi Timur-B04825 wrote:
Mark Brown wrote:
This isn't what happens at all. The constraints set in the DAIs generally just list all the sample rates the device can possibly support, there's no dynamic information injected into the subsystem about what's supported. This is because in many systems the various clock rates are dynamically controlled and so the clocks are adjusted to reflect the sample rates the application layer wants.
IMHO, these two sentences contradict each other.
The first one says that the rates announced by the driver are the superset of all rates the device can ever support, the second says that this is done because the system can change the clock rate after we're done announcing what sample rates we support.
As a result we never actually bother specifying the supported rates for the current clock at all, we just try to make the best of what we're given when it comes to configuring which is a rather different thing.
But why would you do that? That just creates an artificial limitation on the list of supported sample rates. If you include a set_sysclk() function in the codec driver, then you should always specify SNDRV_PCM_RATE_CONTINUOUS in snd_soc_dai_driver.rates. To me, the two go hand-in-hand.
Devices, especially ones with lots of digital in them, often support a series of specific sample rates rather than a continuous range of sample rates. While you can of course configure them with other setups this will run them out of spec which may cause issues from poor performance up to serious audio issues or misdriving of outputs (eg, class D speaker drivers or things using charge pumps). Most of the time things will be OK but in general it seems better to try to stay within spec.
Fairly simple devices like the WM8776 which don't contain much digital are commonly supported over a continuous range of sample rates so _CONTINUOUS is suitable for them.