Message ID | 20200430174615.41185-1-tony@atomide.com |
---|---|
Headers | show |
Series | n_gsm serdev support and GNSS driver for droid4 | expand |
> My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. I tried to get it to work... it was not fun and I did not get far. I pushed my results... user@devuan:/my/ofono$ git push Counting objects: 10, done. Delta compression using up to 2 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 1.17 KiB | 0 bytes/s, done. Total 10 (delta 8), reused 0 (delta 0) remote: Resolving deltas: 100% (8/8), completed with 8 local objects. To github.com:pavelmachek/ofono.git fd34ca20..9042014b mux-v1.29-1 -> mux-v1.29-1 Best regards, Pavel ofonod[12922]: drivers/atmodem/network-registration.c:at_netreg_probe() Probing creg Have command of length 9 (AT+CREG=?) or ^z ofonod[12922]: Voice: > U0000AT+FOO\r ofonod[12922]: InSMS: > U0000AT+FOO\r ofonod[12922]: OutSMS: > U0000AT+FOO\r ofonod[12922]: Voice: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() handle command response ofonod[12922]: Voice: > U0000AT+SCRN=0\r ofonod[12922]: OutSMS: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() handle command response ofonod[12922]: InSMS: < U0000+FOO:ERROR=9\n new bytes 18 Have line: U0000+FOO:ERROR=9 Last character is 13 command response: U0000+FOO:ERROR=9 ofonod[12922]: plugins/motmdm.c:foo_cb() ofonod[12922]: plugins/motmdm.c:foo_cb() All channels working handle command response ofonod[12922]: Voice: < U0000+SCRN:OK\n new bytes 14 Have line: U0000+SCRN:OK Last character is 13 command response: U0000+SCRN:OK ofonod[12922]: plugins/motmdm.c:scrn_cb() handle command response ofonod[12922]: Voice: > U0000AT+CFUN=1\r ofonod[12922]: Voice: < U0000+CFUN:OK\n new bytes 14 Have line: U0000+CFUN:OK Last character is 13 command response: U0000+CFUN:OK ofonod[12922]: plugins/motmdm.c:cfun_cb() handle command response ofonod[12922]: Voice: > U0000AT+CLIP=1\r ofonod[12922]: Voice: < U0000+CLIP:OK\n new bytes 14 Have line: U0000+CLIP:OK Last character is 13 command response: U0000+CLIP:OK handle command response ofonod[12922]: Voice: > U0000AT+CCWA=1\r ofonod[12922]: Voice: < U0000+CCWA:OK\n new bytes 14 Have line: U0000+CCWA:OK Last character is 13 command response: U0000+CCWA:OK ofonod[12922]: drivers/motorolamodem/voicecall.c:motorola_voicecall_initialized() voicecall_init: registering to notifications
Hi! > Now without the chardev support, the /dev/gsmtty* using apps need > to use "U1234AT+CFUN?" format for the packets. The advantage is > less kernel code, and we keep the existing /dev/gsmtty* interface. Actually... yes, this works. But no, this is not "existing" tty interface. ttys work per character, and this interface definitely does not... it is "packet" based, write() syscalls need exactly right lengths. You can't just open minicom, and type "U1234...". You can't paste it, either (I tried). tty controls like start/stop bits and baud rate are useless here. CR/LF conversions are unwanted/dangerous because it is confusing hard to debug if you get them wrong. Now, I don't see reason why this could not be made to work, and it may be more important to have something in mainline and work with that. So if you can make this into -next, I'll not complain too loudly. But it is... still wrong and I liked motmdm* more :-). Best regards, Pavel
* Pavel Machek <pavel@denx.de> [200501 08:22]: > Hi! > > > Now without the chardev support, the /dev/gsmtty* using apps need > > to use "U1234AT+CFUN?" format for the packets. The advantage is > > less kernel code, and we keep the existing /dev/gsmtty* interface. > > Actually... yes, this works. But no, this is not "existing" tty > interface. > > ttys work per character, and this interface definitely does not... it > is "packet" based, write() syscalls need exactly right lengths. You > can't just open minicom, and type "U1234...". You can't paste it, > either (I tried). tty controls like start/stop bits and baud rate are > useless here. CR/LF conversions are unwanted/dangerous because it is > confusing hard to debug if you get them wrong. Yes.. That's what n_gsm spins up. > Now, I don't see reason why this could not be made to work, and it may > be more important to have something in mainline and work with that. So > if you can make this into -next, I'll not complain too loudly. But it > is... still wrong and I liked motmdm* more :-). Yes.. There are issues too with the motmdm* char dev interface too. I don't think it would work as is for devices with network interfaces on some channel, and continuation packets could need more handling possibly. But let's try to get the basics sorted out first and use the "raw" gsmtty* interface. More stuff can always be added later as needed. Regards, Tony
* Pavel Machek <pavel@denx.de> [200430 22:27]: > > > My guess is that at least with the pending ofono patches, we just > > want to use the raw interface for /dev/gsmtty* interface and stop > > pretending we have a modem that is AT compatible. > > I tried to get it to work... it was not fun and I did not get far. OK. Yeah it's now 2020 and still dealing with serial port stuff :) > I pushed my results... > > user@devuan:/my/ofono$ git push > Counting objects: 10, done. > Delta compression using up to 2 threads. > Compressing objects: 100% (10/10), done. > Writing objects: 100% (10/10), 1.17 KiB | 0 bytes/s, done. > Total 10 (delta 8), reused 0 (delta 0) > remote: Resolving deltas: 100% (8/8), completed with 8 local objects. > To github.com:pavelmachek/ofono.git > fd34ca20..9042014b mux-v1.29-1 -> mux-v1.29-1 OK :) I still need to update the ALSA related patches on top of this $subject series. Also what I've noticed is that modprobe n_gsm debug=0xff hex output is currently broken since commit 091cb0994edd ("lib/hexdump: make print_hex_dump_bytes() a nop on !DEBUG builds"). Reverting the commit fixes it. Stephen, any ideas what should be changed to fix it? Regards, Tony
Hi! > My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. Ok, so I got ofono back to work. ... I believe. It was not that bad. SMS send/receive and outgoing call start/hangup worked at some point (I did not play with mixers). To github.com:pavelmachek/ofono.git 61d3d727..195760e9 mux-v1.29-1 -> mux-v1.29-1 Best regards, Pavel
Hi! > Now without the chardev support, the /dev/gsmtty* using apps need > to use "U1234AT+CFUN?" format for the packets. The advantage is > less kernel code, and we keep the existing /dev/gsmtty* interface. > > If we still really need the custom chardev support, that can now > be added as needed with the channel specific consumer driver(s). > > My guess is that at least with the pending ofono patches, we just > want to use the raw interface for /dev/gsmtty* interface and stop > pretending we have a modem that is AT compatible. The series: Tested-by: Pavel Machek <pavel@ucw.cz>
Hi! > We can make use of serdev drivers to do simple device drivers for > TS 27.010 chanels, and we can handle vendor specific protocols on top > of TS 27.010 with serdev drivers. > > So far this has been tested with Motorola droid4 where there is a custom > packet numbering protocol on top of TS 27.010 for the MDM6600 modem. > > I initially though about adding the serdev support into a separate file, > but that will take some refactoring of n_gsm.c. And I'd like to have > things working first. Then later on we might want to consider splitting > n_gsm.c into three pieces for core, tty and serdev parts. And then maybe > the serdev related parts can be just moved to live under something like > drivers/tty/serdev/protocol/ngsm.c. > > Signed-off-by: Tony Lindgren <tony@atomide.com> If you fix error path below, you can add: Reviewed-by: Pavel Machek <pavel@ucw.cz> > +static struct gsm_dlci *gsd_dlci_get(struct gsm_serdev *gsd, int line, > + bool allocate) > +{ > + struct gsm_mux *gsm; > + struct gsm_dlci *dlci; > + > + if (!gsd || !gsd->gsm) > + return ERR_PTR(-ENODEV); > + > + gsm = gsd->gsm; > + > + if (line < 1 || line >= 63) > + return ERR_PTR(-EINVAL); > + > + mutex_lock(&gsm->mutex); ... > + dlci = gsm_dlci_alloc(gsm, line); > + if (!dlci) { > + gsm = ERR_PTR(-ENOMEM); > + goto unlock; dlci = , or you get nice crash. Best regards, Pavel
* Pavel Machek <pavel@denx.de> [200501 20:20]: > Hi! > > > My guess is that at least with the pending ofono patches, we just > > want to use the raw interface for /dev/gsmtty* interface and stop > > pretending we have a modem that is AT compatible. > > Ok, so I got ofono back to work. ... I believe. It was not that > bad. SMS send/receive and outgoing call start/hangup worked at some > point (I did not play with mixers). > > To github.com:pavelmachek/ofono.git > 61d3d727..195760e9 mux-v1.29-1 -> mux-v1.29-1 OK good to hear and thanks for doing it. Regards, Tony
Hi! > We can have a generic serdev-ngsm driver bring up the TS 27.010 line > discipline on the selected serial ports based on device tree data. > > And we can now do standard Linux device driver for the dedicated > TS 27.010 channels for devices like GNSS and ALSA found on modems. > +++ b/drivers/tty/serdev/Kconfig > @@ -22,4 +22,14 @@ config SERIAL_DEV_CTRL_TTYPORT > depends on SERIAL_DEV_BUS != m > default y > > +config SERIAL_DEV_N_GSM > + tristate "Serial device TS 27.010 support" > + help > + Select this if you want to use the TS 27.010 with a serial port with > + devices such as modems and GNSS devices. > + > + If unsure, say N. > + depends on N_GSM > + depends on SERIAL_DEV_CTRL_TTYPORT Normally, depends go after "tristate" and before "help" text. I did not realize this is valid code. Reviewed-by: Pavel Machek <pavel@ucw.cz> > +/* > + * Configure SoC 8250 device for 700 ms autosuspend delay, Values around 600 ms > + * and shorter cause spurious wake-up events at least on droid 4. Also keep the droid->Droid? > +static const struct serdev_ngsm_cfg motmdm_cfg = { > + .gsm = &adaption1, > + .init_retry_quirk = true, > + .needs_usb_phy = true, > + .aggressive_pm = true, Umm. These are unsigned int:1, not bools, so = 1 would be expected here. Best regards, Pavel
On Thu 2020-04-30 10:46:14, Tony Lindgren wrote: > Motorola is using a custom TS 27.010 based serial port line discipline > for various devices on the modem. These devices can be accessed on > dedicated channels using Linux kernel serdev-ngsm driver. > > For the GNSS on these devices, we need to kick the GNSS device at a > desired rate. Otherwise the GNSS device stops sending data after a > few minutes. The rate we poll data defaults to 1000 ms, and can be > specified with a module option rate_ms between 1 to 16 seconds. > > Note that AGPS with xtra2.bin is not yet supported, so getting a fix > can take quite a while. And a recent gpsd is needed to parse the > $GNGNS output, and to properly handle the /dev/gnss0 character device. > I've confirmed it works properly with gpsd-3.20. > > Signed-off-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Pavel Machek <pavel@ucw.cz>
On Thu 2020-04-30 10:46:15, Tony Lindgren wrote: > Let's enable the TS 27.010 /dev/gsmmux* interfaces via Linux n_gsm that > can be used for voice calls and SMS with commands using a custom Motorola > format. > > And let's also enable the kernel GNSS driver via serdev-ngsm that uses a > dedicated TS 27.010 channel. > > Note that voice call audio mixer is not supported yet. > > Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Pavel Machek <pavel@ucw.cz>
* Pavel Machek <pavel@denx.de> [200501 20:32]: > > +static struct gsm_dlci *gsd_dlci_get(struct gsm_serdev *gsd, int line, > > + bool allocate) > > +{ > > + struct gsm_mux *gsm; > > + struct gsm_dlci *dlci; > > + > > + if (!gsd || !gsd->gsm) > > + return ERR_PTR(-ENODEV); > > + > > + gsm = gsd->gsm; > > + > > + if (line < 1 || line >= 63) > > + return ERR_PTR(-EINVAL); > > + > > + mutex_lock(&gsm->mutex); > ... > > + dlci = gsm_dlci_alloc(gsm, line); > > + if (!dlci) { > > + gsm = ERR_PTR(-ENOMEM); > > + goto unlock; > > dlci = , or you get nice crash. Ah thanks yeah we return dlci and need to set dlci instead: if (!dlci) { dlci = ERR_PTR(-ENOMEM); goto unlock; } Regards, Tony
On Fri 2020-05-01 07:52:52, Tony Lindgren wrote: > * Pavel Machek <pavel@denx.de> [200430 22:27]: > > > > > My guess is that at least with the pending ofono patches, we just > > > want to use the raw interface for /dev/gsmtty* interface and stop > > > pretending we have a modem that is AT compatible. > > > > I tried to get it to work... it was not fun and I did not get far. > > OK. Yeah it's now 2020 and still dealing with serial port stuff :) Yeah, and scary thing is... it is 2020 and serial port is _still_ complex and hard to understand and debug :-). > OK :) I still need to update the ALSA related patches on top > of this $subject series. Let me know when you have these. Pavel