Motorola motmdm support

Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

Hi!

Motorola phones use "interesting" setup.

There's qmi and "normal" (but very buggy) AT interface on
them. Unfortunately that uses USB and uses too much power (which is a
problem on phone).

Plus there's /dev/motmdm1, motmdm3 and motmdm9, multiplexed over
serial line.

It uses subset of AT commands (good) with slightly modified
protocol... it says ":OK" instead of "OK" and puts ~ before
unsolicited messages.

Other major difference is that commands need to be sent to the right
device. It seems motmdm1 is for status and call control, and motmdm9
is for incoming sms.

I guess that right way to do this is to introduce
drivers/motorolamodem (or can we just have drivers/motorola?).

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Denis Kenzior]

Hi Pavel,

On 12/29/2018 03:49 AM, Pavel Machek wrote:
> Hi!
> 
> Motorola phones use "interesting" setup.
> 
> There's qmi and "normal" (but very buggy) AT interface on
> them. Unfortunately that uses USB and uses too much power (which is a
> problem on phone).
> 
> Plus there's /dev/motmdm1, motmdm3 and motmdm9, multiplexed over
> serial line.

Kernel 27.010 multiplexer or something else entirely?

> 
> It uses subset of AT commands (good) with slightly modified
> protocol... it says ":OK" instead of "OK" and puts ~ before
> unsolicited messages.

Funny

> 
> Other major difference is that commands need to be sent to the right
> device. It seems motmdm1 is for status and call control, and motmdm9
> is for incoming sms.
> 
> I guess that right way to do this is to introduce
> drivers/motorolamodem (or can we just have drivers/motorola?).
> 

For some weird historic reason we called the atom drivers and thus the 
subdirectory housing the relevant sources with the 'modem' suffix.  So I 
guess we should stick to that just to be consistent.

We can have a separate discussion on whether it makes sense to drop the 
'modem' suffix and what the implications are (probably none).  If we 
decide to drop the suffix, then we should/will do it for all drivers.

Regards,
-Denis

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1355 bytes --]

Hi!

And thanks for a quick replies.

> >There's qmi and "normal" (but very buggy) AT interface on
> >them. Unfortunately that uses USB and uses too much power (which is a
> >problem on phone).
> >
> >Plus there's /dev/motmdm1, motmdm3 and motmdm9, multiplexed over
> >serial line.
> 
> Kernel 27.010 multiplexer or something else entirely?

Kernel 27.010 multiplexer, AFAICT. Some of the endpoints are handled
in kernel (gps, audio mixer control).

> >Other major difference is that commands need to be sent to the right
> >device. It seems motmdm1 is for status and call control, and motmdm9
> >is for incoming sms.
> >
> >I guess that right way to do this is to introduce
> >drivers/motorolamodem (or can we just have drivers/motorola?).
> 
> For some weird historic reason we called the atom drivers and thus the
> subdirectory housing the relevant sources with the 'modem' suffix.  So I
> guess we should stick to that just to be consistent.

Ok.

One more question: I guess I'll need to implement this... Is there
another example of driver doing AT commands but on multiple file
descriptors? I could really use something to look at as a template.. 

Thanks,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Denis Kenzior]

Hi Pavel,

>> Kernel 27.010 multiplexer or something else entirely?
> 
> Kernel 27.010 multiplexer, AFAICT. Some of the endpoints are handled
> in kernel (gps, audio mixer control).
> 

Who sets up the multiplexer? Kernel?

It might make your job easier if the oFono driver itself invoked the 
necessary magic to setup the multiplexer and handed off the devices as 
needed.  We used to have a driver like this, but not sure if it ever 
made it upstream.

> 
> One more question: I guess I'll need to implement this... Is there
> another example of driver doing AT commands but on multiple file
> descriptors? I could really use something to look at as a template..

Any driver for a USB based device would be setup this way.  Each AT port 
is a separate file, e.g. ttyUSB1, ttyACM2, etc.  The discovery is done 
via udev.  See plugins/mbm.c or plugins/ublox.c or plugins/telit.c, etc.

Assuming you don't want to setup the multiplexer in oFono, then the only 
tricky part is the port setup.  udevng.c setup_serial_modem() assumes a 
single port, so you might need to add some extra logic to setup the 
ports via udev rules.

