From mboxrd@z Thu Jan  1 00:00:00 1970
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Subject: Re: About ASoC DAIs cleanup
Date: Thu, 21 Dec 2017 01:28:09 +0000
Message-ID: <87o9msc1zk.wl%kuninori.morimoto.gx@renesas.com>
References: <87shciup8e.wl%kuninori.morimoto.gx@renesas.com>
 <87r2s2uo55.wl%kuninori.morimoto.gx@renesas.com>
 <87o9n6ukyg.wl%kuninori.morimoto.gx@renesas.com>
 <87r2rzqf1q.wl%kuninori.morimoto.gx@renesas.com>
 <20171213155952.GL6416@sirena.org.uk>
 <87wp1qow1q.wl%kuninori.morimoto.gx@renesas.com>
 <20171214050648.GU18649@localhost>
 <20171214113718.GB9788@sirena.org.uk>
 <20171215042053.GA18649@localhost>
 <87mv2grdqm.wl%kuninori.morimoto.gx@renesas.com>
 <20171219112302.GI8563@sirena.org.uk>
Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <alsa-devel-bounces@alsa-project.org>
Received: from relmlie3.idc.renesas.com (relmlor4.renesas.com
 [210.160.252.174])
 by alsa0.perex.cz (Postfix) with ESMTP id ED1C7266E3A
 for <alsa-devel@alsa-project.org>; Thu, 21 Dec 2017 02:28:16 +0100 (CET)
In-Reply-To: <20171219112302.GI8563@sirena.org.uk>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/options/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel/>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Errors-To: alsa-devel-bounces@alsa-project.org
Sender: alsa-devel-bounces@alsa-project.org
To: Mark Brown <broonie@kernel.org>
Cc: Vinod Koul <vinod.koul@intel.com>, Linux-ALSA <alsa-devel@alsa-project.org>, Lars-Peter <lars@metafoo.de>, Shreyas NC <shreyas.nc@intel.com>
List-Id: alsa-devel@alsa-project.org


Hi Mark

Thank you for sharing ideas

> > 	for_each_dais(dai, xxx) {
> > 		if(!dai->peripheral)
> > 			/* non Peripheral == CPU portion */
> > 
> > 		if(dai->peripheral)
> > 			/* Peripheral == Codec portion */
> > 	}
> 
> > But what do you think about this idea/naming etc ?
> > I want to investigate more about Codec <-> Codec connection,
> > which driver is using it ? Especially CPU portion
> 
> I'm thinking it might be better to keep the list ordered in the DAI link
> - that will scale up better with multi-drop links.  What's going to be a
> bit more tricky sometimes is working out which end of the link is a CPU
> DAI but we can probably take a good guess easily enough on order neutral
> bindings and things liken simple-card already know explicitly.

If my understanding was correct, we can call all DAIs
by one for_each loop with controllable order on your idea.
This is nice.
But, callback order will be exchanged ?
For example soc_pcm_trigger() case, .trigger callback order currently is

	Codec DAI -> Component(Platform) -> CPU DAI -> RTD

it will be

	all ordered DAIs -> Component(Platform) -> RTD

Codec / CPU callback order are OK, but DAI / Component order is exchanged.
If this is not a big problem, we can do it.

And one issue I noticed.
If we merged all Codec/CPU DAI into one DAI list, and without
flags (like .peripheral flag), current DAI master/slave direction will be problem.
At least snd_soc_runtime_set_dai_fmt() is switching it for Codec <-> Codec case.
If we can change current SND_SOC_DAIFMT_CBx_CFx style to
xx_MASTER / xx_SLAVE style on each DAIs, this can be no problem I think.
I guess Lars is thinking about it ?

Best regards
---
Kuninori Morimoto