On Tue, Feb 23, 2010 at 02:45:47PM +0900, jassi brar wrote:
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.
That doesn't map too well to hardware - it's relatively rare for devices to require complete symmetry between the playback and capture portions of the device, though often there are some constraints. Usually there is sufficient overlap in the hardware and documentation to describe them as a single interface but not so much as to force the same configuration for playback and record.
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.
If we were to go down this route it'd mean changing the existing drivers to split their DAIs, which seems like a lot of work and doesn't save us from having to implement the constraints that do exist. This would be pretty invasive and I can't clearly see if either approach gives much of a win in itself.
It seems easier to approach this by providing ways for drivers to communicate common constraints to the core with things like flags. That'd at least mean less change for existing code.