On Sat, Aug 10, 2013 at 05:11:23PM +0100, Russell King - ARM Linux wrote:
It would appear that the problem is that the AIF widgets are not finding their stream - the implicit routes are not being created. It _appears_ that the strean name in widgets are only ever connected to the streams within the same DAPM context.
That shouldn't be the case in general - DAPM binds first to a widget in the local context for disambiguation and then falls back to a search of the gobal context. However it is possible that you've got an ordering issue during registration.
So, it's because the capture isn't wired up. The capture isn't wired up on this platform, so how do I tell ASoC not to bother with the capture side with DPCM? Creating a link for the capture side to the dummy codec is wrong, because that allows capture to be brought up when in fact there is no capture wired up on the board (and means that we'll end up trying to use unconnected inputs.)
What I'd expect to happen is that the wiring for the SoC internal bits can be there since it physically is there but we don't generate anything that userspace can see unless we also provide a back end it can be wired up to. We probably need to fill that bit in though since I don't think anyone ever tried to use this stuff on a unidirectional system before.
but doesn't stop those warnings (not really surprising, because it isn't the card level which is being complained about). Probably the easiest way to stop that appearing is to just disable OSS compatibility.
That's something which should be documented until it is fixed - that DPCM is currently incompatible with OSS.
That's not likely to ever be supported even if anyone cared, very few ASoC drivers will work with OSS due to the very poor mapping between OSS parameter configuration and ALSA parameter configuration.
So, there are two issues which still need resolving:
- The registration of Codec widgets from the platform introduced by Liam in be09ad90e17b79fdb0d513a31e814ff4d42e3dff ASoC: core: Add platform DAI widget mapping
Well, that patch isn't visibly doing anything with CODECs - it's acting on the CPU and platform, not on the CODECs. I think what's happening there is that if you've got the same device for the DAI and platform then the widgets will be created twice, once by the DAI and once by the platform. The current code is fine if they're separate devices but will fail if they are the same device.
We just need to make the DAPM context per device I think, possibly as part of moving over to components (based on the work that Morimoto-san started) though we could do it without that.
- How to deal with disconnected front end streams which have no backend provided by their connected codec (in this case, front end can do capture and playback, back end can only do playback.)
Like I say I think we should just not be complaining if there's no capture back end available. Probably just checking if there's any at all is good enough for realistic uses.