Hi, On Tue, Feb 18, 2020 at 02:43:19PM +0200, Peter Ujfalusi wrote: > On 18/02/2020 1.10, Tony Lindgren wrote: > > * Peter Ujfalusi <peter.ujfalusi@xxxxxx> [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?) 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? > 5.1: to CPAC_voice > 5.2: to WL1285 > WL1285: 2 ports and 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. > 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'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 > >>>>>> 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
Attachment:
signature.asc
Description: PGP signature
