[PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card

[Peter Ujfalusi]

Hi Tony,

On 18/02/2020 1.10, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi at ti.com> [200217 12:10]:
>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>> and everything happens betwee the modem and the cpcap pmic.
>>
>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>> or McPDM...
>>
>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
> 
> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
> mcbsp for voice call.
> 
> According to Sebastian sounds like mcbsp can be idle at that point.
> 
> But what about capture of voice call at the mcbsp from the
> TDM slot? In that case mcbsp would be active.

Sure, but with the dummy dai it won't....

If I understand correctly the HW setup:
McBSP2 -> CPCAP_hifi (only playback)

CPCAP_voice is the i2s clock master.
McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
i2s lines.

In case of Voice call with analog mic/speaker only CPCAP_voice and
MDM6600 is used.
In case of Voice call with BT only MDM6600 and WL1285 is used (but
CPCAP_voice must provide the clocks?)
In case you would have any algorithm running on OMAP4 for the calls,
then you will have McBSP3 inserted and used between MDM6600 and
CPAC_voice/WL1285.
Similarly, if you would like to tap in and record the data from the bus
you will have McBSP3 enabled.

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?)

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
	5.1: to CPAC_voice
	5.2: to WL1285
WL1285: 2 ports
	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?
In case of B/C you should not have a running stream imho.
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'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).

> 
>>>>>> I know it was discussed, but can not find the mail:
>>>>>> Can you brief again on the audio connection?
>>>>>
>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>> the audio connection:
>>>>>
>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>
>>>> Thanks!
>>>>  
>>>>>> Do you have branch with working code?
>>>>>
>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>> kernel.org git branch with voice calls working.
>>>>
>>>> I think I should put my droid4 out and try to get it working...
>>>> Do you have a link for dummies to follow to get started? ;)
>>>
>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>> test image using v5.5 kernel + modem and audio patches:
>>>
>>> https://leste.maemo.org/Motorola_Droid_4
>>>
>>> Just use a decent speed micro-sd card rated "a1" for example.
>>
>> Cool. Now I can dual boot the droid4 :D
>> I needed to rewrite the /etc/shadow to get a known root password so I
>> can log in.
> 
> Not sure if you mean password for the droid4-kexecboot or the
> Linux distro you installed..

It was for the maemo-leste.
Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
reference image...

> But for droid4-kexecboot, you
> can configure it to automatically download new kernels over wlan.
> There's some info on the machine specific password and how to
> configure wlan in the droid4-kexecboot buildroot commits here:
> 
> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
> 
>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>> the /boot/boot/boot.cfg to boot my kernel, right?
> 
> Yeah you can update kernels and modules over wlan from the distro(s)
> you have configured, and also from droid4-kexecboot as above.

I need to try droid4-kexecboot's wifi support then.

> And note that kexecboot looks for a boot/boot.cfg file to use on
> every usable parition it finds and uses all the found entries
> based on the priority configured for the boot.cfg entry.

OK, thanks!

> 
> Regards,
> 
> Tony
> 

- Péter

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