On Thu, 2013-07-25 at 13:48 +0100, Mark Brown wrote:
On Thu, Jul 25, 2013 at 02:24:54PM +0200, Daniel Mack wrote:
On 23.07.2013 20:30, Mark Brown wrote:
The prefix mechanism is intended to address this; however it's only currently supported for CODECs. If we move the prefixes to components then they should be usable for CPU DAIs.
But that's a static string as well. How can we distiguish between two Codecs of the same type, or two McASP instances?
The point is to give a different prefix to each device; giving the same prefix to different devices rather defeats the poinnt.
I don't think we had any issues with DAI global naming on OMAP4 (we were probably just lucky I guess). We had several physical McBSP and several logical McPDM interfaces that were used by the ABE and they were globally connected in the machine driver using the DAI device name e.g. "omap-mcbsp.1"
Fwiw, I've just looked at Peter's topic/ti-audio-next-bnw-wip branch at gitorious.org:omap-audio/linux-audio.git and can see we may be missing a couple of patches that can affect the DAI connections i.e. 35f485c300d514225710af4a436c987b15b9b690. These are not required for DPCM on Haswell (where I connect to DAIs SSP0 and SSP1) and were written before Mark upstreamed the CODEC<->CODEC work which also supported widget DAI connections. It may be that some of these patches are still required for some configurations. Peter, you may be able to drop some of these patches since CODEC<->CODEC provides similar DAI widget functionality.
We probably have to address the local/global context for widget naming as Mark suggests. I guess that the global context will only apply to the machine driver whilst the local context will only be used for component drivers. This may just mean some changes for machine drivers in the way we connect to component driver widgets.
Liam