System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
brabo has joined #maemo-leste
akossh has quit [Quit: Leaving.]
norayr has quit [Ping timeout: 252 seconds]
norayr has joined #maemo-leste
Pali has quit [Quit: Pali]
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
pabs3 has joined #maemo-leste
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
<freemangordon>
Wizzup: ok :)
<Wizzup>
:D
norayr has quit [Ping timeout: 252 seconds]
Pali has joined #maemo-leste
avgjoe has quit [Quit: Quit]
akossh has joined #maemo-leste
pere has quit [Ping timeout: 265 seconds]
mrkrisprolls has quit [Quit: Tchussss!]
avgjoe has joined #maemo-leste
mkfz has joined #maemo-leste
<mkfz>
hello
<mkfz>
there is a store nearby me which sells n900 phones
<mkfz>
these are however locked, can I buy them and get rid of password?
<inky>
i think you just reflash
<mkfz>
is there anything I need to consider or check before I buy?
pere has joined #maemo-leste
<sicelo>
modem works, usb port works
<tmlind>
freemangordon: maybe ofono can directly access the gsm dlcs on /dev/ttyS0, see g_at_mux_new_gsm0710_basic()
<Wizzup>
mkfz: I think just modem and usb yeah, lock should not be a problem
mkfz has quit [Ping timeout: 244 seconds]
<freemangordon>
tmlind: the question was - can kernel do something in a way that there is no need of served_ngsm
<freemangordon>
ofono does not need anything tty now it uses qmi
<freemangordon>
so, can snd soc or phy driver open /dev/ttyS0 and set line discipline on it
<freemangordon>
*serdev_ngsm that is
<freemangordon>
or, upstreaming serdev_ngsm is the only proper way
gnarface has quit [Ping timeout: 245 seconds]
freemangordon has quit [Read error: Connection reset by peer]
freemangordon has joined #maemo-leste
gnarface has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
<tmlind>
well the uart wakeups do not matter much any longer with usb qmi working if it's just the audio
<tmlind>
afaik serdev is the way to build serial port device drivers, otherwise it would have to be user space
<freemangordon>
ok, but can;t we do the same in kernel as in userspace:
<freemangordon>
open ttyS0, set line discipline to n_gsm, etc
<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
<freemangordon>
*manage
<tmlind>
yeah it's a pain to fix up for upstreaming..
<freemangordon>
so, I saw at least 2 drivers that open tty devices, in upstream
<tmlind>
so if ofono handled it, we still need to coordinate with the asoc driver with daemon i think sicelo mentioned earlier
<freemangordon>
hmm, I missed that
<tmlind>
i doubt a sound driver doing tty_set_ldisc() would be liked much..
<freemangordon>
no, that would be the phy
<tmlind>
phy?
<freemangordon>
yeah, why not?
<freemangordon>
I mean: phy will set line discipline on ttyS0
<tmlind>
well it's the opening of the ports part still that's going to be messy
<freemangordon>
and than soc will open ttyGSM2 (or whatever is the correct tty for audio contol)
<freemangordon>
*and then
<tmlind>
much cleaner if ofono sets the voice call volume with some daemon coordinating the asoc settings imo :)
<Wizzup>
might be worth to see what asoc folks think
<tmlind>
sure
<freemangordon>
this is out of my knowledge
<Wizzup>
if it's in alsa then it'll be easier for the rest of userspace
<freemangordon>
lemme find what upstream does ATM in terms of opening tty devices
<tmlind>
then it makes sense to implement it with serdev and we've seen that it goes nowhere
<freemangordon>
had to change init sequence a bit, but....
<freemangordon>
and then I got this ULXXX headers
<freemangordon>
or DL, whatever
<tmlind>
i also made some userspace gsm tool before i went with the serdev stuff because of the wake-up events needed
<freemangordon>
the proprietary motorola framing
<tmlind>
ah right
<freemangordon>
well, I don;t see why shall we drop wake-ups
<tmlind>
you can ignore the motorola header and start all writes with U1234
<freemangordon>
my gut feeling tells me that without them wi might have stability issues in long run
<freemangordon>
*we
<tmlind>
well the wakeups are now implemented in the phy driver
<freemangordon>
like, overfilling some modem internal buffer/queue
<freemangordon>
right
<tmlind>
if your audio device driver is a child of the phy, it will wake up the parent phy driver with pm_runtime_get()
<freemangordon>
mhm
<freemangordon>
I understand that
<tmlind>
ok
<freemangordon>
I think I will keep the current DT structure initially, DT is not my strongest skill
<tmlind>
the phy driver needs to just call of_platform_populate() to probe the child devices
<freemangordon>
ok, thanks
<tmlind>
hmm the nice thing is that the phy driver knows when the modem is there and the gsm stuff is working
<tmlind>
in flash mode, it's not in gsm mode
<freemangordon>
mhm
<freemangordon>
and I can return EPROBE_DEFER until I can open the gsm ttys (from snd soc driver), right?
<tmlind>
well the phy driver can call of_platform_populate() only after the modem is powered up
<tmlind>
and remove the child devices on shutdown
<freemangordon>
ok, but will ttyGSMn devices appear instantly?
<tmlind>
no, it takes some time, see the 8 second or so wait in the phy driver
<freemangordon>
mhm, so, I can return EPROBE_DEFER in snd soc driver until the is tty device to open, isn't that proper?
<freemangordon>
*there is
<tmlind>
no need to, the snd soc driver won't probe until you call of_platform_populate()
<tmlind>
i think you can call that after the request threaded irq in the phy driver
<tmlind>
that's when the completion is done
<freemangordon>
ok
<freemangordon>
thanks!
<freemangordon>
have to cook some dinner, laters
<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
<tmlind>
ok ttyl
<freemangordon>
mhm
<freemangordon>
ttyl
Livio has joined #maemo-leste
Livio has quit [Ping timeout: 264 seconds]
<freemangordon>
tmlind: why serdev_ngsm does runtime PM of USB phy? is that really needed now with USB wakeup?
<sicelo>
btw, in brief, what's the relationship between the uart/serial stuff and audio?
<freemangordon>
voice call volume/mute/noise cancellation is done with commands over serial
<freemangordon>
also, switching between BT/Headset, ...
<freemangordon>
tmlind: scratch that, it needs to wake the modem
<tmlind>
freemangordon: probably the wake pin kicking is needed for gsm
<freemangordon>
yeah
<freemangordon>
hmm, I can;t have 2 platform drivers in on e module, right?
<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
<freemangordon>
sec
<tmlind>
you can have the asoc driver and others as completely separate drivers like we have with serdev ngsm
<freemangordon>
yes, but serial platform driver?
<tmlind>
hmm not sure what you mean..
<freemangordon>
I should have it as a separate platform driver too, no?
<tmlind>
what's the serial platform driver?
<freemangordon>
now we have p, li { white-space: pre-wrap; } "motorola,mapphone-mdm6600-serial"
<freemangordon>
that one
<freemangordon>
that's a DT child of uart1
<tmlind>
oh i don't think it's needed now
<tmlind>
that was the glue between serdev ngsm and the dlci
<freemangordon>
right
<freemangordon>
but...
Livio has joined #maemo-leste
<freemangordon>
isn;t it beter some platform driver to be probed when uart1 appears?
<freemangordon>
or ther is no need
<tmlind>
no need to if you probe the child device drivers when the modem is ready
<freemangordon>
and I just wait long enough in phy driver and just open the tty?
<freemangordon>
ok
<tmlind>
yeah open if after the request_threaded_irq() when the completion is completed
<tmlind>
in the phy driver
<freemangordon>
yeah, but, is it guaranteed that uart1 will be ready by that time?
<freemangordon>
and call AT+CMUX=0 from its probe()
<tmlind>
so is that child of the phy now?
<freemangordon>
no, I am keeping the same DT
<freemangordon>
it is child of uart
<freemangordon>
so I can get uart driver_node
<tmlind>
if it's a child of the uart, likely it would need to be a serdev driver
<freemangordon>
I can do of_get_parent() right?
<tmlind>
yeah or dev->parent
<freemangordon>
not sure how to get serdev device from that
<freemangordon>
will try though
<tmlind>
just set up "motorola,mapphone-mdm6600-serial" as a direct serdev device for the uart
<freemangordon>
hmm, ok
<tmlind>
then start the gsm line discipline, and n_gsm.c will create the /dev/gsmtty instances
<freemangordon>
mhm
<tmlind>
i think it needs to be a child of /dev/ttyS0 though, can't use /dev/ttyUSB4
<freemangordon>
yes
<tmlind>
ok
<freemangordon>
I want to use serial, not usb
<tmlind>
yeah
<tmlind>
no special need to use the ttyUSB4
<freemangordon>
exactly
<freemangordon>
hmm, can't find anything 'serdev' related
<tmlind>
git grep EXPORT drivers/tty/serdev/
<freemangordon>
hmm...
<tmlind>
the serdev device won't have the tty created, i wonder if that's going to cause an issue starting the line discipline
haver has joined #maemo-leste
haver has quit [Excess Flood]
haver has joined #maemo-leste
<tmlind>
for an example on d4, see drivers/bluetooth/hci_ll.c
<freemangordon>
so, serdev_device_driver_register() instead of platfrom device?
<freemangordon>
sorry, not following
<tmlind>
yeah serdev_device_driver_register()
<tmlind>
grep for ti,wl1285-st for the hci_ll.c example dts
<tmlind>
when you configure a uart for a serdev device, it won't have the tty created for /dev/ttyS0
<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?
<tmlind>
right but with serdev you get quite a bit of stuff automated for you
<tmlind>
you just do serdev_write() for AT+CMUX=0
<freemangordon>
but then, who will set line discipline on the port?
<tmlind>
can't remember the name of the function, something else not serdev_write()
<freemangordon>
write_wkup() or something
<tmlind>
heh yeah setting the line discipline part is a bit open :)
<freemangordon>
so, I will need parent port tty device either ways
<tmlind>
do you need a struct tty for that?
<freemangordon>
mhm
<freemangordon>
lemme try to find the code
<freemangordon>
int tty_set_ldisc(struct tty_struct *tty, int disc)
<freemangordon>
so I need struct tty
<tmlind>
hmm
<tmlind>
well drivers/bluetooth is setting the line discpline somehow for the wlcore bluetooth example i pasted above
<freemangordon>
lemme check it
<tmlind>
i guess must be in drivers/bluetooth/hci_serdev.c
<tmlind>
as it replaces drivers/bluetooth/hci_ldisc.c for serdev devices i think
<tmlind>
hmm actually i think serdev hci does it without line discpiline
<freemangordon>
mhm
<freemangordon>
that's what I think too
<freemangordon>
maybe we can call n_gsm functions directly?
<freemangordon>
if they are exported at all
<tmlind>
heh so back to serdev-ngsm?
<freemangordon>
but without need to upstream another driver :)
<freemangordon>
lemme see if n_gsm exports any API
<tmlind>
i added some patch to export the registering in the serdev-ngsm patches
<freemangordon>
mhm
<freemangordon>
I will look upstream
<tmlind>
i think johan had some idea to make the dlci instances to use serdev too but that might get messy
<freemangordon>
nope, nothing is exported from n_gsm
<tmlind>
right
<freemangordon>
ok, lets get back to my initial plan
<freemangordon>
I just need to find the way to get from uart device_node to uart_port or something
<freemangordon>
we have kobject in device_node, is that useful for anything?