diff mbox

call/normal switch was Re: omap4-droid4: voice call support was

Message ID 20180331145531.GA10404@amd (mailing list archive)
State New, archived
Headers show

Commit Message

Pavel Machek March 31, 2018, 2:55 p.m. UTC
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...

If someone knows how to express cleanly "active support for modem is
the same as active audio playback", let me know....

Best regards,
								Pavel

Comments

Tony Lindgren March 31, 2018, 6:19 p.m. UTC | #1
* 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
Pavel Machek March 31, 2018, 7:19 p.m. UTC | #2
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
Pavel Machek March 31, 2018, 7:46 p.m. UTC | #3
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
Tony Lindgren March 31, 2018, 7:46 p.m. UTC | #4
* 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
Pavel Machek March 31, 2018, 7:55 p.m. UTC | #5
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
Tony Lindgren March 31, 2018, 11:43 p.m. UTC | #6
* 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
Pavel Machek April 1, 2018, 6:48 a.m. UTC | #7
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
Pavel Machek April 1, 2018, 1:18 p.m. UTC | #8
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
Tony Lindgren April 1, 2018, 3:36 p.m. UTC | #9
* 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 April 1, 2018, 5:30 p.m. UTC | #10
* 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
Tony Lindgren April 2, 2018, 3:57 p.m. UTC | #11
* 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 April 3, 2018, 3:04 p.m. UTC | #12
* 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
Pavel Machek April 3, 2018, 3:50 p.m. UTC | #13
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
Tony Lindgren April 3, 2018, 7:44 p.m. UTC | #14
* 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
Pavel Machek April 6, 2018, 12:04 p.m. UTC | #15
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
Merlijn Wajer April 6, 2018, 12:23 p.m. UTC | #16
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
Pavel Machek April 6, 2018, 12:45 p.m. UTC | #17
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
Pavel Machek April 6, 2018, 10:02 p.m. UTC | #18
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
Pavel Machek April 7, 2018, 8:10 a.m. UTC | #19
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
Pavel Machek April 7, 2018, 12:22 p.m. UTC | #20
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
Dan Williams April 8, 2018, 2:44 a.m. UTC | #21
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
Pavel Machek April 8, 2018, 7:41 a.m. UTC | #22
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
Dan Williams April 9, 2018, 3:15 a.m. UTC | #23
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
Tony Lindgren April 9, 2018, 2:08 p.m. UTC | #24
* 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
Dan Williams April 9, 2018, 3:53 p.m. UTC | #25
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
Pavel Machek April 9, 2018, 8:21 p.m. UTC | #26
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 mbox

Patch

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"},