Re: Motorola motmdm support

[Denis Kenzior <denkenz@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3311 bytes --]

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