<tmlind>
echo "Now configure and start gpsd to read /dev/cdc-wdm0"
<freemangordon>
hmm, weird
<freemangordon>
trying to enable loc here using qmicli results in 'invalid service'
<freemangordon>
but with ofono I get "disabled'
<tmlind>
yeah it might be some long term regression
<tmlind>
but mmcli is for modemmanager, no?
<freemangordon>
yes
<freemangordon>
but afaik it ises libqmi too
<freemangordon>
*uses
<tmlind>
yeah
<freemangordon>
lemme check if I can make it work with ofono
<tmlind>
anyways, that used to work, but would take quite a while to produce data
<tmlind>
probably some way to inject the a-gps data over qmi too..
<freemangordon>
what concerns me more is wake-up
<tmlind>
yeah
<freemangordon>
so, I admit I lack the knowledge, but which device should wake-up? musb?
pabs3 has joined #maemo-leste
<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
narodnik has joined #maemo-leste
<freemangordon>
sorry, not sure I understand - I see "3090 4805b000.gpio 21 Edge mdm6600-wake"
<tmlind>
hmm yeah.. something should wake up and do a qmi query, so maybe the qmi device on the ohci bus?
<freemangordon>
yeah, that's my question: which device shall we wake-up
<tmlind>
only the first gpio bank can wake up the soc from idle state, others need to use the related padconf interrupt
<tmlind>
isn't there some qmi network device?
<freemangordon>
I don;t think soc is idle
<freemangordon>
or at least - it is not soc being idle that stops the data flow
<freemangordon>
IIUC
<tmlind>
yeah the soc could idle between the usb events but probably does not right now..
<freemangordon>
we have /dev/cdc-wdmN
<freemangordon>
1..4
<freemangordon>
ofono uses cdc-wdm0
<freemangordon>
lemme check where it lives
<tmlind>
yeah so maybe that device.. unless the phy driver can kick something with no understanding of the qmi
<freemangordon>
cdc-wdm0 is on "Bus 002 Device 002: ID 22b8:2a70 Motorola PCS Flash MZ600"
<freemangordon>
so it is on the phy, no?
<freemangordon>
hmm, how wake-up yourself?
<freemangordon>
like, it already calls pm_runtime_get_sync() on wake-up irq?
<tmlind>
yeah but nothing kicks the usb modem, not sure what is needed for that
<freemangordon>
pulse on AP gpio?
<freemangordon>
ok, wait, lemme see if I get that right
<freemangordon>
modem triggers wake-up but expect 'we' to wake it up as well?
<tmlind>
maybe..
<freemangordon>
ugh
<freemangordon>
lemme check
<freemangordon>
that shall be easy
<tmlind>
worth a try
<freemangordon>
mhm
<freemangordon>
lemme first see if I can get gps working though ofono
<freemangordon>
and then will try
<freemangordon>
will let you know
<tmlind>
the mdm6600 usb phy is physically on the mdm6600 afaik
<freemangordon>
ah
<tmlind>
sounds like the usb host needs to scan something over the usb based on the wake-up gpio event
<tmlind>
usually usb gadgets signal the wake-up with the data lines pulled into some position
<freemangordon>
yeah, it seems to be part of the specs
<freemangordon>
but, if mdm6600 phy is suspended, it will not do anything
<freemangordon>
so, we shall find a way to trigger remote wake-up from the why driver
<freemangordon>
like, writing some NOP or dunno
<tmlind>
or fake the usb gadget wake-up event to the host with the internal pulls on the data lines
<freemangordon>
yes
<freemangordon>
but how to do that from the phy driver
<tmlind>
but that may not be the issue as the wake-up events never propagate to the qmi
<freemangordon>
I think it is not that our devices are suspended
<tmlind>
to me it seems we need to somehow signal the qmi layer about the event
<freemangordon>
but that remote device (usb in the modem) is suspeneded
<tmlind>
well the usb modem will respond to host queries though
<tmlind>
the only thing the usb modem can signal is the gadget wake over the data lines
<tmlind>
we need to somehow wake the usb host qmi layer..
<freemangordon>
ok, lemme disable power-management to see if events will start coming
<tmlind>
kind of what we do in ofono for the kick function
<freemangordon>
I disabled PM of all USB ports
<freemangordon>
to no use
<tmlind>
yeah ok
<freemangordon>
so it seems that *remote* side needs a kick
<tmlind>
remote to what side?
<tmlind>
usb peripheral?
<freemangordon>
modem itself seems asleep
<freemangordon>
so 'we' are AP (soc side) and 'remote' is BP (modem side)
<freemangordon>
to me it seems BP USB is sleeping, that's why we don't receive anything
<tmlind>
yeah ok could be
<freemangordon>
any idea how to send some NOP URB?
<tmlind>
from which driver?
<freemangordon>
p, li { white-space: pre-wrap; } phy-mapphone-mdm6600
<freemangordon>
that's the one that receives wake-up irq
<tmlind>
the only thing phy-mapphone-mdm6600 can play with is the gpios and pulls for them
<freemangordon>
hmm, ok
<freemangordon>
so which driver it is then? cpcap-usb?
<freemangordon>
musb?
<tmlind>
no, ohci-platform
<freemangordon>
ok
<tmlind>
ohci-platform or qmi cdc whatever could also claim that gpio wake-up interrupt as a shared interrupt
<freemangordon>
mhm
<freemangordon>
hmm, seems I was able to enable *something* on d4 in regards to gps :)
<tmlind>
cool
<freemangordon>
tmlind: it seems I actually get gps data with ofono
<tmlind>
freemangordon: nice, so no fixes needed then for gps?
DFP has quit [Quit: Leaving]
<tmlind>
freemangordon: hmm so what if the mdm6600 phy sends a KEY_PHONE event, can ofono listen for it?
<freemangordon>
perhaps yes, but sounds like a hack
<freemangordon>
like, what would ofono do? kick the modem?
<tmlind>
heh yeah
<freemangordon>
well...
<freemangordon>
lemme check if phy kicking the gpio will have any effect
<freemangordon>
this is with d4 connected in BP mode
* freemangordon
is building d4 kernel
<tmlind>
ok
<freemangordon>
did you see paste ^^^? does it look like a proper data?
<sicelo>
to me, yes
<freemangordon>
cool
Livio has joined #maemo-leste
<tmlind>
looks like the right data before satellites are seen
<freemangordon>
ok
<tmlind>
you may need to online the modem if not online though
<freemangordon>
yeah
<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?
<freemangordon>
ok, thanks
<tmlind>
heh not sure if we have usb devices with gpio interrupts though :)
Livio has quit [Ping timeout: 264 seconds]
Anasko has quit [Read error: Connection reset by peer]