From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH 00/14] SPDIF support Date: Mon, 2 Sep 2013 17:59:33 +0100 Message-ID: <20130902165932.GZ6617@n2100.arm.linux.org.uk> References: <20130901123433.GR6617@n2100.arm.linux.org.uk> <20130902140632.GQ3084@sirena.org.uk> <20130902141631.GV6617@n2100.arm.linux.org.uk> <20130902162729.GT3084@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from caramon.arm.linux.org.uk (caramon.arm.linux.org.uk [78.32.30.218]) by alsa0.perex.cz (Postfix) with ESMTP id 454022651EC for ; Mon, 2 Sep 2013 18:59:52 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20130902162729.GT3084@sirena.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: Thomas Petazzoni , Andrew Lunn , alsa-devel@alsa-project.org, Lars-Peter Clausen , Jason Cooper , Jean-Francois Moine , Takashi Iwai , Liam Girdwood , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth List-Id: alsa-devel@alsa-project.org On Mon, Sep 02, 2013 at 05:27:29PM +0100, Mark Brown wrote: > On Mon, Sep 02, 2013 at 03:16:31PM +0100, Russell King - ARM Linux wrote: > > On Mon, Sep 02, 2013 at 03:06:32PM +0100, Mark Brown wrote: > > > > Yes, and this is one of the reasons for suggesting getting either/or > > > support merged - it will help things like the binding definition > > > progress (as well as being useful for any users with a S/PDIF only > > > system). > > > Sorry, but I believe the exact opposite: > > > 1. The DAI link binding created for a dual-DAI driver is completely > > different from the DAI link binding for a DPCM driver. The dual > > DAI link binding will have to be completely rewritten when the > > driver is converted to DPCM. > > That seems like overstating the difficulties. The updates for any new > S/PDIF drivers will be pretty much the same as those for the existing > I2S drivers and should just be mechanical changes, nothing too taxing. Sorry, you need to explain more. Here's the dual-DAI version: .name = "S/PDIF1", .stream_name = "IEC958 Playback", .platform_name = "mvebu-audio.1", .cpu_dai_name = "kirkwood-spdif.1", .codec_dai_name = "dit-hifi", .codec_name = "spdif-dit", Here's the DPCM version: { .name = "S/PDIF1", .stream_name = "Audio Playback", .platform_name = "mvebu-audio.1", .cpu_dai_name = "mvebu-audio.1", .codec_name = "snd-soc-dummy", .codec_dai_name = "snd-soc-dummy-dai", .dynamic = 1, }, { .name = "Codec", .stream_name = "IEC958 Playback", .cpu_dai_name = "snd-soc-dummy-dai", .platform_name = "snd-soc-dummy", .no_pcm = 1, .codec_dai_name = "dit-hifi", .codec_name = "spdif-dit", }, The above are two completely different beasts. Please explain how the DT representation for those DAI links can be the same. > > 2. When the driver is converted to DPCM, it must use DPCM for > > everything, otherwise it has no way to know which of SPDIF or I2S to > > enable. The only way I know to work around that is to add additional > > routes to link up the AIF widgets, and that's the solution you're all > > telling me is not acceptable, as per the patch set at the start of > > this thread. > > What we have been telling you is that if there is a DAI link present > (there should be one for each physical DAI link) then this should be > enough information for the framework to know that the two DAIs are > linked and if any routes are needed in DAPM these should be added > automatically in the same way that we add links for CODEC<->CODEC links > at present. > > It's been said to you off-list that having the links manually added > but marking them for removal when the framework figures out how to do > that should be OK. Sorry, I just don't get this. What you seem to be telling me here is to forget DPCM, and just go with the dual DAI solution. If I have separate CPU DAI links, then I can't do simultaneous operation, because both DAI links are entirely separate entities which are activated entirely separately. The only way I know how to handle this is with the patch set I've already posted. We've been through this before: this is also not how Liam's example DPCM driver works - please go back and look at those diagrams I drew you of how Liam's driver is setup. I've also said to you that from what I can see, the routes are still required for DPCM - those routes are in Liam's DPCM driver as well.