Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio
 graph card
To:     Sebastian Reichel <sre@kernel.org>
CC:     Tony Lindgren <tony@atomide.com>,
        Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
        Mark Brown <broonie@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, <alsa-devel@alsa-project.org>,
        <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
        Aaro Koskinen <aaro.koskinen@iki.fi>,
        "Arthur D ." <spinal.by@gmail.com>,
        Jarkko Nikula <jarkko.nikula@bitmer.com>,
        Merlijn Wajer <merlijn@wizzup.org>, Pavel Machek <pavel@ucw.cz>
References: <20200211171645.41990-1-tony@atomide.com>
 <cd46c6ec-80e3-332f-4922-e58a3acbfc61@ti.com>
 <20200212143543.GI64767@atomide.com>
 <346dfd2b-23f8-87e0-6f45-27a5099b1066@ti.com>
 <20200214170322.GZ64767@atomide.com>
 <d9a43fcb-ed0f-5cd5-7e22-58924d571d17@ti.com>
 <20200217231001.GC35972@atomide.com>
 <5402eba8-4f84-0973-e11b-6ab2667ada85@ti.com>
 <20200218211631.fxojsxzvttoidfed@earth.universe>
From:   Peter Ujfalusi <peter.ujfalusi@ti.com>
Message-ID: <a263a857-bb8a-0e37-6932-dd07df98ad63@ti.com>
Date:   Thu, 20 Feb 2020 16:15:22 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20200218211631.fxojsxzvttoidfed@earth.universe>
Content-Type: text/plain; charset="windows-1252"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Sebastian,

On 18/02/2020 23.16, Sebastian Reichel wrote:
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
> 
> Your description matches my understanding of the hardware setup.
> 
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
>>
>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 	1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 	2.1: to CPCAP_voice
>> 	2.2: to WL1285
>> CPCAP: 2 ports
>> 	hifi:	3.1: to McBSP2
>> 	voice:	4.1: to McBSP3
>> 		4.2: to MDM6600
>> MDM6600: 2 ports
> 
> I suppose you mean 1 port, 2 endpoints?

Oh yes. Numbers....

> 
>> 	5.1: to CPAC_voice
>> 	5.2: to WL1285
>> WL1285: 2 ports
> 
> and here too?

here too ;)

> 
>> 	6.1: to McBSP3
>> 	6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
>>
>> Can a generic card provide such a functionality?
> 
> I suppose in the end its a question if generic card can provide TDM
> support.

Sure it can, but can it handle the switching between the paths based on
use cases?
There should be machine level DAPM widgets to kick codec2codec (MDM6600
- CPAC_voice for example) and also to make sure that when you switch
between them the system is not going to get misconfigured.
Switching between CPAC and BT route during call?
Not allowing VoIP while on call, etc.

>> In case of B/C you should not have a running stream imho.
> 
> I would expect, that MDM6600 codec marks itself as running/stopped
> based on call state. That should enable DAPM widgets automatically
> when CPCAP_voice is routed to MDM6600?
> 
>> In all cases CPCAP_voice should be able to run the clocks on i2s,
>> even if it is not used by the audio setup.
>> Not sure if you can just turn Wl1285 as master, but it is possible
>> that it is master, but silent when it is not used?
> 
> I provided CPCAP registers for BT call, which should be enough to
> figure this out (I did not yet analyze the results myself).

I got the datasheet from NXP (thanks for the pointer!), I try to look at
it in a coming days.

>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
> 
> Makes sense to me.
> 
> -- Sebastian
- P?ter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki