Hi Mark,
On 12/03/2014 01:28, Mark Brown wrote:
On Tue, Mar 11, 2014 at 12:17:24PM +0100, Benoit Cousson wrote:
From: Misael Lopez Cruz misael.lopez@ti.com
DAI link assumes a one to one mapping between CPU DAI and CODEC. In some cases, the same CPU DAI can be connected to several codecs. This is the case for example, if you connect two mono codecs to the same I2S link in order to have a stereo card. The current ASoC implementation does not allow such setup.
First up thanks for working on this, it's a feature which has been requested for a long time but nobody stepped forward to do it before now.
This is rather large so I've not had time to review it today, I'll try to get at least a first pass at that done tomorrow. I did notice that in your comment about rebasing you mentioned a series - it'd be good if we could see this as a series, splitting it up would make review easier.
Yeah, I know. The issue is that the original series was done on a 3.8 Android branch with few refactor patches before that one to introduce some helpers. During the 3.8 -> 3.13 rebase then 3.13 -> 3.14 rebase, a lot of them did not survive due to internal asoc changes and cleanups that happened since 3.8.
At least, there are still few helpers that can be introduced sooner, but it will still make the main patch pretty huge. I don't think we can make the transition in smaller chunks.
CPU DAI in a multicodec DAI link can have more channels than what each CODEC has. The number of channels each CODEC is responsible for is machine specific, hence it's fixed up in machine drivers in a similar way to what DPCM does.
This one is interesting. It feels like most things will want a static mapping because that's what the hardware does but there will doubtless be things that could use flexibility. Liam has looked at this in the past (more for TDM IIRC, I thought about it for that as well and I seem to recall Liam's ideas covering it). It feels like we should start out with static mappings and build up dynamic later on but equally well getting something merged would mean we could improve on it.
The patch is based on 3.14-rc6.
For such an invasive set of changes it's probably worth working off -next, I forsee conflicts.
Indeed, I've just tried rebasing it on asoc/next and it does conflict :-( But not a major conflict anyway. I'll do that for the repost.
Thanks for the comments, Benoit