<kristianpaul>
wpwrak: btw i asked osgps developer (Clifford Kelley) about that fdopen and he said it works very well unless  another process uses too much cpu for even a short time it can produce a buffer overrun xD
<kristianpaul>
and it can very exiting have real data _but_ i lost bandwitch
<kristianpaul>
with namuru seems there is no problem at all, why? because it asumes real data, but as i have complex i just send the I and QÂ Â data from sige to the right mixers i think
<kristianpaul>
anyway, i just read that from the gp2021 datasheet so should not be a problem do same with namuru
<cmw>
kristianpaul: even at boot time when its plugged in still doesnt show up. The driver loads but i dont see it being identified or eth0 :)
<kristianpaul>
what dmesg show?
<cmw>
nothing.. just the driver loading (even when i plug it)
<kristianpaul>
i encorage you to write mail lists, there are few people having this wifi-sd card, i dont and my
<kristianpaul>
try rmmod and modprobe it may be?
<cmw>
kristianpaul: will try recompiling the kernel. It's possible its something with the stock
<cmw>
yeah tried that no go
<kristianpaul>
i dont and so i really dont know posible issues with it*
<wpwrak>
kyak: maybe you want to share some experience with the usd wlan thingy with cmw. he has one and it doesn't seem to work (or maybe the driver is busted)
<kyak>
wpwrak: it's also not working for me ;)
<wpwrak>
kyak: do you know someone who has it working ?
<zrafa>
wpwrak: you mean wifi usd thing?
<wpwrak>
zrafa: yup
<wpwrak>
zrafa: btw, welcome back on #qi-hardware ! it's been a long while ! :)
<zrafa>
wpwrak: I helped somebody but it did not work for him. I did a specific kernel for jlime for him.. but no luck. No idea why
<zrafa>
wpwrak: it was a lot of months ago via qi ML
<kyak>
wpwrak: both xiangfu and wolfspraul reported it working
<wolfspraul>
zrafa: yes, happy you are there!
<wolfspraul>
I miss your drinks
<zrafa>
wpwrak: welcome: he :-) It is hard for me to follow the irc these days.. that is why I do not get here so much. I can not read the logs either :P
<wolfspraul>
and werner's meat and wine
<zrafa>
a disaster from my side
<zrafa>
:P
<wolfspraul>
zrafa: nah that's ok, just don't forget us entirely :-)
<wolfspraul>
you get older and wiser, and then you share all the wisdom you gained here :-)
<zrafa>
wolfspraul: meat, wine, drinks : haha.. me too! :-). But only if no germany and arg are going to play some match :D
<wolfspraul>
I think I want to leave the Spectec nightmares behind
<wolfspraul>
long live ben-wpan
<wpwrak>
zrafa: ah, i thought your internet at home was working ? btw, does the heating ? ;-)
<wpwrak>
wolfspraul: yeah. more reliable than spectec ;-)
<zrafa>
wpwrak: both things work for now.. I will touch wood anyway.. (no sure if "yo toco madera" expresion exists in english)
<wpwrak>
zrafa: yeah. also in german ;-)
<zrafa>
wpwrak: great, very known it seems :)
<wpwrak>
stefan_schmidt: ahh, you're back. excellent ! :) how are the atusbs ?
<stefan_schmidt>
wpwrak: yeah, had some weekend dates. Birthday, 10 years "Abitur" meeting etc
<stefan_schmidt>
wpwrak: back to work now.
<wpwrak>
stefan_schmidt: busy week then ;-)
<stefan_schmidt>
wpwrak: reworked it to async usb and still getting scheduling while atomic
<stefan_schmidt>
wpwrak: yup, it was also my 30th birthday. means a lot planing for party etc
<stefan_schmidt>
anyway, alcohol should be gone by now and I should be able to start again
<wpwrak>
(scheduling) hmm, nasty. what's the call stack like ?
<stefan_schmidt>
ah, and I'm now using kvm with usb passthrough to avoid all this rebooting
<wpwrak>
(partying) oh yes, i had plenty of that in the last days :) yesterday, i just slept for 12 hours
<wpwrak>
module unload still not working then ?
<stefan_schmidt>
wpwrak: ha, 12 hours would have been great. I had 4 hours each night. Only came into bed when the light was back already :)
<stefan_schmidt>
wpwrak: Doing all build-in tests with kvm now.
<wpwrak>
the nights before the 12 hours were significantly shorter :)
<stefan_schmidt>
Will come back to this topic once the other stuff works
<stefan_schmidt>
heh
<wpwrak>
(modules) okay
<stefan_schmidt>
hmm, I can copy'n'paste the call stack from kvm
<stefan_schmidt>
s/can/can't/
<stefan_schmidt>
wpwrak: give me a moment to figure this out
<wpwrak>
screen dump ?
<unclouded>
is CONFIG_MAC802154 absolutely essential for dirtpan to work?  The 2.6.39-3 Ubuntu kernel has CONFIG_IEEE802154 and CONFIG_IEEE802154_DRIVERS as modules but CONFIG_MAC802154 isn't mentioned.  does this mean I won't be able to use this kernel for dirtpan?
<wpwrak>
hmm, i would think it is needed, yes. haven't tested that hypothesis, though
<unclouded>
do you think it's worth me trying without it to find out?
<wpwrak>
ah yes, you need it. things like the function that calls xmit are in there ;)
<wpwrak>
oh wait
<stefan_schmidt>
unclouded: you need it. The at86rf230 driver needs it
<stefan_schmidt>
and the driver is not in mainline yet due to this
<stefan_schmidt>
wpwrak: (screen dump) thats lazy
<wpwrak>
no. it's like that. you need it.
<unclouded>
ah ok, that will explain why it isn't in a packaged Ubuntu kernel
<wpwrak>
(lazy) if it works ... :)
<stefan_schmidt>
unclouded: yeah, its only in the linux-zigbee tree right now. The other parts you are seeing are already upstream
<stefan_schmidt>
wpwrak: pfft :)
<unclouded>
ok, will see if I can patch the Ubuntu kernel with it
<stefan_schmidt>
wpwrak: I'm still doing the wait_for_completion in the same function doing the urb_submit. Did not wrap my head around doing a full dispatcher here
<stefan_schmidt>
wpwrak: that could well be the problem. Never worked on a async usb driver before
<wpwrak>
wait_for_completion is pretty obviously wrong :)
<wpwrak>
now. let's see what you could use instead ...
<stefan_schmidt>
wpwrak: well, thats what I have seen in other usb drivers
<wpwrak>
not in async ones that actually worked :)
<stefan_schmidt>
hmm
<stefan_schmidt>
ponders and does a grep
<stefan_schmidt>
ponders more and should read the wait_for_completion implementation...
<wpwrak>
no no .. wait_for_completion sleeps. that's all you need to know about the implementation :)
<wpwrak>
your async function can't call anything that sleeps
<wpwrak>
in atusb_usb_cb, instead of calling complete, you should call (spi_)msg->complete(msg->context)
<wpwrak>
basically move everything after calling read1 into the callback. now there's one more difficulty: some messages have two transfers
<stefan_schmidt>
wpwrak: drivers/usb/usb-skeleton.c was the one I peaked into
<stefan_schmidt>
wpwrak: And yes, sleeping and async does not make sense together
<wpwrak>
so you'd need to chain them in the callback. maybe move the urb submission simply into a suitable function that takes a struct spi_transfer and that calls a callback when done
<wpwrak>
(usb-skeleton) skel_read isn't async
<stefan_schmidt>
wpwrak: grr, why don' they use the sync usb api then. Fooling me all over :)
<wpwrak>
and you need to set master->bus_lock_flag. else, you may get new requests while still working on an older one
<wpwrak>
see also drivers/spi/spi.c:spi_async
<stefan_schmidt>
wpwrak: so in summary: Kick off the completion stuff, move msg->complete and msg->status into the callback and set the bus_lock_flag
<stefan_schmidt>
wpwrak: and as second step take care of messages with two transfers
<wpwrak>
yes. you can do bus_lock_flag later. you're probably nicely synchronized from the callers anyway
<stefan_schmidt>
ok, lets see how this works out
<wpwrak>
(2nd step) or do them both at once. what you want is a function that submits the "next" transfer.
<wpwrak>
btw, since spi_atben.c is now in the ben-wpan branch, i just deleted the ben-wpan-atben branch
<wpwrak>
stefan_schmidt: btw2, i'll remove the interrupt redirection from spi_atben soon, since i can just pass the real interrupt. so if you want a copy of that code, you'll make it now or dig a bit into the history
<stefan_schmidt>
wpwrak: just mention interrupt redirection in the commit message and I get it from there
<stefan_schmidt>
wpwrak: already merging the plain ben-wpan branch nowadays
<qi-bot>
[commit] Werner Almesberger: switch linux-zigbee tools source from (old) tarball to git repository (master) http://qi-hw.com/p/ben-wpan/ae348fb
<qi-bot>
[commit] Werner Almesberger: tools/Makefile (BEN_DIRS): add dirtpan iff its lowpan tools dependency is met (master) http://qi-hw.com/p/ben-wpan/71f095d
<qi-bot>
[commit] Werner Almesberger: tools/: moved get_key from atrf-path/gui.c to libatrf, for sharing (master) http://qi-hw.com/p/ben-wpan/56f8b2d
<qi-bot>
[commit] Werner Almesberger: tools/atrf-rssi/gui.c (gui): accept keyboard input both from stdin and SDL (master) http://qi-hw.com/p/ben-wpan/10f618a
<qi-bot>
[commit] Werner Almesberger: Merge branch 'master' of projects.qi-hardware.com:ben-wpan (master) http://qi-hw.com/p/ben-wpan/f279907
<wolfspraul>
wpwrak: good morning :-)
<wolfspraul>
so you are back in Buenos Aires now?
<wolfspraul>
what's your take in FISL?
<wpwrak>
wolfspraul: yup, back home and well rested :)
<wpwrak>
wolfspraul: it was pretty good. people liked what rejon and i said and had to show. we may get a few customers for ben, atben/atusb, and M1 :)
<wolfspraul>
any wisdom you learnt that I should now learn from you?
<wolfspraul>
how many people were there? how many young people (say < 25, or < 20)?
<wpwrak>
wolfspraul: one guy was also starting to think of producing things in brazil (to escape the horrendous import taxes). he has done some small things already. he's also thinking of making a wpan+arduino blend.
<wolfspraul>
nice
<wpwrak>
at the talks ? hmm, mine had about 50. rejon got 30-40. define "young" :)
<wolfspraul>
young < 25 years old, or better yet < 20 years old
<wpwrak>
people were very excited about the M1 demos
<wolfspraul>
I hope a download link for your talk will emerge