On Thu, Feb 18, 2010 at 10:10 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Feb 18, 2010 at 08:59:38PM +0900, jassi brar wrote:
On Thu, Feb 18, 2010 at 7:57 PM, Mark Brown IMO codecs should simply do as directed by the ASOC.
Right, but that doesn't mean that the device drivers can't do anything useful here - in terms of restrictions they can't do anything the hardware can't implmenent. Another example here is that startup function can set constraints based on the configuration of other running links if the hardware has any limitations in that regard (some will, some won't, and the limitations may not even be anything to do with audio in some designs).
Okay. Here's another perspective ... If a dai can have further parallel sub-configurations, perhaps it should be further divided into more dais. So, I see a snd_soc_dai as the simplest h/w unit in the system and presumably already fully exploited by the active dai_link i.e, none of its bits can be changed without disturbing the active stream. The number of shares should be transparent to a dai. If this assumption is valid please read on, otherwise correct me.
The set of {rate, sample size & format, channels} defines one active dai. The second stream sharing this dai can not change any of these parameters without spoiling the active playback/capture - we can allow this configuration overriding as a feature or prevent as a bug. I prefer latter. Since there isn't anything new to do now, the ASoC core can simply avoid calling hooks in drivers rather than having 50 drivers implement a check.