Alternatively, simply use a config file specific to your driver.  See 
for example how plugins/phonesim.c does this.

Or, if it is an extremely platform specific driver, then just hardcode 
it.  E.g. like plugins/calypso.c, which only works for the Freerunner.

Regards,
-Denis

Re: Motorola motmdm support

[Denis Kenzior]

Hi Tony,

>> It might make your job easier if the oFono driver itself invoked the
>> necessary magic to setup the multiplexer and handed off the devices as
>> needed.  We used to have a driver like this, but not sure if it ever made it
>> upstream.
> 
> Playing with ldattach and user space handling earlier this year did
> not work out good.. It needed app specific handling for the Motorola
> custom layer on top of ts 27.010, custom handling for all the devices
> such as GNSS and audio mixer, and did not work well with device
> specific power management. So let's not go back to that :)

You still need someone to send AT+CMUX, no?  And you most likely need to 
integrate power management into the telephony stack anyway.  As I 
mentioned, we had a driver like this that worked just fine.  oFono ended 
up using a user space MUX since most of the quality of life improvements 
to n_gsm came in much later.  If I was writing a new MUXed driver these 
days, I'd seriously consider using GSMIOC_SETCONF and GSMIOC_ENABLE_NET.

How does the audio mixer handling work?  Just some AT commands to setup 
the mixing parameters, or something more involved?

Some other things to consider:
- oFono expects / is designed to expect exclusive access to all the tty 
ports
- GNSS/GPS is intended to be handled via oFono LocationReporting API.  I 
would recommend integrating this as intended...

> 
>>> One more question: I guess I'll need to implement this... Is there
>>> another example of driver doing AT commands but on multiple file
>>> descriptors? I could really use something to look at as a template..
>>
>> Any driver for a USB based device would be setup this way.  Each AT port is
>> a separate file, e.g. ttyUSB1, ttyACM2, etc.  The discovery is done via
>> udev.  See plugins/mbm.c or plugins/ublox.c or plugins/telit.c, etc.
>>
>> Assuming you don't want to setup the multiplexer in oFono, then the only
>> tricky part is the port setup.  udevng.c setup_serial_modem() assumes a
>> single port, so you might need to add some extra logic to setup the ports
>> via udev rules.
> 
> We have network status data at /dev/motmdm1, outgoing SMS PDU device at
> /dev/motmdm3, incoming SMS PDU device at /dev/motmdm9 and so on for each
> ts 27.010 channel. At least incoming and outgoing SMS PDU devices could
> be considered as separate modems if that makes things easier?

No, that just makes things more difficult.

