| Wizzup | freemangordon: sry for not responding wrt ofono, looks like youre on it | 12:57 |
|---|---|---|
| freemangordon | yes, I just sent a patch | 12:58 |
| freemangordon | you are in CC | 12:58 |
| freemangordon | I think that's the correct way of fixing it, but please have a look if you have some time | 12:58 |
| freemangordon | sicelo: Wizzup: https://github.com/maemo-leste-upstream-forks/ofono/commits/upstream-wip/ | 13:13 |
| freemangordon | with this outgoing calls work, incoming not (as expected) | 13:57 |
| freemangordon | have to check if we can get wake-ups via AT interface | 13:58 |
| Wizzup | and checking some of the usb ifaces for any data whatsoever doesn't work as wake up? | 14:22 |
| freemangordon | checking, like polling? | 14:27 |
| Wizzup | select? | 14:27 |
| freemangordon | ofono already does that | 14:27 |
| freemangordon | but usb itself does not wake-up | 14:28 |
| freemangordon | hmm, unfortunately snd_soc is also using n_gsm | 14:30 |
| freemangordon | otherwise we can use modem wake-up gpio | 14:30 |
| * dsc_ strangles QHeaderView | 15:04 | |
| sicelo | freemangordon: yay, about to build, thanks | 16:44 |
| sicelo | what parent was this? i was working off leste/maemo/chimaera-devel, and have no plugins/droid* file. there is plugins/motmdm.c | 16:46 |
| freemangordon | no | 16:46 |
| freemangordon | check the branch | 16:46 |
| freemangordon | https://github.com/maemo-leste-upstream-forks/ofono/commits/upstream-wip/ | 16:46 |
| sicelo | ah, i see now | 16:48 |
| sicelo | i never realized that there was already something of D4 in upstream ofono | 16:50 |
| freemangordon | there is | 16:52 |
| freemangordon | never tried it though | 16:52 |
| freemangordon | hmm I wonder if we can simply export wake-up gpio to userspace and call it a day | 16:55 |
| sicelo | (btw, ofono dropped support for mbpi a couple of versions back, so we may want to drop it from list of deps) | 16:58 |
| freemangordon | wip branch has no packaging at all | 16:58 |
| freemangordon | I want to fix wake-up issue first | 16:58 |
| freemangordon | tmlind: https://github.com/maemo-leste-upstream-forks/ofono/commits/upstream-wip/ | 16:59 |
| freemangordon | tmlind: even (outgoing) voice calls seem to work, however, as expected, incoming calls, sms, etc do not work | 17:00 |
| tmlind | freemangordon: that's cool, so only the wakeup is missing? :) | 17:00 |
| sicelo | what is the wakeup issue btw? apologies i've never really followed the quirks of droid 4 modem | 17:00 |
| freemangordon | tmlind: what about exporting wake-up gpio? | 17:00 |
| freemangordon | and teaching ofono driver on it | 17:00 |
| tmlind | hmm yeah interesting idea | 17:00 |
| freemangordon | isimmodem already deals with gpios, so support seems to be there already | 17:01 |
| tmlind | all it needs is a wake up to kick the usb modem.. | 17:01 |
| freemangordon | mhm | 17:01 |
| tmlind | yup worth a try for sure | 17:01 |
| freemangordon | will do | 17:01 |
| freemangordon | just wanted to hear from you | 17:01 |
| tmlind | the missing 1 bit of data | 17:01 |
| freemangordon | :) | 17:01 |
| tmlind | so which gpio though? the rx line on uart1? | 17:01 |
| freemangordon | no, phy wake-up | 17:02 |
| freemangordon | 611 or something | 17:02 |
| tmlind | usb phy wake? oh sure if that generates anything | 17:02 |
| tmlind | sicelo: the issue is that usb modem never sees any events as they are only routed to the uart | 17:03 |
| freemangordon | at least count in /proc/interrupts increases for mdm6600-wake when I send sms | 17:03 |
| tmlind | oh that's great | 17:03 |
| tmlind | might as well use the padconf interrupt unless the interrupt is in the first gpio bank | 17:04 |
| freemangordon | tmlind: BTW, do you know, can we use USB4 to control modem volume etc? | 17:04 |
| freemangordon | ttyUSB4 that is | 17:04 |
| tmlind | no idea, but let's hope so | 17:04 |
| freemangordon | AT interfcae | 17:04 |
| freemangordon | hmm | 17:05 |
| tmlind | the usb qmi gps interface used to work years ago, then it at some point stopped working | 17:05 |
| freemangordon | any idea how to try it? | 17:05 |
| freemangordon | as now I have LocationReporting with qmimodem driver | 17:06 |
| freemangordon | actually... | 17:06 |
| freemangordon | hmm, starting maep does not create any event in ofono | 17:07 |
| freemangordon | what interface do we use? | 17:07 |
| tmlind | some qmicli command used to work for gps data | 17:09 |
| freemangordon | Wizzup: any idea how do we use gps on d4? through ofono? | 17:09 |
| sicelo | no, gpsd | 17:13 |
| freemangordon | and how does it communicate with the modem? | 17:14 |
| tmlind | probably over n_gsm | 17:19 |
| tmlind | freemangordon: qmicli --loc-start followed by qmicli --loc-follow-nmea or some similar command used to eventually produce gps info | 17:22 |
| freemangordon | no | 17:22 |
| freemangordon | this modem does not export LOC service | 17:22 |
| freemangordon | but PDS | 17:22 |
| freemangordon | "Position Determination Service" | 17:23 |
| tmlind | ah ok yeah anyways some commands listed in the qmicli man page | 17:23 |
| freemangordon | and qmicli does not seem to support it | 17:23 |
| freemangordon | tried already, they fail | 17:23 |
| tmlind | hmm it used to long time ago | 17:23 |
| freemangordon | maybe they used PDS back then | 17:24 |
| tmlind | can't find my old test scripts though | 17:24 |
| tmlind | heh found something, it's using mmcli though | 17:29 |
| tmlind | has these lines: | 17:29 |
| tmlind | sudo mmcli -m ${modem} --enable | 17:29 |
| tmlind | sudo mmcli -m ${modem} --location-enable-gps-raw | 17:29 |
| tmlind | sudo chmod a+r /dev/cdc-wdm0 | 17:29 |
| tmlind | echo "Now configure and start gpsd to read /dev/cdc-wdm0" | 17:29 |
| freemangordon | hmm, weird | 17:30 |
| freemangordon | trying to enable loc here using qmicli results in 'invalid service' | 17:30 |
| freemangordon | but with ofono I get "disabled' | 17:30 |
| tmlind | yeah it might be some long term regression | 17:31 |
| tmlind | but mmcli is for modemmanager, no? | 17:31 |
| freemangordon | yes | 17:31 |
| freemangordon | but afaik it ises libqmi too | 17:31 |
| freemangordon | *uses | 17:31 |
| tmlind | yeah | 17:31 |
| freemangordon | lemme check if I can make it work with ofono | 17:32 |
| tmlind | anyways, that used to work, but would take quite a while to produce data | 17:32 |
| tmlind | probably some way to inject the a-gps data over qmi too.. | 17:32 |
| freemangordon | what concerns me more is wake-up | 17:32 |
| tmlind | yeah | 17:33 |
| freemangordon | so, I admit I lack the knowledge, but which device should wake-up? musb? | 17:33 |
| tmlind | good find if you see some phy interrupts, maybe try with the gpio phy interrupt first, then let's figure out the related padconf interrupt to use for wake-up from any state | 17:33 |
| freemangordon | sorry, not sure I understand - I see "3090 4805b000.gpio 21 Edge mdm6600-wake" | 17:34 |
| tmlind | hmm yeah.. something should wake up and do a qmi query, so maybe the qmi device on the ohci bus? | 17:35 |
| freemangordon | yeah, that's my question: which device shall we wake-up | 17:35 |
| tmlind | only the first gpio bank can wake up the soc from idle state, others need to use the related padconf interrupt | 17:35 |
| tmlind | isn't there some qmi network device? | 17:35 |
| freemangordon | I don;t think soc is idle | 17:35 |
| freemangordon | or at least - it is not soc being idle that stops the data flow | 17:36 |
| freemangordon | IIUC | 17:36 |
| tmlind | yeah the soc could idle between the usb events but probably does not right now.. | 17:36 |
| freemangordon | we have /dev/cdc-wdmN | 17:37 |
| freemangordon | 1..4 | 17:37 |
| freemangordon | ofono uses cdc-wdm0 | 17:37 |
| freemangordon | lemme check where it lives | 17:37 |
| tmlind | yeah so maybe that device.. unless the phy driver can kick something with no understanding of the qmi | 17:37 |
| freemangordon | cdc-wdm0 is on "Bus 002 Device 002: ID 22b8:2a70 Motorola PCS Flash MZ600" | 17:40 |
| freemangordon | so it is on the phy, no? | 17:40 |
| freemangordon | hmm, how wake-up yourself? | 17:41 |
| freemangordon | like, it already calls pm_runtime_get_sync() on wake-up irq? | 17:41 |
| tmlind | yeah but nothing kicks the usb modem, not sure what is needed for that | 17:42 |
| freemangordon | pulse on AP gpio? | 17:43 |
| freemangordon | ok, wait, lemme see if I get that right | 17:43 |
| freemangordon | modem triggers wake-up but expect 'we' to wake it up as well? | 17:44 |
| tmlind | maybe.. | 17:44 |
| freemangordon | ugh | 17:44 |
| freemangordon | lemme check | 17:44 |
| freemangordon | that shall be easy | 17:44 |
| tmlind | worth a try | 17:45 |
| freemangordon | mhm | 17:45 |
| freemangordon | lemme first see if I can get gps working though ofono | 17:45 |
| freemangordon | and then will try | 17:45 |
| freemangordon | will let you know | 17:45 |
| tmlind | the mdm6600 usb phy is physically on the mdm6600 afaik | 17:45 |
| freemangordon | ah | 17:45 |
| tmlind | sounds like the usb host needs to scan something over the usb based on the wake-up gpio event | 17:47 |
| tmlind | usually usb gadgets signal the wake-up with the data lines pulled into some position | 17:49 |
| freemangordon | yeah, it seems to be part of the specs | 17:49 |
| freemangordon | but, if mdm6600 phy is suspended, it will not do anything | 17:50 |
| freemangordon | so, we shall find a way to trigger remote wake-up from the why driver | 17:50 |
| freemangordon | like, writing some NOP or dunno | 17:50 |
| tmlind | or fake the usb gadget wake-up event to the host with the internal pulls on the data lines | 17:53 |
| freemangordon | yes | 17:53 |
| freemangordon | but how to do that from the phy driver | 17:53 |
| tmlind | but that may not be the issue as the wake-up events never propagate to the qmi | 17:53 |
| freemangordon | I think it is not that our devices are suspended | 17:53 |
| tmlind | to me it seems we need to somehow signal the qmi layer about the event | 17:54 |
| freemangordon | but that remote device (usb in the modem) is suspeneded | 17:54 |
| tmlind | well the usb modem will respond to host queries though | 17:54 |
| tmlind | the only thing the usb modem can signal is the gadget wake over the data lines | 17:55 |
| tmlind | we need to somehow wake the usb host qmi layer.. | 17:55 |
| freemangordon | ok, lemme disable power-management to see if events will start coming | 17:55 |
| tmlind | kind of what we do in ofono for the kick function | 17:56 |
| freemangordon | I disabled PM of all USB ports | 18:00 |
| freemangordon | to no use | 18:00 |
| tmlind | yeah ok | 18:01 |
| freemangordon | so it seems that *remote* side needs a kick | 18:01 |
| tmlind | remote to what side? | 18:02 |
| tmlind | usb peripheral? | 18:02 |
| freemangordon | modem itself seems asleep | 18:02 |
| freemangordon | so 'we' are AP (soc side) and 'remote' is BP (modem side) | 18:03 |
| freemangordon | to me it seems BP USB is sleeping, that's why we don't receive anything | 18:03 |
| tmlind | yeah ok could be | 18:03 |
| freemangordon | any idea how to send some NOP URB? | 18:05 |
| tmlind | from which driver? | 18:05 |
| freemangordon | p, li { white-space: pre-wrap; } phy-mapphone-mdm6600 | 18:06 |
| freemangordon | that's the one that receives wake-up irq | 18:06 |
| tmlind | the only thing phy-mapphone-mdm6600 can play with is the gpios and pulls for them | 18:07 |
| freemangordon | hmm, ok | 18:07 |
| freemangordon | so which driver it is then? cpcap-usb? | 18:08 |
| freemangordon | musb? | 18:08 |
| tmlind | no, ohci-platform | 18:08 |
| freemangordon | ok | 18:08 |
| tmlind | ohci-platform or qmi cdc whatever could also claim that gpio wake-up interrupt as a shared interrupt | 18:09 |
| freemangordon | mhm | 18:09 |
| freemangordon | hmm, seems I was able to enable *something* on d4 in regards to gps :) | 18:38 |
| tmlind | cool | 18:47 |
| freemangordon | tmlind: it seems I actually get gps data with ofono | 19:02 |
| tmlind | freemangordon: nice, so no fixes needed then for gps? | 19:11 |
| tmlind | freemangordon: hmm so what if the mdm6600 phy sends a KEY_PHONE event, can ofono listen for it? | 19:18 |
| freemangordon | perhaps yes, but sounds like a hack | 19:26 |
| freemangordon | like, what would ofono do? kick the modem? | 19:26 |
| tmlind | heh yeah | 19:28 |
| freemangordon | well... | 19:28 |
| freemangordon | lemme check if phy kicking the gpio will have any effect | 19:28 |
| tmlind | ok | 19:29 |
| freemangordon | tmlind: https://pastebin.com/aFfGBqQi | 19:37 |
| freemangordon | code https://pastebin.com/L1U12yid | 19:37 |
| freemangordon | this is with d4 connected in BP mode | 19:38 |
| * freemangordon is building d4 kernel | 19:42 | |
| tmlind | ok | 19:44 |
| freemangordon | did you see paste ^^^? does it look like a proper data? | 19:45 |
| sicelo | to me, yes | 19:45 |
| freemangordon | cool | 19:45 |
| tmlind | looks like the right data before satellites are seen | 19:49 |
| freemangordon | ok | 19:49 |
| tmlind | you may need to online the modem if not online though | 19:52 |
| freemangordon | yeah | 19:53 |
| tmlind | freemangordon: not sure if this helps, but see usb_autopm_get_interface() in drivers/net/usb/qmi_wwan.c.. if qmi_wwan.c added support for oob gpio interrupts, that could be called? | 20:08 |
| freemangordon | ok, thanks | 20:09 |
| tmlind | heh not sure if we have usb devices with gpio interrupts though :) | 20:09 |
| freemangordon | tmlind: oh, phy-mapphone-mdm6600 already kicks mode_gpio0 (BP wake) | 20:55 |
| freemangordon | tmlind: do I get it right that there is a real serial interface between modem and soc? | 21:27 |
| freemangordon | not serial over usb? | 21:27 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!