| freemangordon | Wizzup: ok :) | 10:55 |
|---|---|---|
| Wizzup | :D | 10:59 |
| mkfz | hello | 15:18 |
| mkfz | there is a store nearby me which sells n900 phones | 15:18 |
| mkfz | these are however locked, can I buy them and get rid of password? | 15:19 |
| inky | i think you just reflash | 15:47 |
| mkfz | is there anything I need to consider or check before I buy? | 15:51 |
| sicelo | modem works, usb port works | 15:56 |
| tmlind | freemangordon: maybe ofono can directly access the gsm dlcs on /dev/ttyS0, see g_at_mux_new_gsm0710_basic() | 16:12 |
| Wizzup | mkfz: I think just modem and usb yeah, lock should not be a problem | 16:41 |
| freemangordon | tmlind: the question was - can kernel do something in a way that there is no need of served_ngsm | 16:55 |
| freemangordon | ofono does not need anything tty now it uses qmi | 16:56 |
| freemangordon | so, can snd soc or phy driver open /dev/ttyS0 and set line discipline on it | 16:57 |
| freemangordon | *serdev_ngsm that is | 16:57 |
| freemangordon | or, upstreaming serdev_ngsm is the only proper way | 16:59 |
| tmlind | well the uart wakeups do not matter much any longer with usb qmi working if it's just the audio | 17:28 |
| tmlind | afaik serdev is the way to build serial port device drivers, otherwise it would have to be user space | 17:29 |
| freemangordon | ok, but can;t we do the same in kernel as in userspace: | 17:29 |
| freemangordon | open ttyS0, set line discipline to n_gsm, etc | 17:29 |
| freemangordon | I don;t think we shall drop support for uart wakeups, but would prefer if we can get away without upstreaming serdev_ngsm, given that I am not sure I'll manager to upstream it | 17:34 |
| freemangordon | *manage | 17:34 |
| tmlind | yeah it's a pain to fix up for upstreaming.. | 17:35 |
| freemangordon | so, I saw at least 2 drivers that open tty devices, in upstream | 17:35 |
| tmlind | so if ofono handled it, we still need to coordinate with the asoc driver with daemon i think sicelo mentioned earlier | 17:35 |
| freemangordon | hmm, I missed that | 17:36 |
| tmlind | i doubt a sound driver doing tty_set_ldisc() would be liked much.. | 17:36 |
| freemangordon | no, that would be the phy | 17:36 |
| tmlind | phy? | 17:37 |
| freemangordon | yeah, why not? | 17:37 |
| freemangordon | I mean: phy will set line discipline on ttyS0 | 17:37 |
| tmlind | well it's the opening of the ports part still that's going to be messy | 17:37 |
| freemangordon | and than soc will open ttyGSM2 (or whatever is the correct tty for audio contol) | 17:37 |
| freemangordon | *and then | 17:38 |
| tmlind | much cleaner if ofono sets the voice call volume with some daemon coordinating the asoc settings imo :) | 17:38 |
| Wizzup | might be worth to see what asoc folks think | 17:39 |
| tmlind | sure | 17:39 |
| freemangordon | this is out of my knowledge | 17:39 |
| Wizzup | if it's in alsa then it'll be easier for the rest of userspace | 17:39 |
| freemangordon | lemme find what upstream does ATM in terms of opening tty devices | 17:40 |
| tmlind | then it makes sense to implement it with serdev and we've seen that it goes nowhere | 17:40 |
| freemangordon | this https://elixir.bootlin.com/linux/v6.12.5/source/drivers/leds/trigger/ledtrig-tty.c#L222 | 17:41 |
| freemangordon | and https://elixir.bootlin.com/linux/v6.12.5/source/drivers/accessibility/speakup/spk_ttyio.c#L154 | 17:42 |
| freemangordon | why would not we do something similar? | 17:42 |
| tmlind | well i think the idea of serdev is to deal with that kind of stuff using a generic layer | 17:43 |
| freemangordon | sure, that's clear, but upstream does not seem happy with it | 17:44 |
| freemangordon | or, do they expect anything else to happen? | 17:44 |
| tmlind | it's just too much to deal with at least for me | 17:45 |
| tmlind | infinite bugs and changes needed | 17:45 |
| freemangordon | Imagine how would I be in that situation, given your experience with kernel ;) | 17:46 |
| tmlind | sicelo: what was the audio daemon helper thingy you mentioned earlier? | 17:46 |
| tmlind | well the n_gsm is in a better shape now after siemens has been patching it, but still feels like a big mess | 17:47 |
| freemangordon | right, but we have fixes fro it too | 17:48 |
| freemangordon | I will send | 17:48 |
| tmlind | ok | 17:48 |
| freemangordon | however, do you know what is needed for seredev to go upstream? | 17:48 |
| freemangordon | *serdev | 17:48 |
| freemangordon | I saw series v5 was sent, and then nothing, perhaps I missed it | 17:49 |
| tmlind | johan had a bunch of good comments on it if you search on lore | 17:49 |
| tmlind | changing the functions to be more serdev like was one, then moving stuff around | 17:50 |
| tmlind | i think he suggested that the dlcis are treated as serdev subdevices or something like that | 17:50 |
| tmlind | anyways, i feel it's a waste of time if we don't need it for anything beyond setting voice call volume and mute | 17:51 |
| freemangordon | ans switching streams | 17:51 |
| freemangordon | *and | 17:51 |
| tmlind | no, that's in the asoc driver for the mcbsp | 17:51 |
| tmlind | i think also the bluetooth would be just an asoc driver still | 17:52 |
| freemangordon | no, I think voice strams swithing is done through modem | 17:52 |
| freemangordon | *streams | 17:52 |
| tmlind | oh right to set it to be the master | 17:52 |
| freemangordon | p, li { white-space: pre-wrap; } AT+EACC | 17:52 |
| freemangordon | this is still needed IIUC | 17:53 |
| tmlind | yeah | 17:53 |
| freemangordon | so this, noise cancellation, mute and volume | 17:54 |
| tmlind | yup | 17:54 |
| freemangordon | I think this is better done on alsa | 17:54 |
| freemangordon | did you have a look at the links I pasted ^^^ | 17:54 |
| freemangordon | upstream drivers opening ttys | 17:55 |
| tmlind | very old drivers though? | 17:55 |
| freemangordon | no idea | 17:55 |
| freemangordon | lemme check | 17:55 |
| freemangordon | not really | 17:56 |
| freemangordon | Wed Jan 13 18:30:18 2021 | 17:56 |
| freemangordon | fd4a641ac88fbbaf8b90e00823397597a287cfcd | 17:56 |
| tmlind | ok | 17:57 |
| tmlind | so did you get the gps stuff working over usb qmi? | 17:57 |
| freemangordon | yes | 17:57 |
| freemangordon | at least you and sicelo said that data looks like gps data :) | 17:58 |
| tmlind | then if we can claim that no other drivers need to use ttyS0 it might be justified.. | 17:58 |
| freemangordon | umm, but we'll expose ttyGSMn to userspace | 17:58 |
| tmlind | you should test outside or near a window and see if you get a gps fix after 10 to 20 minutes | 17:58 |
| freemangordon | so GPS tty will still be accessible | 17:59 |
| tmlind | hmm so how would drivers/gnss access it? | 17:59 |
| freemangordon | tty_open_shared? | 17:59 |
| freemangordon | I am not sure what gnss diver is doing ATM, honestly | 18:00 |
| tmlind | hmm ok so maybe that would work | 18:00 |
| tmlind | it's custom at commands on a separate dlci | 18:00 |
| tmlind | so your plan is to have the phy driver set up the line discipline, then have drivers do tty_open_shared()? | 18:01 |
| freemangordon | yes | 18:01 |
| freemangordon | well.. plan | 18:01 |
| freemangordon | idea | 18:01 |
| tmlind | worth a test imo, that would leave out all the serdev ngsm hassles | 18:01 |
| freemangordon | mhm | 18:01 |
| freemangordon | even if upstream reject it, that will be way easier to maintain too | 18:02 |
| freemangordon | as out-of-tree patch | 18:02 |
| tmlind | yeah for sure | 18:02 |
| freemangordon | and for gps I think we shall use ofono either ways | 18:02 |
| freemangordon | because qmi works most of devices we care, besides n900 | 18:03 |
| freemangordon | I have no idea if gps works with leste on n900 | 18:03 |
| tmlind | i guess ofono could create some socket for gpsd to use | 18:04 |
| freemangordon | that's what it does, provides fd to read from | 18:04 |
| freemangordon | and you read | 18:04 |
| tmlind | ok great | 18:04 |
| freemangordon | nmea data | 18:04 |
| tmlind | so gpsd can already use it? | 18:05 |
| freemangordon | https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/location-reporting-api.txt | 18:05 |
| freemangordon | in theory | 18:05 |
| tmlind | cool | 18:05 |
| freemangordon | I guess we'll have to fix some bugs in ofono(I already have a patch to send) but those are details | 18:06 |
| freemangordon | and Denis seems very nice and cooperative guy | 18:06 |
| freemangordon | he accepts patches almost instantly | 18:06 |
| tmlind | yup that's great | 18:06 |
| freemangordon | mhm | 18:07 |
| freemangordon | ok, se the plan is: I will try to make snd soc stuff work without serdev_ngsm | 18:07 |
| freemangordon | will report once I have result :) | 18:07 |
| tmlind | there should be a way to enable gps on ttyUSB0, 1, 2, 3 btw, probably just some nvram setting but unknown | 18:07 |
| freemangordon | ttyUSB4 accept +CMUX=0 | 18:08 |
| tmlind | but does it switch to gsm mode? | 18:08 |
| freemangordon | yes | 18:08 |
| freemangordon | I tried | 18:08 |
| tmlind | oh ok | 18:08 |
| freemangordon | using cmux (or some other tool, lemme try to re-find it) | 18:08 |
| tmlind | if you get it to gsm mode, dlci7 can be used to echo back what you write, at least on ttyS0 | 18:09 |
| freemangordon | https://github.com/Rtone/cmux | 18:09 |
| freemangordon | had to change init sequence a bit, but.... | 18:09 |
| freemangordon | and then I got this ULXXX headers | 18:10 |
| freemangordon | or DL, whatever | 18:10 |
| tmlind | i also made some userspace gsm tool before i went with the serdev stuff because of the wake-up events needed | 18:10 |
| freemangordon | the proprietary motorola framing | 18:10 |
| tmlind | ah right | 18:10 |
| freemangordon | well, I don;t see why shall we drop wake-ups | 18:11 |
| tmlind | you can ignore the motorola header and start all writes with U1234 | 18:11 |
| freemangordon | my gut feeling tells me that without them wi might have stability issues in long run | 18:11 |
| freemangordon | *we | 18:11 |
| tmlind | well the wakeups are now implemented in the phy driver | 18:11 |
| freemangordon | like, overfilling some modem internal buffer/queue | 18:11 |
| freemangordon | right | 18:12 |
| tmlind | if your audio device driver is a child of the phy, it will wake up the parent phy driver with pm_runtime_get() | 18:12 |
| freemangordon | mhm | 18:12 |
| freemangordon | I understand that | 18:12 |
| tmlind | ok | 18:13 |
| freemangordon | I think I will keep the current DT structure initially, DT is not my strongest skill | 18:13 |
| tmlind | the phy driver needs to just call of_platform_populate() to probe the child devices | 18:14 |
| freemangordon | ok, thanks | 18:14 |
| tmlind | hmm the nice thing is that the phy driver knows when the modem is there and the gsm stuff is working | 18:15 |
| tmlind | in flash mode, it's not in gsm mode | 18:15 |
| freemangordon | mhm | 18:16 |
| freemangordon | and I can return EPROBE_DEFER until I can open the gsm ttys (from snd soc driver), right? | 18:16 |
| tmlind | well the phy driver can call of_platform_populate() only after the modem is powered up | 18:17 |
| tmlind | and remove the child devices on shutdown | 18:17 |
| freemangordon | ok, but will ttyGSMn devices appear instantly? | 18:18 |
| tmlind | no, it takes some time, see the 8 second or so wait in the phy driver | 18:18 |
| freemangordon | mhm, so, I can return EPROBE_DEFER in snd soc driver until the is tty device to open, isn't that proper? | 18:19 |
| freemangordon | *there is | 18:19 |
| tmlind | no need to, the snd soc driver won't probe until you call of_platform_populate() | 18:19 |
| tmlind | i think you can call that after the request threaded irq in the phy driver | 18:20 |
| tmlind | that's when the completion is done | 18:20 |
| freemangordon | ok | 18:22 |
| freemangordon | thanks! | 18:22 |
| freemangordon | have to cook some dinner, laters | 18:23 |
| tmlind | i think one of the reasons for serdev was that there's no way to tell if something is connected to a uart without devicetree, with your solution that issue is not there as the phy driver knows when the line discipline can be started | 18:23 |
| tmlind | ok ttyl | 18:23 |
| freemangordon | mhm | 18:23 |
| freemangordon | ttyl | 18:23 |
| freemangordon | tmlind: why serdev_ngsm does runtime PM of USB phy? is that really needed now with USB wakeup? | 19:46 |
| sicelo | btw, in brief, what's the relationship between the uart/serial stuff and audio? | 19:48 |
| freemangordon | voice call volume/mute/noise cancellation is done with commands over serial | 19:49 |
| freemangordon | also, switching between BT/Headset, ... | 19:49 |
| freemangordon | tmlind: scratch that, it needs to wake the modem | 19:50 |
| tmlind | freemangordon: probably the wake pin kicking is needed for gsm | 19:50 |
| freemangordon | yeah | 19:50 |
| freemangordon | hmm, I can;t have 2 platform drivers in on e module, right? | 19:51 |
| tmlind | freemangordon: so what's the AT+CMUX=0 init sequence you used for ttyUSB4? i can try it briefly with my debug tool too | 19:51 |
| freemangordon | sec | 19:51 |
| tmlind | you can have the asoc driver and others as completely separate drivers like we have with serdev ngsm | 19:52 |
| freemangordon | yes, but serial platform driver? | 19:52 |
| tmlind | hmm not sure what you mean.. | 19:52 |
| freemangordon | I should have it as a separate platform driver too, no? | 19:52 |
| tmlind | what's the serial platform driver? | 19:53 |
| freemangordon | now we have p, li { white-space: pre-wrap; } "motorola,mapphone-mdm6600-serial" | 19:53 |
| freemangordon | that one | 19:53 |
| freemangordon | that's a DT child of uart1 | 19:53 |
| tmlind | oh i don't think it's needed now | 19:53 |
| tmlind | that was the glue between serdev ngsm and the dlci | 19:53 |
| freemangordon | right | 19:53 |
| freemangordon | but... | 19:54 |
| freemangordon | isn;t it beter some platform driver to be probed when uart1 appears? | 19:54 |
| freemangordon | or ther is no need | 19:54 |
| tmlind | no need to if you probe the child device drivers when the modem is ready | 19:54 |
| freemangordon | and I just wait long enough in phy driver and just open the tty? | 19:54 |
| freemangordon | ok | 19:55 |
| tmlind | yeah open if after the request_threaded_irq() when the completion is completed | 19:55 |
| tmlind | in the phy driver | 19:55 |
| freemangordon | yeah, but, is it guaranteed that uart1 will be ready by that time? | 19:55 |
| tmlind | should be yeah | 19:55 |
| freemangordon | ok | 19:55 |
| tmlind | unless booted to flash_mode | 19:55 |
| freemangordon | so, this https://github.com/Rtone/cmux | 19:56 |
| freemangordon | yeah, but phy driver knows the mode | 19:56 |
| tmlind | right :) | 19:56 |
| tmlind | so you just changed the cmux init sequence and pointed it to /dev/ttyUSB4? | 19:56 |
| freemangordon | yep | 19:56 |
| freemangordon | this patch https://pastebin.com/REhpYu7p | 19:56 |
| freemangordon | this creates 4 ports, no idea why 4, but... | 19:57 |
| freemangordon | oh | 19:57 |
| tmlind | ok no luck so far here with patched https://github.com/tmlind/droid4-ngsm | 19:57 |
| freemangordon | #define NUM_NODES4 | 19:57 |
| freemangordon | do you want me to execute some copmands? | 19:58 |
| freemangordon | *commands | 19:58 |
| tmlind | no need to, was just wondering | 19:59 |
| freemangordon | hmm, it always errors with U1234:ERROR=2, no matter what I type | 20:02 |
| tmlind | try format UNNNNAT+FOO\r\0 | 20:03 |
| freemangordon | mhm | 20:04 |
| freemangordon | does not like it | 20:04 |
| tmlind | may not be wired to anything? | 20:04 |
| freemangordon | 2 and 4 cannot be opened | 20:04 |
| freemangordon | so I guess those are not wired | 20:04 |
| freemangordon | but 1 and 3 I can open | 20:05 |
| freemangordon | 1 errors with U1234 | 20:05 |
| freemangordon | 3 errors with U0000 | 20:05 |
| freemangordon | maybe cmux sets wring parameters, lemme check | 20:05 |
| tmlind | ok sounds like something is connected | 20:08 |
| freemangordon | yes, but what :) | 20:08 |
| freemangordon | tmlind: opening /dev/gsmtty1 gives the same result | 20:14 |
| freemangordon | as opening /dev/ttyGSM1 | 20:14 |
| freemangordon | with minicom that is | 20:14 |
| freemangordon | 9 was sim card, right? (/me checks ofono) | 20:14 |
| freemangordon | no, it is 10 | 20:16 |
| freemangordon | tmlind: those are 1to1 mapped to gsmttyN ports | 20:29 |
| freemangordon | ./ttyngsm.sh 10 AT+MSIM=? over /dev/ttyGSM10 return SIM card details | 20:29 |
| freemangordon | this patch https://pastebin.com/gACm7i4w over cmux | 20:30 |
| freemangordon | script https://pastebin.com/U1LAVyG9 | 20:31 |
| tmlind | ok nice to hear | 20:35 |
| freemangordon | tmlind: hmm, am I sure uart1 tty is always ttyS0? | 20:39 |
| tmlind | heh you could use the new hardware based addressing.. except the nodes are not yet created | 20:45 |
| freemangordon | I think I shall keep serial platform driver | 20:45 |
| freemangordon | and do of_platform_populate from there | 20:46 |
| tmlind | 17199dfccd4b ("Documentation: kernel-parameters: Add DEVNAME:0.0 format for serial ports") | 20:46 |
| freemangordon | also AT+CMUX=0 shall be done from here | 20:46 |
| freemangordon | that way I avoid having to deal with device naming | 20:47 |
| freemangordon | also, I get tty port from parent device, no? | 20:47 |
| freemangordon | lets se | 20:47 |
| freemangordon | a | 20:47 |
| freemangordon | see | 20:47 |
| freemangordon | tmlind: can I do of_get_parent() from serial platform driver to get uart device directly? | 20:59 |
| tmlind | not following.. from which driver are you trying to do that from? | 21:04 |
| freemangordon | "motorola,mapphone-mdm6600-serial" | 21:05 |
| freemangordon | I want to keep that | 21:05 |
| tmlind | oh ok | 21:05 |
| freemangordon | and call AT+CMUX=0 from its probe() | 21:06 |
| tmlind | so is that child of the phy now? | 21:06 |
| freemangordon | no, I am keeping the same DT | 21:06 |
| freemangordon | it is child of uart | 21:06 |
| freemangordon | so I can get uart driver_node | 21:07 |
| tmlind | if it's a child of the uart, likely it would need to be a serdev driver | 21:07 |
| freemangordon | I can do of_get_parent() right? | 21:08 |
| tmlind | yeah or dev->parent | 21:08 |
| freemangordon | not sure how to get serdev device from that | 21:08 |
| freemangordon | will try though | 21:08 |
| tmlind | just set up "motorola,mapphone-mdm6600-serial" as a direct serdev device for the uart | 21:09 |
| freemangordon | hmm, ok | 21:09 |
| tmlind | then start the gsm line discipline, and n_gsm.c will create the /dev/gsmtty instances | 21:10 |
| freemangordon | mhm | 21:10 |
| tmlind | i think it needs to be a child of /dev/ttyS0 though, can't use /dev/ttyUSB4 | 21:10 |
| freemangordon | yes | 21:10 |
| tmlind | ok | 21:10 |
| freemangordon | I want to use serial, not usb | 21:10 |
| tmlind | yeah | 21:10 |
| tmlind | no special need to use the ttyUSB4 | 21:11 |
| freemangordon | exactly | 21:11 |
| freemangordon | hmm, can't find anything 'serdev' related | 21:11 |
| tmlind | git grep EXPORT drivers/tty/serdev/ | 21:12 |
| freemangordon | hmm... | 21:13 |
| tmlind | the serdev device won't have the tty created, i wonder if that's going to cause an issue starting the line discipline | 21:13 |
| tmlind | for an example on d4, see drivers/bluetooth/hci_ll.c | 21:15 |
| freemangordon | so, serdev_device_driver_register() instead of platfrom device? | 21:17 |
| freemangordon | sorry, not following | 21:18 |
| tmlind | yeah serdev_device_driver_register() | 21:19 |
| tmlind | grep for ti,wl1285-st for the hci_ll.c example dts | 21:19 |
| tmlind | when you configure a uart for a serdev device, it won't have the tty created for /dev/ttyS0 | 21:20 |
| freemangordon | I was thinking about something else: instead of creating serdev, isn't it possible to get uart device (being parent in DT) and then using it to find port device and tty respectively? | 21:20 |
| tmlind | right but with serdev you get quite a bit of stuff automated for you | 21:21 |
| tmlind | you just do serdev_write() for AT+CMUX=0 | 21:21 |
| freemangordon | but then, who will set line discipline on the port? | 21:22 |
| tmlind | can't remember the name of the function, something else not serdev_write() | 21:22 |
| freemangordon | write_wkup() or something | 21:22 |
| tmlind | heh yeah setting the line discipline part is a bit open :) | 21:22 |
| freemangordon | so, I will need parent port tty device either ways | 21:23 |
| tmlind | do you need a struct tty for that? | 21:23 |
| freemangordon | mhm | 21:23 |
| freemangordon | lemme try to find the code | 21:23 |
| freemangordon | int tty_set_ldisc(struct tty_struct *tty, int disc) | 21:24 |
| freemangordon | so I need struct tty | 21:24 |
| tmlind | hmm | 21:24 |
| tmlind | well drivers/bluetooth is setting the line discpline somehow for the wlcore bluetooth example i pasted above | 21:25 |
| freemangordon | lemme check it | 21:26 |
| tmlind | i guess must be in drivers/bluetooth/hci_serdev.c | 21:27 |
| tmlind | as it replaces drivers/bluetooth/hci_ldisc.c for serdev devices i think | 21:29 |
| tmlind | hmm actually i think serdev hci does it without line discpiline | 21:30 |
| freemangordon | mhm | 21:30 |
| freemangordon | that's what I think too | 21:31 |
| freemangordon | maybe we can call n_gsm functions directly? | 21:31 |
| freemangordon | if they are exported at all | 21:31 |
| tmlind | heh so back to serdev-ngsm? | 21:31 |
| freemangordon | but without need to upstream another driver :) | 21:31 |
| freemangordon | lemme see if n_gsm exports any API | 21:32 |
| tmlind | i added some patch to export the registering in the serdev-ngsm patches | 21:32 |
| freemangordon | mhm | 21:32 |
| freemangordon | I will look upstream | 21:32 |
| tmlind | i think johan had some idea to make the dlci instances to use serdev too but that might get messy | 21:33 |
| freemangordon | nope, nothing is exported from n_gsm | 21:35 |
| tmlind | right | 21:35 |
| freemangordon | ok, lets get back to my initial plan | 21:35 |
| freemangordon | I just need to find the way to get from uart device_node to uart_port or something | 21:35 |
| freemangordon | we have kobject in device_node, is that useful for anything? | 21:36 |
| tmlind | &of->dev ? | 21:37 |
| freemangordon | lemme check | 21:37 |
| tmlind | gotta go here, have fun, ttyl | 21:39 |
| freemangordon | ttyl | 21:39 |
| freemangordon | thanks! | 21:39 |
| freemangordon | hmm, of_find_device_by_node() | 21:41 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!