* Denis Kenzior <denkenz@xxxxxxxxx> [181230 21:05]: > On 12/30/2018 02:24 PM, Tony Lindgren wrote: > > 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. I have not seen anything about IP over ts 27.010 on this one.. I'll play with it at some point to confirm. > > 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. OK thanks for explaining the use case. > 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. > > > - 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 :) > 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. 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. Regards, Tony