> 
>> Alternatively, simply use a config file specific to your driver.  See for
>> example how plugins/phonesim.c does this.
>>
>> Or, if it is an extremely platform specific driver, then just hardcode it.
>> E.g. like plugins/calypso.c, which only works for the Freerunner.
> 
> Just adding one more thing to consider: Looks like the modem handling for
> SMS PDU's needs to be specific to the nework. First the network needs to
> be detected, and then the GSM or CDMA handlers need to be used for sending
> and receiving SMS. After that things should get standard.. Looks like
> ofono has parsing for the different type SMS PDUs in src/*sms*.c :)
> 

There's no real functional CDMA support in oFono anyhow.  Given that 
most CDMA networks are about to be switched off, I don't know why you 
would bother?

Regards,
-Denis

Re: Motorola motmdm support

[Denis Kenzior]

Hi Tony,

On 12/30/2018 02:24 PM, Tony Lindgren wrote:
> * Denis Kenzior <denkenz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [181230 19:32]:
>> You still need someone to send AT+CMUX, no?  And you most likely need to
>> integrate power management into the telephony stack anyway.  As I mentioned,
>> we had a driver like this that worked just fine.  oFono ended up using a
>> user space MUX since most of the quality of life improvements to n_gsm came
>> in much later.  If I was writing a new MUXed driver these days, I'd
>> seriously consider using GSMIOC_SETCONF and GSMIOC_ENABLE_NET.
> 
> No need to type AT+CMUX or anything, things start in ts 27.010
> mode from the start for the hardware. Then the serdev driver
> layer handles doing GSMIOC_SETCONF.

Gotcha.  That makes things a bit easier.

> 
> I have not played with GSMIOC_ENABLE_NET, I thought that needed
> support on the modem side as well, but maybe not?
>

It requires the modem to support Raw IP.  Many (most?) AT command based 
modems do these days, no idea about your hardware.

> Would GSMIOC_ENABLE_NET make things easier from ofono
> point of view?

Depends on your definition of easier.  The real reason for 
GSMIOC_ENABLE_NET is speed/efficiency.  In a typical 27.010 / 27.007 
compliant modem you'd setup N logical AT command channels where N = 1 
(minimum, but can be more if you want) + max number of active contexts. 
Typically modems support 3+ of these.  Once a context is activated, 
you'd switch the channel into data mode via AT+CGDATA (e.g. for PPP or 
raw IP) and start shoving your network packets on that channel in the 
format chosen.

How are you handling data connections?  PPP? Or is there some other 
protocol to transfer packets back and forth?

>> - GNSS/GPS is intended to be handled via oFono LocationReporting API.  I
>> would recommend integrating this as intended...
> 
> We have a standard kernel GNSS API now :) And we have /dev/gnss0
> already working for droid 4.

That's great.  But I think my recommendation still stands.  You want GPS 
state to be synchronized with the overall modem state, etc...

> 
>> There's no real functional CDMA support in oFono anyhow.  Given that most
>> CDMA networks are about to be switched off, I don't know why you would
>> bother?
> 
> Hmm right, good point. Anyways that's how the SMS gets sent and
> received in the US for droid 4 currently.. The file I was looking at
> is src/cdma-sms.c and the only thing to do there is the PDU coding
> and encoding.

I believe the utilities you mention should be good enough to decode the 
basics.  I think someone has even tested these on a real network at some 
point.  But the people working on CDMA have not contributed since ~2011, 
so I have no idea about the state of that code.  I was considering 
removing it given that CDMA is essentially defunct (or will be in a few 
years).

Regards,
-Denis

Re: Motorola motmdm support

[Denis Kenzior]

Hi Tony,

>> How are you handling data connections?  PPP? Or is there some other protocol
>> to transfer packets back and forth?
> 
> All the data connections in this case are done using QMI over USB.
> 
> And that probably explains why I have not seen any data related
> stuff on ts 27.010.

Ew.  So is everything related to packet services is running over QMI?

When Pavel explained that he wanted to use the weird squiggly AT 
commands, I assumed you wanted to run the packet services over AT as well.

> 
>>>> - GNSS/GPS is intended to be handled via oFono LocationReporting API.  I
>>>> would recommend integrating this as intended...
>>>
>>> We have a standard kernel GNSS API now :) And we have /dev/gnss0
>>> already working for droid 4.
>>
>> That's great.  But I think my recommendation still stands.  You want GPS
>> state to be synchronized with the overall modem state, etc...
> 
> Hmm sounds like ofono would benefit from using /dev/gnss0 in the
> long run though. I guess the situation is similar to having
> multiple computer mouse drivers earlier with their own interfaces
> vs standard /dev/input :)

Yep, agreed.  I already tried to nudge Pavel to propose something.

> 
>> I believe the utilities you mention should be good enough to decode the
>> basics.  I think someone has even tested these on a real network at some
>> point.  But the people working on CDMA have not contributed since ~2011, so
>> I have no idea about the state of that code.  I was considering removing it
>> given that CDMA is essentially defunct (or will be in a few years).
> 
> OK, sounds like we might need the CDMA PDU features for few more
> years though.

That's fine, as long as someone is actually using these.  Right now it 
is unmaintained code.

> 
> Oh, I think I forgot to answer your question regarding PM,
> there's nothing that the user space needs to except to avoid
> polling the /dev/motmdm* devices unnecessarily. And to type
> AT+SCRN=0 on /dev/motmdm1 when no notifications for signal
> strength and network status are needed.
> 

Right, but since /dev/motmdm1 would in theory belong exclusively to 
oFono, you probably still need some way of sending the screen 'off' 
command.  So in effect you're integrating power management with the 
telephony stack.

Regards,
-Denis

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 2694 bytes --]

Hi!

> >>How are you handling data connections?  PPP? Or is there some other protocol
> >>to transfer packets back and forth?
> >
> >All the data connections in this case are done using QMI over USB.
> >
> >And that probably explains why I have not seen any data related
> >stuff on ts 27.010.
> 
> Ew.  So is everything related to packet services is running over QMI?
> 
> When Pavel explained that he wanted to use the weird squiggly AT commands, I
> assumed you wanted to run the packet services over AT as well.

No idea about packet data for now. I currently run them over
qmi... which means increased power consumption, I guess that's ok if
data are active.


> >>>>- GNSS/GPS is intended to be handled via oFono LocationReporting API.  I
> >>>>would recommend integrating this as intended...
> >>>
> >>>We have a standard kernel GNSS API now :) And we have /dev/gnss0
> >>>already working for droid 4.
> >>
> >>That's great.  But I think my recommendation still stands.  You want GPS
> >>state to be synchronized with the overall modem state, etc...
> >
> >Hmm sounds like ofono would benefit from using /dev/gnss0 in the
> >long run though. I guess the situation is similar to having
> >multiple computer mouse drivers earlier with their own interfaces
> >vs standard /dev/input :)
> 
> Yep, agreed.  I already tried to nudge Pavel to propose something.

?

I believe that kernel doing the multiplexing and "normal" /dev/gnss0
being available to userspace is actually very nice solution.

> >Oh, I think I forgot to answer your question regarding PM,
> >there's nothing that the user space needs to except to avoid
> >polling the /dev/motmdm* devices unnecessarily. And to type
> >AT+SCRN=0 on /dev/motmdm1 when no notifications for signal
> >strength and network status are needed.
> >
> 
> Right, but since /dev/motmdm1 would in theory belong exclusively to oFono,
> you probably still need some way of sending the screen 'off' command.  So in
> effect you're integrating power management with the telephony stack.

I don't understand. Display power management should be separate from
ofono?

Tony: are there expected to be differences between motmdm1 and other
ttys? It does not gatchat seems to work ok with ttyUSB4, but does not
quite behave with motmdm1. Are the settings like ctsrts and baudrates
used for something?

Plus, it seems has its own subsystem, so
this is needed:

+       udev_enumerate_add_match_subsystem(enumerate, "motmdm");

Best regards,

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1525 bytes --]

Hi!

> Oh, I think I forgot to answer your question regarding PM,
> there's nothing that the user space needs to except to avoid
> polling the /dev/motmdm* devices unnecessarily. And to type
> AT+SCRN=0 on /dev/motmdm1 when no notifications for signal
> strength and network status are needed.

Is it possible that epoll() does not work properly with /dev/motmdm*?
I am debugging weird problems with ofonod, and that would be an
explanation...

epoll.poll() should be returning list of file descriptors and if they
are ready. And it seems to work for ttyUSB4 but not for motmdm.

Hmm. And motmdm_cdev_poll() lacks EPOLLOUT() support, right? That
could explain things...

Best regards,
								Pavel

Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("/dev/ttyUSB4", "r+")
>>> f.write("AT\r\n")
>>>
>>> import select
>>> epoll = select.epoll()
>>> epoll.register(1, select.EPOLLOUT)
>>> epoll.register(f.fileno(), select.EPOLLOUT | select.EPOLLIN)
>>> epoll.poll(1)
[(1, 4), (3, 5)]
>>> select.EPOLLOUT
4
>>> select.EPOLLIN
1
>>> f = open("/dev/motmdm1", "r+")
>>> #f = open("/dev/ttyUSB4", "r+")
... f.write("AT\r\n")
>>>
>>> import select
>>> epoll = select.epoll()
>>> epoll.register(1, select.EPOLLOUT)
>>> epoll.register(f.fileno(), select.EPOLLOUT | select.EPOLLIN)
>>> epoll.poll(1)
[(1, 4)]
>>>


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 2582 bytes --]

On Mon 2018-12-31 14:23:29, Tony Lindgren wrote:
> * Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org> [181231 21:54]:
> > Is it possible that epoll() does not work properly with /dev/motmdm*?
> > I am debugging weird problems with ofonod, and that would be an
> > explanation...
> > 
> > epoll.poll() should be returning list of file descriptors and if they
> > are ready. And it seems to work for ttyUSB4 but not for motmdm.
> > 
> > Hmm. And motmdm_cdev_poll() lacks EPOLLOUT() support, right? That
> > could explain things...
> 
> Hmm yeah maybe.
> 
> FYI, I just pushed a test script into github droid4-sms-tools repo
> for sending SMS and a related kernel fix for ctrl-z termination
> into k.o droid4-pending-mdm-v4.20 branch.
> 
> But that seems to fix a different issue from what you're seeing.

Yes, I can easily work around the problem like this:

It needs huge fixme there, but if you could include it... "always
ready" is better than "never ready".

I'm currently adding code to ofono... I can decode incoming
SMS. Current is here. https://github.com/pavelmachek/ofono

Have you figured out how the incoming calls are supposed to work? I'm
getting this on incoming call:

ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+CIEV=1,4,0\n\r
ignoring line
ofonod[2534]: Voice: < ~+CLIP="+420xxxxxxxxx",1,1,"",0,"",0\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+CIEV=1,0,0\n\r
ignoring line

ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r
ignoring line
ofonod[2534]: Voice: < ~+WAKEUP\n\r

I probably could use +CLIP as "there's incoming call", but I don't see
anything useful when I hang up and phone should stop ringing. 

Best regards,
								Pavel


diff --git a/drivers/mfd/motorola-mdm.c b/drivers/mfd/motorola-mdm.c
index 2cdc9e8..abf58e3 100644
--- a/drivers/mfd/motorola-mdm.c
+++ b/drivers/mfd/motorola-mdm.c
@@ -706,6 +706,7 @@ static __poll_t motmdm_cdev_poll(struct file *file, poll_table *wait)
 		mask |= EPOLLIN | EPOLLRDNORM;
 	if (cdata->disconnected)
 		mask |= EPOLLHUP;
+	mask |= (EPOLLOUT | EPOLLWRNORM);
 
 	return mask;
 }

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1415 bytes --]

Hi!

> > > But that seems to fix a different issue from what you're seeing.
> > 
> > Yes, I can easily work around the problem like this:
> > 
> > It needs huge fixme there, but if you could include it... "always
> > ready" is better than "never ready".
> 
> OK I'll take a look when I get a chance. I think all we need
> to do there is check that cdata->write_offset < cdata->write_buf_sz.

Makes sense. And you probably need to wake up userspace when buffer
was full and free space appears.

> > Have you figured out how the incoming calls are supposed to work? I'm
> > getting this on incoming call:
...
> > ofonod[2534]: Voice: < ~+CIEV=1,4,0\n\r
> > ignoring line
> > ofonod[2534]: Voice: < ~+CLIP="+420xxxxxxxxx",1,1,"",0,"",0\n\r
> > ignoring line

> > I probably could use +CLIP as "there's incoming call", but I don't see
> > anything useful when I hang up and phone should stop ringing. 
> 
> Parsing the number(s) from +CIEV should tell that, see what
> I added to motmdm_read_state().

+CIEV is documented as "indicator event". I can make ofono parse that,
but it will be ... slightly hacky.

Is there "RING" or something like that going on any of the interfaces?

BTW does 5.0-rc1 boot for you?

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Motorola motmdm support

[Pavel Machek]

[-- Attachment #1.1.1: Type: text/plain, Size: 863 bytes --]

Hi!

> Motorola phones use "interesting" setup.
> 
> There's qmi and "normal" (but very buggy) AT interface on
> them. Unfortunately that uses USB and uses too much power (which is a
> problem on phone).
> 
> Plus there's /dev/motmdm1, motmdm3 and motmdm9, multiplexed over
> serial line.
> 
> It uses subset of AT commands (good) with slightly modified
> protocol... it says ":OK" instead of "OK" and puts ~ before
> unsolicited messages.

Ok, turns out the setup is not that unusual, calypso also uses few
different channels.

This is where I got so far; yes, I'm probably doing everything wrong,
but hey, at least motmdm1 is detected and in some cases I even get
status messages...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.1.2: delme2.gz --]
[-- Type: application/gzip, Size: 6021 bytes --]

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]