| Message ID | 20180331145531.GA10404@amd (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Pavel Machek <pavel@ucw.cz> [180331 14:56]: > Hi! > > > Hmm well I got audio call hacked to work as a proof of concept hack, > > see below. Maybe it can be used to verify some of the assumptions > > above. > > > > Then.. To split the work a bit, can you guys maybe try to decode > > the cpcap register values and try to do a proper ASoC driver patch? > > This is not proper patch yet, but it should be a step in that > direction... Cool :) Microphone still does not work for me.. I tried tweaking the alsamixer settings but no mic. This is with cold boot with droid4-kexecboot if that might make a difference, we may have some register uninitialized somewhere. Any ideas? FYI, I got one of the remaining n_gsm issues tracked down yesterday, at least one more bug to go. Things only work with n_gsm debug enabled right now for some reason.. Regards, Tony
On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [180331 14:56]: > > Hi! > > > > > Hmm well I got audio call hacked to work as a proof of concept hack, > > > see below. Maybe it can be used to verify some of the assumptions > > > above. > > > > > > Then.. To split the work a bit, can you guys maybe try to decode > > > the cpcap register values and try to do a proper ASoC driver patch? > > > > This is not proper patch yet, but it should be a step in that > > direction... > > Cool :) Microphone still does not work for me.. I tried tweaking > the alsamixer settings but no mic. This is with cold boot with > droid4-kexecboot if that might make a difference, we may have > some register uninitialized somewhere. Any ideas? Ok, I was focusing on the speaker side. alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 should work, according to my notes, but not recently tested and not tested against real human. I'll attempt to test it, but something in my userland shuts down system just after boot 60% of time, which is rather annoying. > FYI, I got one of the remaining n_gsm issues tracked down yesterday, > at least one more bug to go. Things only work with n_gsm debug > enabled right now for some reason.. I don't know why I need n_gsm, but I have my fingers crossed. :-). Pavel
On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [180331 14:56]: > > > Hi! > > > > > > > Hmm well I got audio call hacked to work as a proof of concept hack, > > > > see below. Maybe it can be used to verify some of the assumptions > > > > above. > > > > > > > > Then.. To split the work a bit, can you guys maybe try to decode > > > > the cpcap register values and try to do a proper ASoC driver patch? > > > > > > This is not proper patch yet, but it should be a step in that > > > direction... > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > the alsamixer settings but no mic. This is with cold boot with > > droid4-kexecboot if that might make a difference, we may have > > some register uninitialized somewhere. Any ideas? > > Ok, I was focusing on the speaker side. > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > should work, according to my notes, but not recently tested and not > tested against real human. > > I'll attempt to test it, but something in my userland shuts down > system just after boot 60% of time, which is rather annoying. Hmm. So I tried again, and setting Mic1 and back in the capture settings crashed the modem. Bang, disconnected from the USB. Pavel
* Pavel Machek <pavel@ucw.cz> [180331 19:21]: > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [180331 14:56]: > > > Hi! > > > > > > > Hmm well I got audio call hacked to work as a proof of concept hack, > > > > see below. Maybe it can be used to verify some of the assumptions > > > > above. > > > > > > > > Then.. To split the work a bit, can you guys maybe try to decode > > > > the cpcap register values and try to do a proper ASoC driver patch? > > > > > > This is not proper patch yet, but it should be a step in that > > > direction... > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > the alsamixer settings but no mic. This is with cold boot with > > droid4-kexecboot if that might make a difference, we may have > > some register uninitialized somewhere. Any ideas? > > Ok, I was focusing on the speaker side. > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > should work, according to my notes, but not recently tested and not > tested against real human. In alsamixer after setting the second "Speaker" to "Voice" and "Mode" to "Call" and "Left" to "Mic 2" and "Right" to "Mic 1" and doing a test call the mic does not work, speaker works though. After the call in alsamixer, setting the second "Speaker" to "HiFi", and "Mode" to "Normal" mode, I can record a wav file and play it back just fine. But this only works for me after reloading snd-soc-cpcap.ko after the voice call. > I'll attempt to test it, but something in my userland shuts down > system just after boot 60% of time, which is rather annoying. Hmm battery voltage too low? We have cpcap_battery_irq_thread() call orderly_poweroff() on lowbpl interrupt. > > FYI, I got one of the remaining n_gsm issues tracked down yesterday, > > at least one more bug to go. Things only work with n_gsm debug > > enabled right now for some reason.. > > I don't know why I need n_gsm, but I have my fingers crossed. :-). More features it seems :) But sounds like you're all set for now with USB access. Regards, Tony
On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > * Pavel Machek <pavel@ucw.cz> [180331 14:56]: > > > > Hi! > > > > > > > > > Hmm well I got audio call hacked to work as a proof of concept hack, > > > > > see below. Maybe it can be used to verify some of the assumptions > > > > > above. > > > > > > > > > > Then.. To split the work a bit, can you guys maybe try to decode > > > > > the cpcap register values and try to do a proper ASoC driver patch? > > > > > > > > This is not proper patch yet, but it should be a step in that > > > > direction... > > > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > the alsamixer settings but no mic. This is with cold boot with > > > droid4-kexecboot if that might make a difference, we may have > > > some register uninitialized somewhere. Any ideas? > > > > Ok, I was focusing on the speaker side. > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > should work, according to my notes, but not recently tested and not > > tested against real human. > > > > I'll attempt to test it, but something in my userland shuts down > > system just after boot 60% of time, which is rather annoying. > > Hmm. So I tried again, and setting Mic1 and back in the capture > settings crashed the modem. Bang, disconnected from the USB. Next try, and it worked this time. _Before the call_, set mode to Normal and then Call. Then go to capture, and set 100 100 Mic2 Mic1. Then place a call, AT+CFUN=1 OK ATD6; If you change Mic1 setting, GSM modem will likely crash. Good luck, Pavel
* Pavel Machek <pavel@ucw.cz> [180331 19:56]: > On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > > the alsamixer settings but no mic. This is with cold boot with > > > > droid4-kexecboot if that might make a difference, we may have > > > > some register uninitialized somewhere. Any ideas? > > > > > > Ok, I was focusing on the speaker side. > > > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > > should work, according to my notes, but not recently tested and not > > > tested against real human. > > > > > > I'll attempt to test it, but something in my userland shuts down > > > system just after boot 60% of time, which is rather annoying. > > > > Hmm. So I tried again, and setting Mic1 and back in the capture > > settings crashed the modem. Bang, disconnected from the USB. > > Next try, and it worked this time. > > _Before the call_, set mode to Normal and then Call. Then go to > capture, and set 100 100 Mic2 Mic1. Then place a call, > > AT+CFUN=1 > OK > ATD6; No luck with microphone here :( Using ttyUSB4, AT+CFUN=1 works, but ATD command on it just hangs the USB interface and I have to reload phy-mapphone-mdm6600 to reset the modem. > If you change Mic1 setting, GSM modem will likely crash. Have not seen that one here :) Regards, Tony
On Sat 2018-03-31 16:43:14, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [180331 19:56]: > > On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > > > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > > > the alsamixer settings but no mic. This is with cold boot with > > > > > droid4-kexecboot if that might make a difference, we may have > > > > > some register uninitialized somewhere. Any ideas? > > > > > > > > Ok, I was focusing on the speaker side. > > > > > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > > > should work, according to my notes, but not recently tested and not > > > > tested against real human. > > > > > > > > I'll attempt to test it, but something in my userland shuts down > > > > system just after boot 60% of time, which is rather annoying. > > > > > > Hmm. So I tried again, and setting Mic1 and back in the capture > > > settings crashed the modem. Bang, disconnected from the USB. > > > > Next try, and it worked this time. > > > > _Before the call_, set mode to Normal and then Call. Then go to > > capture, and set 100 100 Mic2 Mic1. Then place a call, > > > > AT+CFUN=1 > > OK > > ATD6; > > No luck with microphone here :( Using ttyUSB4, AT+CFUN=1 > works, but ATD command on it just hangs the USB interface > and I have to reload phy-mapphone-mdm6600 to reset the > modem. I realized where the difference is. I have ofonod running there, one from maemo leste distribution. It manages to talk to the modem somehow. I guess that accounts for the difference. I guess I should get it out of the picture.... Pavel
On Sat 2018-03-31 16:43:14, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [180331 19:56]: > > On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > > > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > > > the alsamixer settings but no mic. This is with cold boot with > > > > > droid4-kexecboot if that might make a difference, we may have > > > > > some register uninitialized somewhere. Any ideas? > > > > > > > > Ok, I was focusing on the speaker side. > > > > > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > > > should work, according to my notes, but not recently tested and not > > > > tested against real human. > > > > > > > > I'll attempt to test it, but something in my userland shuts down > > > > system just after boot 60% of time, which is rather annoying. > > > > > > Hmm. So I tried again, and setting Mic1 and back in the capture > > > settings crashed the modem. Bang, disconnected from the USB. > > > > Next try, and it worked this time. > > > > _Before the call_, set mode to Normal and then Call. Then go to > > capture, and set 100 100 Mic2 Mic1. Then place a call, > > > > AT+CFUN=1 > > OK > > ATD6; > > No luck with microphone here :( Using ttyUSB4, AT+CFUN=1 > works, but ATD command on it just hangs the USB interface > and I have to reload phy-mapphone-mdm6600 to reset the > modem. Test call with real human worked (thanks to Rolf K.), I could hear him well but he reported call was very quiet. And that was with capture settings at 100%. If you had a register dump from android with mics working, preferably not in speaker mode, perhaps I could try to figure it out? Pavel
* Pavel Machek <pavel@ucw.cz> [180401 13:20]: > On Sat 2018-03-31 16:43:14, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [180331 19:56]: > > > On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > > > > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > > > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > > > > the alsamixer settings but no mic. This is with cold boot with > > > > > > droid4-kexecboot if that might make a difference, we may have > > > > > > some register uninitialized somewhere. Any ideas? > > > > > > > > > > Ok, I was focusing on the speaker side. > > > > > > > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > > > > should work, according to my notes, but not recently tested and not > > > > > tested against real human. > > > > > > > > > > I'll attempt to test it, but something in my userland shuts down > > > > > system just after boot 60% of time, which is rather annoying. > > > > > > > > Hmm. So I tried again, and setting Mic1 and back in the capture > > > > settings crashed the modem. Bang, disconnected from the USB. > > > > > > Next try, and it worked this time. > > > > > > _Before the call_, set mode to Normal and then Call. Then go to > > > capture, and set 100 100 Mic2 Mic1. Then place a call, > > > > > > AT+CFUN=1 > > > OK > > > ATD6; > > > > No luck with microphone here :( Using ttyUSB4, AT+CFUN=1 > > works, but ATD command on it just hangs the USB interface > > and I have to reload phy-mapphone-mdm6600 to reset the > > modem. > > Test call with real human worked (thanks to Rolf K.), I could hear him > well but he reported call was very quiet. And that was with capture > settings at 100%. Maybe the volume also needs to be controlled at mdm6600 end. I'm seeing some AT+CLVL=n with n being between [0-7] calls on DLCI2 in my Android logcat logs. > If you had a register dump from android with mics working, preferably > not in speaker mode, perhaps I could try to figure it out? OK here are four diffs against starting the phone app for regular call, speaker call, and muted versions of them: http://muru.com/linux/d4/cpcap/ Also, I'm connected over cdma right now, not 3g, but I doubt that makes a difference for the microphone. Regards, Tony
* Tony Lindgren <tony@atomide.com> [180401 15:38]: > * Pavel Machek <pavel@ucw.cz> [180401 13:20]: > > On Sat 2018-03-31 16:43:14, Tony Lindgren wrote: > > > * Pavel Machek <pavel@ucw.cz> [180331 19:56]: > > > > On Sat 2018-03-31 21:46:16, Pavel Machek wrote: > > > > > On Sat 2018-03-31 21:19:39, Pavel Machek wrote: > > > > > > On Sat 2018-03-31 11:19:35, Tony Lindgren wrote: > > > > > > > Cool :) Microphone still does not work for me.. I tried tweaking > > > > > > > the alsamixer settings but no mic. This is with cold boot with > > > > > > > droid4-kexecboot if that might make a difference, we may have > > > > > > > some register uninitialized somewhere. Any ideas? > > > > > > > > > > > > Ok, I was focusing on the speaker side. > > > > > > > > > > > > alsamixer, tab to go to capture settings, set it to 37 37 Mic2 Mic1 > > > > > > should work, according to my notes, but not recently tested and not > > > > > > tested against real human. > > > > > > > > > > > > I'll attempt to test it, but something in my userland shuts down > > > > > > system just after boot 60% of time, which is rather annoying. > > > > > > > > > > Hmm. So I tried again, and setting Mic1 and back in the capture > > > > > settings crashed the modem. Bang, disconnected from the USB. > > > > > > > > Next try, and it worked this time. > > > > > > > > _Before the call_, set mode to Normal and then Call. Then go to > > > > capture, and set 100 100 Mic2 Mic1. Then place a call, > > > > > > > > AT+CFUN=1 > > > > OK > > > > ATD6; > > > > > > No luck with microphone here :( Using ttyUSB4, AT+CFUN=1 > > > works, but ATD command on it just hangs the USB interface > > > and I have to reload phy-mapphone-mdm6600 to reset the > > > modem. > > > > Test call with real human worked (thanks to Rolf K.), I could hear him > > well but he reported call was very quiet. And that was with capture > > settings at 100%. > > Maybe the volume also needs to be controlled at mdm6600 end. > I'm seeing some AT+CLVL=n with n being between [0-7] calls on > DLCI2 in my Android logcat logs. > > > If you had a register dump from android with mics working, preferably > > not in speaker mode, perhaps I could try to figure it out? > > OK here are four diffs against starting the phone app for regular > call, speaker call, and muted versions of them: > > http://muru.com/linux/d4/cpcap/ > > Also, I'm connected over cdma right now, not 3g, but I doubt > that makes a difference for the microphone. Found it! Here's what I need to do over n_gsm: ngsm 1 "AT+CFUN=1" ngsm 1 "AT+CFUN?" ngsm 2 "AT+EACC=3,0" # enable mic ngsm 2 "AT+CLVL=4" # set speaker volume ngsm 2 "AT+CMUT=0" # unmute mic ngsm 1 "ATD${number}" ngsm 1 "AT+CLCC" # list current calls ngsm 2 "AT+NREC=1" # enable noise cancellation ngsm 1 "AT+SCRN=0" # ??? not sure if this does anything while [ 1 ]; do date ngsm 1 "AT+CLCC" sleep 10 done So speaker phone call works just fine, I just tested with a human at the other end :) Hmm let's hope all those also translate to some qmi calls. Regards, Tony
* Dan Williams <dcbw@redhat.com> [180402 15:51]: > On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [180401 15:38]: > > Found it! Here's what I need to do over n_gsm: > > > > ngsm 1 "AT+CFUN=1" > > ngsm 1 "AT+CFUN?" > > ngsm 2 "AT+EACC=3,0" # enable mic > > ngsm 2 "AT+CLVL=4" # set speaker volume > > ngsm 2 "AT+CMUT=0" # unmute mic > > I tried to look through the QMI dumps we have in libqmi from 2013 > (latest Qualcomm posted) and couldn't find anything to do with mic > control, speaker volume, or anything like that. > > If the modem supports the AT service (which I think it does? Not > looking at the libqmi dumps right now) then it could potentially tunnel > these AT commands through QMI too. > > Perhaps Qualcomm added something to the Voice service after 2013, or > perhaps there are other services that might control speaker/mic that we > don't have public dumps for yet though. OK thanks for checking. So probably only n_gsm channel 1 is for normal Qualcomm at commands, and then channel 2 and others are commands implemented by Motorola on the mdm6600. I guess we'd have to add support for reading and writing to /dev/gsmtty2 at least as it looks like these cannot be accessed via /dev/ttyUSB4. Or at least I have not figured out any other way to access them. Regards, Tony
* Tony Lindgren <tony@atomide.com> [180402 15:59]: > * Dan Williams <dcbw@redhat.com> [180402 15:51]: > > On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote: > > > * Tony Lindgren <tony@atomide.com> [180401 15:38]: > > > Found it! Here's what I need to do over n_gsm: > > > > > > ngsm 1 "AT+CFUN=1" > > > ngsm 1 "AT+CFUN?" > > > ngsm 2 "AT+EACC=3,0" # enable mic > > > ngsm 2 "AT+CLVL=4" # set speaker volume > > > ngsm 2 "AT+CMUT=0" # unmute mic > > > > I tried to look through the QMI dumps we have in libqmi from 2013 > > (latest Qualcomm posted) and couldn't find anything to do with mic > > control, speaker volume, or anything like that. > > > > If the modem supports the AT service (which I think it does? Not > > looking at the libqmi dumps right now) then it could potentially tunnel > > these AT commands through QMI too. > > > > Perhaps Qualcomm added something to the Voice service after 2013, or > > perhaps there are other services that might control speaker/mic that we > > don't have public dumps for yet though. > > OK thanks for checking. So probably only n_gsm channel 1 is for normal > Qualcomm at commands, and then channel 2 and others are commands > implemented by Motorola on the mdm6600. > > I guess we'd have to add support for reading and writing to > /dev/gsmtty2 at least as it looks like these cannot be accessed > via /dev/ttyUSB4. Or at least I have not figured out any other > way to access them. Hmm or maybe there is some way to select where qmi to tunnels the AT commands to? Some kind of channel type paramenter like n_gsm has? Anyways, for trying to figure out things for alsamixer, I tested that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register settings and the mic is enabled during the call with Pavel's patch with alsamixer "Mode" set to either "Call" or "Normal". Also speaker keeps working during the call toggling between "Call" and "Normal". "Voice" in alsamixer does also control the speaker volume during the call. And setting the second "Speaker" from "Voice" to "HiFi" mutes the speaker. Then alsamixer capture settings for "Mic2" do change the mic gain as expected, and setting "Right" to "Off" mutes the mic. And then setting "Left" to "Mic 2" turns on the mic again. So my guess is that ngsm 2 "AT+EACC=3,0" and ngsm 2 "AT+CLVL=4" might control some external amp over the mdm6600 gpio pins? With "AT+CLVL" values being 0 7 it sounds like 3 gpios for that? Regards, Tony
Hi! > > OK thanks for checking. So probably only n_gsm channel 1 is for normal > > Qualcomm at commands, and then channel 2 and others are commands > > implemented by Motorola on the mdm6600. > > > > I guess we'd have to add support for reading and writing to > > /dev/gsmtty2 at least as it looks like these cannot be accessed > > via /dev/ttyUSB4. Or at least I have not figured out any other > > way to access them. > > Hmm or maybe there is some way to select where qmi to tunnels the > AT commands to? Some kind of channel type paramenter like n_gsm > has? > > Anyways, for trying to figure out things for alsamixer, I tested > that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register > settings and the mic is enabled during the call with Pavel's patch > with alsamixer "Mode" set to either "Call" or "Normal". Also speaker > keeps working during the call toggling between "Call" and "Normal". > "Voice" in alsamixer does also control the speaker volume during > the call. And setting the second "Speaker" from "Voice" to "HiFi" > mutes the speaker. Take a look at the patch. Selecting "call" does something at hardware level, selecting "normal" is a nop. Sorry for confusion. Yes, that patch needs more work. Pavel
* Pavel Machek <pavel@ucw.cz> [180403 15:51]: > Hi! > > > > OK thanks for checking. So probably only n_gsm channel 1 is for normal > > > Qualcomm at commands, and then channel 2 and others are commands > > > implemented by Motorola on the mdm6600. > > > > > > I guess we'd have to add support for reading and writing to > > > /dev/gsmtty2 at least as it looks like these cannot be accessed > > > via /dev/ttyUSB4. Or at least I have not figured out any other > > > way to access them. > > > > Hmm or maybe there is some way to select where qmi to tunnels the > > AT commands to? Some kind of channel type paramenter like n_gsm > > has? > > > > Anyways, for trying to figure out things for alsamixer, I tested > > that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register > > settings and the mic is enabled during the call with Pavel's patch > > with alsamixer "Mode" set to either "Call" or "Normal". Also speaker > > keeps working during the call toggling between "Call" and "Normal". > > "Voice" in alsamixer does also control the speaker volume during > > the call. And setting the second "Speaker" from "Voice" to "HiFi" > > mutes the speaker. > > Take a look at the patch. Selecting "call" does something at hardware > level, selecting "normal" is a nop. > > Sorry for confusion. > > Yes, that patch needs more work. OK that explains why the speaker keeps working then :) Regards, Tony
Hi!
> OK that explains why the speaker keeps working then :)
Ok, I pushed new version of unicsy_demo.
It now sends & receives sms and you can call & receive call. Tone from
linphone is used for incoming call. User interface and code is
slightly weird, as ofono was -- and still is -- meant as a backend.
Pavel
Hi, On 06/04/18 14:04, Pavel Machek wrote: > Hi! > >> OK that explains why the speaker keeps working then :) > > Ok, I pushed new version of unicsy_demo. > > It now sends & receives sms and you can call & receive call. Tone from > linphone is used for incoming call. User interface and code is > slightly weird, as ofono was -- and still is -- meant as a backend. Great news, can't wait to try it. Did you modify ofono beyond the patches you have already posted? And what version of ofono was that for? Cheers, Merlijn
On Fri 2018-04-06 14:23:46, Merlijn Wajer wrote: > Hi, > > On 06/04/18 14:04, Pavel Machek wrote: > > Hi! > > > >> OK that explains why the speaker keeps working then :) > > > > Ok, I pushed new version of unicsy_demo. > > > > It now sends & receives sms and you can call & receive call. Tone from > > linphone is used for incoming call. User interface and code is > > slightly weird, as ofono was -- and still is -- meant as a backend. > > Great news, can't wait to try it. > > Did you modify ofono beyond the patches you have already posted? And > what version of ofono was that for? Forget ofono for now. I modified ofone to issue at commands directly. It is .. a hack, but should be good enough for testing. Best regards, Pavel
On Fri 2018-04-06 14:23:46, Merlijn Wajer wrote: > Hi, > > On 06/04/18 14:04, Pavel Machek wrote: > > Hi! > > > >> OK that explains why the speaker keeps working then :) > > > > Ok, I pushed new version of unicsy_demo. > > > > It now sends & receives sms and you can call & receive call. Tone from > > linphone is used for incoming call. User interface and code is > > slightly weird, as ofono was -- and still is -- meant as a backend. > > Great news, can't wait to try it. Oh btw ... if you need any help just ask. unicsy_demo needs to be symlinked to /usr/share/unicsy. If you could make notes of any problems you encounter and any packages you'll need to install, that would be nice -- it would be good to create README with installation instructions. Good luck, Pavel
Hi! It seems qmicli can be used while unicsy_demo/ofone talks to the modem using the AT commands. So I could do: qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start-network=apn=internet.t-mobile.cz route del default sudo ifconfig wwan0 up dhclient wwan0 to get GPRS/UMTS connection. AT commands still work. Does anyone have any idea what to do to get the GPS to work? Pavel
On Sat 2018-04-07 10:10:00, Pavel Machek wrote: > Hi! > > It seems qmicli can be used while unicsy_demo/ofone talks to the modem > using the AT commands. > > So I could do: > > qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start-network=apn=internet.t-mobile.cz > route del default > sudo ifconfig wwan0 up > dhclient wwan0 > > to get GPRS/UMTS connection. AT commands still work. > > Does anyone have any idea what to do to get the GPS to work? Got that to work. I installed modemmanager -- unfortunately that claims ttyUSB4 so it breaks voice/sms -- but then mmcli -m 0 --enable mmcli -m 0 --location-enable-gps-nmea watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea ...can be used to get GPS data. Droid4 seems to have rather bad GPS, so you should probably put it near window for testing. Is there way to grab data from modemmanager and feed it to gpsd, so that normal applications can access gps? I don't see easy way. I tried --location-enable-gps-unmanaged , but that did not work for me. Is modemmanager enabling GPS, or is it talking to libqmi to do that? The code is quite confusing to me... Best regards, Pavel
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote: > On Sat 2018-04-07 10:10:00, Pavel Machek wrote: > > Hi! > > > > It seems qmicli can be used while unicsy_demo/ofone talks to the > > modem > > using the AT commands. > > > > So I could do: > > > > qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start- > > network=apn=internet.t-mobile.cz > > route del default > > sudo ifconfig wwan0 up > > dhclient wwan0 > > > > to get GPRS/UMTS connection. AT commands still work. > > > > Does anyone have any idea what to do to get the GPS to work? > > Got that to work. > > I installed modemmanager -- unfortunately that claims ttyUSB4 so it > breaks voice/sms -- but then It shouldn't break SMS since MM will do SMS via QMI, but yeah for now it'll break voice because that would happen via QMI too, and we haven't implemented voice for QMI yet. --help-messaging --help-sms Also available via D-Bus of course. > mmcli -m 0 --enable > mmcli -m 0 --location-enable-gps-nmea > watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea > > ...can be used to get GPS data. Droid4 seems to have rather bad GPS, > so you should probably put it near window for testing. > > Is there way to grab data from modemmanager and feed it to gpsd, so > that normal applications can access gps? I don't see easy way. > > I tried --location-enable-gps-unmanaged , but that did not work for > me. That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM). So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no. Doesn't --location-get-gps-nmea work for you? That will spit out the latest NMEA traces MM gets from the modem, if it supports NMEA. I believe --location-status will tell you what methods MM supports with the modem. Also available via D-Bus of course. > Is modemmanager enabling GPS, or is it talking to libqmi to do that? > The code is quite confusing to me... Yes. When the modem is driven with QMI, then all the data comes from QMI. For other modems (like Huawei HiLink and Gobi 1000) the enabling commands are done via AT on the main command port and then one of the TTYs starts spewing out NMEA. Dan
Hi! > > mmcli -m 0 --enable > > mmcli -m 0 --location-enable-gps-nmea > > watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea > > > > ...can be used to get GPS data. Droid4 seems to have rather bad GPS, > > so you should probably put it near window for testing. > > > > Is there way to grab data from modemmanager and feed it to gpsd, so > > that normal applications can access gps? I don't see easy way. > > > > I tried --location-enable-gps-unmanaged , but that did not work for > > me. > > That requires a TTY that would spit out the GPS data; in this mode MM > only sends the start/stop commands, and what comes out the GPS TTY is > undefined (at least by MM). > > So unless you know that one of the 6600's TTYs does GPS and in what > format it does GPS, then no. > > Doesn't --location-get-gps-nmea work for you? That will spit out the > latest NMEA traces MM gets from the modem, if it supports NMEA. I > believe --location-status will tell you what methods MM supports with > the modem. Yes, --location-get-gps-nmea works for me. I guess one way forward would be to implement --location-get-gps-nmea support for qmicli, and use that? Best regards, Pavel
On Sun, 2018-04-08 at 09:41 +0200, Pavel Machek wrote: > Hi! > > > > mmcli -m 0 --enable > > > mmcli -m 0 --location-enable-gps-nmea > > > watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea > > > > > > ...can be used to get GPS data. Droid4 seems to have rather bad > > > GPS, > > > so you should probably put it near window for testing. > > > > > > Is there way to grab data from modemmanager and feed it to gpsd, > > > so > > > that normal applications can access gps? I don't see easy way. > > > > > > I tried --location-enable-gps-unmanaged , but that did not work > > > for > > > me. > > > > That requires a TTY that would spit out the GPS data; in this mode > > MM > > only sends the start/stop commands, and what comes out the GPS TTY > > is > > undefined (at least by MM). > > > > So unless you know that one of the 6600's TTYs does GPS and in what > > format it does GPS, then no. > > > > Doesn't --location-get-gps-nmea work for you? That will spit out > > the > > latest NMEA traces MM gets from the modem, if it supports NMEA. I > > believe --location-status will tell you what methods MM supports > > with > > the modem. > > Yes, --location-get-gps-nmea works for me. > > I guess one way forward would be to implement --location-get-gps-nmea > support for qmicli, and use that? Yeah, libqmi already has the necessary bits but it's not plumbed through to qmicli. Note that qmicli is a straight interface to QMI and doesn't try to impose abstractions on anything, so you wouldn't get -- location-get-gps-nmea, but you'd instead be working directly with the QMI PDS (older) and/or LOC (newer) service commands. Dan
* Dan Williams <dcbw@redhat.com> [180408 02:46]: > On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote: > > I tried --location-enable-gps-unmanaged , but that did not work for > > me. > > That requires a TTY that would spit out the GPS data; in this mode MM > only sends the start/stop commands, and what comes out the GPS TTY is > undefined (at least by MM). > > So unless you know that one of the 6600's TTYs does GPS and in what > format it does GPS, then no. There should be a NMEA port within the unknown port range ttyUSB[123]. Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports? Regards, Tony
On Mon, 2018-04-09 at 07:08 -0700, Tony Lindgren wrote: > * Dan Williams <dcbw@redhat.com> [180408 02:46]: > > On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote: > > > I tried --location-enable-gps-unmanaged , but that did not work > > > for > > > me. > > > > That requires a TTY that would spit out the GPS data; in this mode > > MM > > only sends the start/stop commands, and what comes out the GPS TTY > > is > > undefined (at least by MM). > > > > So unless you know that one of the 6600's TTYs does GPS and in what > > format it does GPS, then no. > > There should be a NMEA port within the unknown port range > ttyUSB[123]. > > Is there some easy way to enable --location-enable-gps-unmanaged for > testing so I can check if GPS gets enabled for one of the ports? Not all modems support all of the ModemManager location options; -unmanaged is only for devices that support sending the data to a separate port and for which we know the commands to do that. It looks like QMI has a way to direct the output to a specific device: // Enum to describe QMI PDS Output Devices enum eQMIPDSOutputDevices:UINT8 { eQMIPDSOutputDevices_NoneDisabled = 0, eQMIPDSOutputDevices_USB = 1, eQMIPDSOutputDevices_UART1 = 2, eQMIPDSOutputDevices_UART2 = 3, eQMIPDSOutputDevices_SharedMemory = 4, }; so we could add support for that to libqmi and then to ModemManager, which could help implement --location-enable-gps-unmanaged on alternate ports. But what might be simpler is implementing something like the "QMI GPS proxy" that already exists, but for ModemManager or libqmi directly. That way you can use QMI and get known formatting of the output data, but proxy it to a normal-looking NMEA tty? Instead of trying to figure out which TTY/UART/etc the information comes out of for each specific device and somehow encoding that into the platform. We know what the QMI ports are already, that's easy. We don't know what all the TTYs are for every given modem and hardcoding that info somewhere is error- prone and hard to keep up with. Dan
On Mon 2018-04-09 07:08:47, Tony Lindgren wrote: > * Dan Williams <dcbw@redhat.com> [180408 02:46]: > > On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote: > > > I tried --location-enable-gps-unmanaged , but that did not work for > > > me. > > > > That requires a TTY that would spit out the GPS data; in this mode MM > > only sends the start/stop commands, and what comes out the GPS TTY is > > undefined (at least by MM). > > > > So unless you know that one of the 6600's TTYs does GPS and in what > > format it does GPS, then no. > > There should be a NMEA port within the unknown port range ttyUSB[123]. > > Is there some easy way to enable --location-enable-gps-unmanaged for > testing so I can check if GPS gets enabled for one of the ports? In the meantime, I got GPS to work :-). I modified qmicli to pipe NMEA data to stdout, which should be enough. But yes, directly exposing NMEA data on ttyGSM? would be even nicer. Thanks, Pavel
diff --git a/sound/soc/codecs/cpcap.c b/sound/soc/codecs/cpcap.c index 3b53bd0..7aaa4db 100644 --- a/sound/soc/codecs/cpcap.c +++ b/sound/soc/codecs/cpcap.c @@ -221,18 +221,18 @@ struct cpcap_reg_info { }; static const struct cpcap_reg_info cpcap_default_regs[] = { - { CPCAP_REG_CC, 0xFFFF, 0x0000 }, - { CPCAP_REG_CC, 0xFFFF, 0x0000 }, - { CPCAP_REG_CDI, 0xBFFF, 0x0000 }, + { CPCAP_REG_CC, 0xFFFF, 0x60cf }, + { CPCAP_REG_CDI, 0xBFFF, 0xae0a }, { CPCAP_REG_SDAC, 0x0FFF, 0x0000 }, { CPCAP_REG_SDACDI, 0x3FFF, 0x0000 }, - { CPCAP_REG_TXI, 0x0FDF, 0x0000 }, - { CPCAP_REG_TXMP, 0x0FFF, 0x0400 }, - { CPCAP_REG_RXOA, 0x01FF, 0x0000 }, - { CPCAP_REG_RXVC, 0xFF3C, 0x0000 }, - { CPCAP_REG_RXCOA, 0x07FF, 0x0000 }, - { CPCAP_REG_RXSDOA, 0x1FFF, 0x0000 }, + { CPCAP_REG_TXI, 0x0FFF, 0x0CC0 }, + { CPCAP_REG_TXMP, 0x0FFF, 0x0610 }, + { CPCAP_REG_RXOA, 0x01FF, 0x0006 }, + { CPCAP_REG_RXVC, 0xFF3C, 0x0B2C }, + { CPCAP_REG_RXCOA, 0x07FF, 0x0606 }, + { CPCAP_REG_RXSDOA, 0x1FFF, 0x0600 }, { CPCAP_REG_RXEPOA, 0x7FFF, 0x0000 }, + { CPCAP_REG_VAUDIOC, 0xFFFF, 0x0025 }, { CPCAP_REG_A2LA, BIT(CPCAP_BIT_A2_FREE_RUN), BIT(CPCAP_BIT_A2_FREE_RUN) }, }; @@ -330,6 +330,11 @@ static const char * const cpcap_in_left_mux_texts[] = { "Off", "Mic 2", "Ext Left" }; +static const char * const cpcap_mode_texts[] = { + "Normal", "Call" +}; + + /* * input muxes use unusual register layout, so that we need to use custom * getter/setter methods @@ -354,6 +359,8 @@ static SOC_ENUM_SINGLE_DECL(cpcap_hs_l_mux_enum, 0, 6, cpcap_out_mux_texts); static SOC_ENUM_SINGLE_DECL(cpcap_emu_l_mux_enum, 0, 7, cpcap_out_mux_texts); static SOC_ENUM_SINGLE_DECL(cpcap_emu_r_mux_enum, 0, 8, cpcap_out_mux_texts); +static SOC_ENUM_SINGLE_DECL(cpcap_mode_enum, 0, 9, cpcap_mode_texts); + static int cpcap_output_mux_get_enum(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -442,6 +449,86 @@ static int cpcap_output_mux_put_enum(struct snd_kcontrol *kcontrol, return 0; } +static int mode; + +static int cpcap_mode_get_enum(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol); + struct cpcap_audio *cpcap = snd_soc_codec_get_drvdata(codec); + struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; + int err; + + ucontrol->value.enumerated.item[0] = mode; + + return 0; +} + +static int cpcap_mode_put_enum(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_soc_dapm_kcontrol_codec(kcontrol); + struct cpcap_audio *cpcap = snd_soc_codec_get_drvdata(codec); + struct snd_soc_dapm_context *dapm = + snd_soc_dapm_kcontrol_dapm(kcontrol); + struct soc_enum *e = (struct soc_enum *)kcontrol->private_value; + unsigned int muxval = ucontrol->value.enumerated.item[0]; + unsigned int mask = BIT(e->shift_l); + int err; + + printk("Requested mode %d\n", muxval); + + mode = muxval; + + switch (muxval) { + case 1: + + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_VAUDIOC, + 0xffff, 0x0025); // OK + if (err) + goto out; + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_CC, + 0xffff, 0x60cf); // OK + if (err) + goto out; + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_CDI, + 0xffff, 0xae0a); // OK + if (err) + goto out; + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_TXI, + 0xffff, 0x0cc0); + if (err) + goto out; + + mask = 1 << CPCAP_BIT_PGA_CDC_EN | 0x200; + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_RXCOA, + mask, mask); + if (err) + printk("error #3\n"); + + mask = 1 << CPCAP_BIT_A2_LDSP_L_EN | 1 << CPCAP_BIT_A2_LDSP_R_EN; + err = regmap_update_bits(cpcap->regmap, CPCAP_REG_RXOA, + mask, mask); + if (err) + printk("error #2\n"); + + err = regmap_update_bits(cpcap->regmap, 0x814, + 0x0400, 0x0400); + if (err) + printk("error #1\n"); + + default: + break; + } + + // FIXME +// snd_soc_dapm_mux_update_power(dapm, kcontrol, muxval, e, NULL); + + return 0; +out: printk("Something failed\n"); + return -EINVAL; +} + static int cpcap_input_right_mux_get_enum(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { @@ -630,6 +717,11 @@ static const struct snd_kcontrol_new cpcap_earpiece_mux = SOC_DAPM_ENUM_EXT("Earpiece", cpcap_earpiece_mux_enum, cpcap_output_mux_get_enum, cpcap_output_mux_put_enum); +static const struct snd_kcontrol_new cpcap_mode = + SOC_DAPM_ENUM_EXT("Mode", cpcap_mode_enum, + cpcap_mode_get_enum, cpcap_mode_put_enum); + + static const struct snd_kcontrol_new cpcap_hifi_mono_mixer_controls[] = { SOC_DAPM_SINGLE("HiFi Mono Playback Switch", CPCAP_REG_RXSDOA, CPCAP_BIT_MONO_DAC1, 1, 0), @@ -771,6 +863,10 @@ static const struct snd_soc_dapm_widget cpcap_dapm_widgets[] = { SND_SOC_DAPM_MUX("EMU Left Playback Route", SND_SOC_NOPM, 0, 0, &cpcap_emu_left_mux), + + SND_SOC_DAPM_MUX("Mode", SND_SOC_NOPM, 0, 0, + &cpcap_mode), + /* Output Amplifier */ SND_SOC_DAPM_PGA("Earpiece PGA", CPCAP_REG_RXOA, CPCAP_BIT_A1_EAR_EN, 0, NULL, 0), @@ -816,6 +912,9 @@ static const struct snd_soc_dapm_route intercon[] = { {"Microphone 1 PGA", NULL, "VAUDIO"}, {"Microphone 2 PGA", NULL, "VAUDIO"}, + /* FIXME */ + {"Mode", NULL, "Voice TX"}, + /* Stream -> AIF */ {"HiFi RX", NULL, "HiFi Playback"}, {"Voice RX", NULL, "Voice Playback"},