<stefan_schmidt>
well, without focus it obviously does not crash
<wpwrak>
and maybe we should start looking at those CRCs ;-)
<stefan_schmidt>
looks like your PHR fix is working as it shoudl
<stefan_schmidt>
should
<stefan_schmidt>
does it do hardware crc?
<wpwrak>
it doesn't crash ! when pressing any key, it does a clean normal exit
<wpwrak>
the chip does
<wpwrak>
the driver ignores it :)
<wpwrak>
eventually, some higher layer may catch it, but ...
<stefan_schmidt>
(crash) its a question of what I expect. :)
<stefan_schmidt>
wpwrak: it should fill the two CRC bytes with other data like rssi, lqi and a crc flag, no?
<stefan_schmidt>
I'm ignoring the packets with wrong CRC in the driver now (cc2420)
<stefan_schmidt>
besides debugging I see no use for them in the stack.
<wpwrak>
you have to read the CRC result separately
<stefan_schmidt>
urgs
<stefan_schmidt>
thats not nice
<wpwrak>
well, you can actually avoid it on the 231. you can make it return the register PHY_RSSI, which happens to include the CRC status "underneath" the first byte of any SPI command.
<wpwrak>
and you even get 2 "truly random" bits on top of that. you could feed them into the entropy pool ;-)
<wpwrak>
how's the platform manipulation working ?
<stefan_schmidt>
got sidetracked by the motorola atrix. A smartphone with android _and_ a ubuntu system side by side sounds interesting
<stefan_schmidt>
especially with a laptop dock and a normal dock available
<stefan_schmidt>
kinda the idea raster had at openmoko. Normal phone in the pocket and desktop system when docked
<stefan_schmidt>
anyway, back to coding now :)
<wpwrak>
not too bad: 10000 packets transmitted, 9999 packets received, 0% packet loss
<wpwrak>
that's on the end with lots of errors. the other side got: 10000 packets transmitted, 10000 packets received, 13 duplicates, 0% packet loss
<stefan_schmidt>
nice
<stefan_schmidt>
what size are the ping packets?
<wpwrak>
(some errors must have killed acks, hence the DUPs)
<wpwrak>
standard size, 64 bytes
<wpwrak>
round-trip min/avg/max = 11.034/11.858/81.130 ms
<wpwrak>
ben to ben
<stefan_schmidt>
plus ieee802154 header overhead
<stefan_schmidt>
thats 77 bytes
<stefan_schmidt>
or 76
<wpwrak>
yup. one byte for dirtpan, not sure if ping counts with or without IP header.
<stefan_schmidt>
maybe worth to test with full size packets sometime later
<stefan_schmidt>
but its nearly 2/3 already
<wpwrak>
i tried that a while ago. 4000 bytes. dirtpan takes care of fragmentation and reassembly.
<stefan_schmidt>
and the packet loss is nice
<stefan_schmidt>
ah, right. I always forgot as I don't use IP over it
<wpwrak>
and especially the absence of crashes ;-) i didn't like it that i kept on finding unresponsive systems after doing something else for a while.
<stefan_schmidt>
but I will steal your fragmentation and reassembly when I get to the higher layers here
<stefan_schmidt>
its also on my list :D
<wpwrak>
it's as ugly and simple as it can possibly get ;-)
<stefan_schmidt>
sure, I can expand from there. At least it is known to work
<wolfspraul>
I want my atbens! tuxbrain where are you?
<stefan_schmidt>
wpwrak: no more warnings and the driver still loads without crashing. Not to bad. :)
<stefan_schmidt>
wpwrak: the usb_device does have a struct device under ->dev. Convenient.
<wpwrak>
wolfspraul: my boards are already in buenos aires. i should get them monday. finally :)
<stefan_schmidt>
hi wolfspraul
<wpwrak>
wolfspraul: and no a day too early - i'll leave for FISL tuesday morning. well, volcano willing ...
<stefan_schmidt>
wpwrak: I should rip out all the mac802154 stuff again as is will be a simple usb<->spi driver
<wpwrak>
stefan_schmidt: yeah, you won't need that anymore :)
<stefan_schmidt>
wpwrak: and also all the sysfs debug stuff. Hardware info printing during probe. No need for sysfs there
<stefan_schmidt>
but thats later
<wolfspraul>
I'm not so lucky. Wired money to the big mega corporation, since then silence.
<stefan_schmidt>
The question now is how I get the 230 to speak to my spi master driver
<wolfspraul>
that smells like it needs some copyleft hardware competition, a NanoNote with integrated ben-wpan :-)
<wpwrak>
stefan_schmidt: ah yes, this will be a little tricky
<wpwrak>
wolfspraul: yes !! ;-)
<stefan_schmidt>
wpwrak: no board file to set it up, hmm
<wpwrak>
wolfspraul: maybe ping victor about the boards. he's usually more responsive.
<stefan_schmidt>
wolfspraul: is there space left in the case and SPI testpoints available?
<wpwrak>
stefan_schmidt: you could probably do all the formalities in atusb_init ... :)
<wpwrak>
ducks
<wolfspraul>
ah that's a long discussion. We are thinking about how to make the next NanoNote but there are many pieces that need to come together, and so far we haven't found any golden path yet.
<wolfspraul>
I wouldn't want to try to cram it into the current case.
<stefan_schmidt>
wolfspraul: ah, you plan for the next. I was thinking about a drop into for the current note
<stefan_schmidt>
ok, got it
<wpwrak>
(current case) that wouldn't work anyway
<wolfspraul>
plus once you start this thinking, you open a can of worms. Say we use the Ingenic 4760 CPU, then we would want to expose more memory cards...
<stefan_schmidt>
wpwrak: I would not mind putting it there. I just don't see how. I mean the 230 have to "find" our master somehow
<wpwrak>
up to three of then, to be precise :)
<wpwrak>
s/then/them/
<wolfspraul>
another idea is to use the Milkymist SoC for the next NanoNote, but it may be a year too early
<wpwrak>
stefan_schmidt: spi_register_board_info ? see arch/mips/jz4740/board-qi_lb60.c
<wolfspraul>
there's so much work everywhere, it's hard to find the shortest path to something we can sell today
<wolfspraul>
needs more thinking :-)
<wpwrak>
wolfspraul: yes, make the MM+NN merge later. that will needs some power management work first.
<wolfspraul>
when I finally have Milkymist One RC3 out, I will go back to that
<wolfspraul>
wpwrak: yes, I think it also needs progress on MMU and Linux, and I think most of those efforts are in deep-freeze right now. (of course can continue later, it's just too much at once)
<stefan_schmidt>
wpwrak: hmm, good point. There is no reason that can't life in our driver instead of a board file.
<stefan_schmidt>
Sometimes it sounds to easy :)
<wpwrak>
wolfspraul: Ya should be what the Ben ought to have been. properly free'd, own case, no silly performance/feature restrictions
<wolfspraul>
Maybe I do need to give myself a kick one of these days and go back to our Ingenic friends :-)
<wolfspraul>
but first m1 now...
<wolfspraul>
and waiting for my ben-wpans
<wolfspraul>
really not the best customer service there, I have to say
<wpwrak>
stefan_schmidt: there are a few variations of the theme in include/linux/spi/spi.h, right after spi_register_board_info
<rsharpe>
wpwrak: Has stefan committed his stuff yet? I checked out jz-2.6.38 but cannot see any of Stefan's code
<stefan_schmidt>
wpwrak: yeah, I actually worked with it before. But somehow I believed thats bound to board file. No idea why :)
<wpwrak>
wolfspraul: yeah, the vanishing act gets a little silly
<stefan_schmidt>
rsharpe: its in ben-wpan-stefan
<stefan_schmidt>
rsharpe: hi, btw
<rsharpe>
Yeah, I just noticed ... thanks
<stefan_schmidt>
rsharpe: but some of it will be obsolete soon. Working on the SPI master driver side now as wpwrak showed that it is possible
<wpwrak>
wolfspraul: ah, and if you can find some funding, i'd be more than happy to absolve you from most of the Ya R&D worries ;-)
<rsharpe>
stefan_schmidt: OK, I will read through the emails ...
<stefan_schmidt>
rsharpe: oki
<rsharpe>
I saw the new branches when I pulled from upstream.
<stefan_schmidt>
wpwrak, wolfspraul. What kind of FPGA is needed for m1 soc?
<wolfspraul>
right now it runs on a Xilinx Spartan-6
<wolfspraul>
using about 44% of it (slx45 variant)
<wolfspraul>
one of the design goals was portability between fpgas, so we try to stay away from Xilinx-specific features
<stefan_schmidt>
IIRC, its some time since my fpga course, that more like a high end model, right?
<wolfspraul>
but bringing it to another chip is definitely work
<stefan_schmidt>
verilog or vhdl?
<wolfspraul>
stefan_schmidt: no not at all. the spartan is the low-end series for Xilinx
<wolfspraul>
Verilog
<wpwrak>
vhdl = cobol :)
<stefan_schmidt>
wolfspraul: good to know. Brain is getting old :)
<wolfspraul>
the fpga in m1 costs about 39 USD
<rsharpe>
Yeah, verilog is great ...
<stefan_schmidt>
wpwrak: well, I had verilog as well, but vhdl is used a lot here in .de
<wolfspraul>
so is Java
<wolfspraul>
:-)
<stefan_schmidt>
wolfspraul: thats ok. And going for an asic is just no option in this quantities
<wolfspraul>
that's another long story
<stefan_schmidt>
and we can still update the soc in filed :)
<stefan_schmidt>
field
<wolfspraul>
there are multiple 'asic' approaches
<urandom__>
though 39 USD is still expesive. the spartan 3a is a lot cheaper i gues but m1 might be far to large
<wolfspraul>
there's this 'structured asic' stuff, where I believe you can make chips at volumes of a few hundred
<wpwrak>
i actually like the idea of having an fpga around. once llhdl works, there would be an awful lot you could do with it.
<stefan_schmidt>
wolfspraul: interesting. Did not know about it
<wolfspraul>
yes correct, then there are tools issues, like llhdl
<wolfspraul>
stefan_schmidt: when you 'go asic', the question is also which process technology you want, and thus which 'IP partners' you need to get into your boat (cell libraries)
<stefan_schmidt>
wolfspraul: thus I know again. But I would not like to think about all the details of IP partners. :)
<wolfspraul>
so for me that whole 'go asic' thing is about learning, understanding where it can help us to make products, and finally waiting for an economic reason/opportunity
<wolfspraul>
stefan_schmidt: well that's why I say - it depends on what you want. If you are OK in making a Milkymist SoC in a 1um process that's just something entirely different from making it in a 90nm process
<wolfspraul>
but in a 1um process, maybe in the end your chip will perform worse than in an fpga that was made in a Samsung 45nm process :-)
<wolfspraul>
or 28nm as the upcoming Xilinx -7 series
<wolfspraul>
so I look at this from product back
<stefan_schmidt>
wolfspraul: actually size should not be such a big problem. Heat and power might be more problematic. But you get experience with this on the m1
<wolfspraul>
where is the product? how many can we sell? what is the best way to build the product?
<wpwrak>
plan B: build a direct writer for wafers and let azonenberg make the asic ;-)
<wolfspraul>
yes correct
<wolfspraul>
stefan_schmidt: that's our latest mental exercise - follow azonenberg and his #homecmos project
<wolfspraul>
very cool stuff!
<wolfspraul>
we won't be able to make a Milkymist SoC in that process anytime soon, but who knows, it may at some point be possible to make some specialized chips in that way, chips that can still help us a lot with a particular product...
<wolfspraul>
I think his first big goal is to make a replica of the Intel 4004 CPU :-)
<wpwrak>
grmbl. my atusb is even too broken to act as a decent jammer :-( tries to make my pings run into trouble more often, but absolutely nothing happens. very disappointing. so i'll have to wait for "natural" errors ...
<wolfspraul>
I need to put these pics into a nice gallery...
<qi-bot>
[commit] Werner Almesberger: Revert "at86rf230: initialize unused buffers in struct spi_transfer to NULL" http://qi-hw.com/p/qi-kernel/01c171f
<qi-bot>
[commit] Werner Almesberger: at86rf230: check PHR of inbound packets and make sure frame fits into skb http://qi-hw.com/p/qi-kernel/fe7850b
<qi-bot>
[commit] Werner Almesberger: at86rf230: check PHR of inbound packets and make sure frame fits into skb http://qi-hw.com/p/qi-kernel/eb5fe3b
<wpwrak>
hmm, without indicating the branch, such commits are a tad confusing
<wpwrak>
aha. seems i have a very noisy neighbour at wifi channel 1. good, just where it causes the most interesting effects :)
<stefan_schmidt>
aaaaargh
<stefan_schmidt>
two hours checking a linking problem
<stefan_schmidt>
and it turns out that I'm not able to use spi_register_board_info in the driver
<stefan_schmidt>
and then there is this magic spi_new_device() call which takes a master and a board_info and glues them together
<stefan_schmidt>
hmm, but 230 seems still not happy
<stefan_schmidt>
anyway, its 6am and I need some sleep
<stefan_schmidt>
night all
<DocScrutinizer>
moo
<DocScrutinizer>
any issues with PM flooding recently, anybody?
<DocScrutinizer>
there's been a runaway or rogue bot at 74.63.*.*
<DocScrutinizer>
seems freenode sorted it
<dvdk>
whitequark: any news about the ubbs?
<whitequark>
dvdk: yeah, they came two days ago
<dvdk>
cool
<dvdk>
so still % of loss with german mail is 0
<whitequark>
dvdk: here in russia, germans are commonly perceived as being incredibly accurate and pedantic, even a bit obsessed about keeping things in order :)
<dvdk>
whitequark: yeah, here, too :)
<whitequark>
there's even a phrase "exemplary deutsch order". somewhat like that
<kristianpaul>
ffffffffff....
<kristianpaul>
:-/
<wpwrak>
kristianpaul: NO SATELLITES FOUND. ARE YOU INDOORS ?
<kristianpaul>
wpwrak: atenna is no indoor
<kristianpaul>
i already tested it worked with a gps receivre i have
<kristianpaul>
(fffff) just testing a different way of sampling
<kristianpaul>
i was polling froma  register, but i did something wrong surelly
<wpwrak>
kristianpaul: you suspect over/underruns ?
<wpwrak>
kristianpaul: that register is in the FPGA, right ? maybe add logic that checks for overrun/underrun and generates some signal
<kristianpaul>
yeah, i will do that better, as i was detecting overrun by reading a pointer
<kristianpaul>
a pointer coming from the counter that address the buffer
<kristianpaul>
indeed something is definetelly not good, at current sampling i just should sample 256Kb per second (considering every word is 32Bits..) and thats no true right now..
<wpwrak>
do you actually need a counter ? why not a fifo ?
<kristianpaul>
hum, you suguested the circular buffer time ago, so i implemented sort of that :)
<kristianpaul>
i remenber..
<wpwrak>
well, depends on how much data can pile up
<wpwrak>
if you need to collect lots of data, when a circular buffer is better
<wpwrak>
if you're polling anyway, a FIFO may be lighter
<wpwrak>
is the buffer fill rate correct ? e.g., when you signal beginning and end of a buffer fill (e.g., via some I/O pin) does the duration correspond to the correct buf_size/data_rate ?
<kristianpaul>
well in theory it should be correct as the counter clk is coming from the sync signal from the sige chip
<kristianpaul>
but i realize now, i may be reading same value many times.. because i wasnt taking care of overrun
<wpwrak>
"shuold be correct" means that you may be chasing a problem that's elsewhere :)
<wpwrak>
if things refuse to work as stubbornly as your data collection, it makes sense to systematically verify every single step for correctness
<kristianpaul>
but how i can measure the sampling rate?
<wpwrak>
you wouldn't be the first one to spend weeks trying to catch a bug at A while A is perfect and the real problem is an input coming from buggy B ;-)
<wpwrak>
you could raise an I/O signal when you begin collecting data, drop it when the buffer is full (or the counter wraps), then check the timing with the scope
<kristianpaul>
okay i'll try that
<kristianpaul>
when you said check timing with scope, i guess you mean that i can measure that I/O overrun signal, so i can confirm sampling rate from it
<wpwrak>
yes. you can measure the duration of the pulse (or if you use two I/Os, one to indicate start, the other to indicate wrap/overrun/end, the time between them)
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved atben_reset and at86rf230_platform_data from board to driver (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/9a7d79a
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved qi_lb60_atben platform device from board to spi_atben (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/00fded8
<qi-bot>
[commit] Werner Almesberger: spi_atben: moved spi_board_info of atben from board to spi_atben (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/b9def22
<wpwrak>
stefan_schmidt: the rest should be trivial ;-)
<stefan_schmidt>
wpwrak: let me dig through it.
<stefan_schmidt>
has also some stuff to push
<qi-bot>
[commit] Stefan Schmidt: ieee802154/atusb: Remove all ieee802154 informations again. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/38c3128
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Initial setup to be a fake spi master driver. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/5a03c6f
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Move Kconfig and Makefile handling from ieee802154 to spi (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/80b0bda
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Remove the sysfs entry for firmware build version. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/c704f64
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Move atusb_id informations to probing as well. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/f5cd312
<stefan_schmidt>
wpwrak: Lets see if we have the same solution for the spi board info in the driver now :)
<stefan_schmidt>
wpwrak: you tested yours already?
<wpwrak>
hehe :)
<wpwrak>
sure
<wpwrak>
there are still 1-2 things i need to clean up. but by and large, that's how it should work
<stefan_schmidt>
wpwrak: great
<stefan_schmidt>
wpwrak: for reset I would just use the reset command?
<stefan_schmidt>
ATUSB_RESET I mean
<rsharpe>
wpwrak: stefan_schmidt: I want to push a small change that uses snprintf rather than sprintf
<rsharpe>
Hmmm, looks like atusb.c did not get compiled in my recent build.
<wpwrak>
ATUSB_RF_RESET
<stefan_schmidt>
rsharpe: I'm not sure if that is worth it. I already removed some of the sysfs and planing to remov ethe rest once the at86rf230 driver get loaded
<stefan_schmidt>
wpwrak: ok
<stefan_schmidt>
rsharpe: the information in the files is so static that giving them during driver probe is fine IMHO
<stefan_schmidt>
and the reg reads for the 230 will come from the driver itself then
<rsharpe>
OK, so you are working on the at86rf230 driver then?
<rsharpe>
Anyway, make menuconfig does not seem to give me a way to build atusb.c or at86rf230 that I can find
<wpwrak>
btw, spi_atben is stiill only in branch ben-wpan-atben. i'll merge into ben-wpan once done with it.
<wpwrak>
rsharpe: on which branch are you ?
<stefan_schmidt>
rsharpe: the driver moved also to drivers/spi now as it will only handle spi stuff no ieee802154
<stefan_schmidt>
rsharpe: I bit rough right now
<stefan_schmidt>
I just have to change some things back as wpwrak showed that the spi master idea will work
<rsharpe>
I am on ben-wpan-stefan ...
<rsharpe>
OK, I guess I do not understand the architecture so well.
<stefan_schmidt>
rsharpe: let us help to explain it to you :)
<stefan_schmidt>
rsharpe: etben and atusb are similar as they connect a 230 over SPI to a host
<stefan_schmidt>
rsharpe: atusb uses USB for this and atben GPIOs
<stefan_schmidt>
And we don't want to re-implement the at86rf230 driver that is already there and working
<stefan_schmidt>
that is the base we start from
<stefan_schmidt>
as the given at86rf230 speaks SPI in slave mode we are implementing these driver to be the SPI master counterpart
<rsharpe>
So does the at86rf230 think it is an SPI slave to the 230 on the SPI bus?
<stefan_schmidt>
So we abstract the connection to the host in the drivers and let at86rf230 work as normally by speaking to a SPI master driver
<stefan_schmidt>
rsharpe: yes
<stefan_schmidt>
rsharpe: and thus needs no changes
<stefan_schmidt>
On the other hand that makes the atben and atusb driver simpler as they only handle data shifting without knowing about the payload
<rsharpe>
Let me look some at the at86rf230 ... does it have a way to do a software connection to another module that is pretending to be the SPI master to it?
<rsharpe>
Anyway, sounds interesting.
<stefan_schmidt>
rsharpe: That is handled by the linux spi framework already
<rsharpe>
Huh, pretty neat.
<stefan_schmidt>
rsharpe: at86rf230 is just a plain slave driver and we can setup in our driver that it gets bound to our master driver
<stefan_schmidt>
thats what in embedded normally is handled in the machine (board) file
<rsharpe>
OK, I gotta look at that some more ... I should have been on this board weeks ago ...
<wpwrak>
almost plain. it knows some gpios, reset and slp_tr
<stefan_schmidt>
wpwrak: did I miss anything or got it wrong?
<stefan_schmidt>
rsharpe: I hope you don't take this as a hostile takeover of your work. Its just that I have some time at hand right now and really need these devices working for my thesis
<wpwrak>
also, atusb can't be 100% generic spi. the firmware only implements a few transfer patterns. (optimized for what the 230/1 can do)
<stefan_schmidt>
wpwrak: its a hw dependent driver anyway. Its bound to the USB ids of the atusb board and speaks gooed enough SPI for the chip on it. :)
<rsharpe>
stefan_schmidt: I really want whatever works ... and you have just clued me in on some interesting stuff ... so no problems.
<stefan_schmidt>
rsharpe: cool, glad you see it this way!
<rsharpe>
stefan_schmidt: Also, it's "get it wrong." In English the tense goes on the first verb for the most part and we use present tense for the others (I am not sure if that is the correct explanation, just that "did I miss anything or _got_ anything wrong" is wrong :-)
<stefan_schmidt>
rsharpe: thanks
<stefan_schmidt>
:)
<rsharpe>
np. I study Mandarin and speak some Cantonese, and really wish that native speakers would correct me more often. They are just too polite.
<stefan_schmidt>
Dinner now. Will check wpwrak's latest commits after this and see what atusb can use from them
<wpwrak>
rsharpe: hmm, you'll need some thoroughly westernized chinese for that ;-)
<wpwrak>
stefan_schmidt: just finished brunch :) now, the remaining cleanup ....
<rsharpe>
So, what is needed is a driver that is an SPI master to the at86rf230 and speaks USB out the other side ...
<rsharpe>
That is kind of like a SCSI LLD that is also a SCSI Target driver, ie, scst_local ...
<rsharpe>
wpwrak: Is my understanding correct?
<wpwrak>
rsharpe: yup. in branch ben-wpan-atben, drivers/spi/spi_atben.c, there's one that does SPI -> GPIOs for atben. (similar to spi_gpio, but more efficient. plus, it takes care of all the plumbing, so no changed to the board init needed)
<rsharpe>
wpwrak: Hmmmm, the spi.h include file suggests that there is no slave-side support. Have I misunderstood this?
<wpwrak>
hmm, dunno. could be. in any case, we don't need a slave :)
<rsharpe>
OK, so I misunderstood the above then. I assumed you mean that the at86rf230 driver thought it was a slave, but it seems that it is a master and treats the chip as a slave.
<stefan_schmidt>
rsharpe: right, there is no slave support. What we need as slave support is only the protocol part
<stefan_schmidt>
rsharpe: The slave itself is the at86rf230 chip
<rsharpe>
OK, now I have that clear.
<rsharpe>
OK, more questions: wpwrak: So our driver has to register itself as an SPI master driver? That is, spi_atusb.c pretends to be an SPI controller driver and the at86rf230 is an SPI protocol driver?
<stefan_schmidt>
rsharpe: correct
<wpwrak>
yes. see spi_atben.c. the registration process is a little tricky
<rsharpe>
OK, thanks. Now I have a better mental picture.
<stefan_schmidt>
wpwrak: on atusb it is tricky as well, but different :)
<rjeffries>
anybody home this fine Saturday?
<wpwrak>
home, hacking :)
<rsharpe>
wpwrak: You are in a similar time zone to me aren't you?
<rjeffries>
cool.I just learned about the $2K fee to get a USB address block. I assume Wolfgang had tp pomy up? it really sucks.
<qi-bot>
[commit] Werner Almesberger: spi_atben: announce atben_reset and don't modify global variables (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/add45cd
<rjeffries>
is GMT +8 (usa pacific daylight time zone) is now 11:42am Saturday
<wpwrak>
rsharpe: you're still US west coast ? i'm argentina (east) coast. one hour "east" of US east cost. so somewhat similar
<wpwrak>
you guys will also need.reset_data for spi_atusb. i think all the bits and pieces are now in place.
<wpwrak>
ah, and i'll kick out the transfer classifier soonish.
<wpwrak>
that is, thinking of it ... maybe i'm not in a hurry with that. may still be useful
<rsharpe>
OK, so you are four hours ahead of me
<stefan_schmidt>
wpwrak: yeah, I was already thinking about reset_data :)
<stefan_schmidt>
wpwrak: spi_atben is now ready from your side?
<wpwrak>
yeah, should be good to copy from now
<stefan_schmidt>
wpwrak: oki
<wpwrak>
i still have to optimize the bit-banging functions a little. still got some precious cycles to squeeze out of them ;-)
<stefan_schmidt>
wpwrak: only the irq forwarding with usb irqs is unknown to me now
<wpwrak>
oh, wait. one mistake ...
<rsharpe>
wpwrak: Why do you need to bitbang the SPI stuff? Doesn't the JZ have an SPI controller on chip? Or are the pins connected to the wrong place?
<qi-bot>
[commit] Werner Almesberger: spi_atben: we set prv->board_info.platform_data later, don't mis-initialize (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/8a07eed
<wpwrak>
now it's better :)
<wpwrak>
rsharpe: the latter, unfortunately. we have a perfectly good SPI controller, doing nothing :-(
<rsharpe>
Ahhh, that is a pity :-(
<wpwrak>
yeah. the SPI pins are used for the keyboard matrix instead. a sad fate ...
<rsharpe>
OK, I begin to see some of the details for ATUSB. It has to register itself as a USB driver and as an SPI device controller, but I guess I am restating myself ...
<stefan_schmidt>
rsharpe: be aware that the code in git has some problems right now. I'm working my way through it.
<wpwrak>
the whole spi master registration bureaucracy is already covered in spi_atben. maybe we can even have some common functions shared by spi_atben and spi_atusb in the future, to avoid redundancy
<stefan_schmidt>
Just that you don't get on the wrong path :)
<rsharpe>
and don't yet see where we can hook in ... I guess I will need to read through the spi core code to understand that.
<wpwrak>
hehe. ping -s 4000 from both sides. meltdown ;-)
<wpwrak>
rsharpe: all the SPI registration is already handled in spi_atben. copy & paste is your friend :)
<stefan_schmidt>
wpwrak: some bits are different thought as as you have a struct device and we have a struct usb_device here.
<stefan_schmidt>
Needs a bit of a different handling
<stefan_schmidt>
pretty similar anyway :)
<wpwrak>
of course, if you want to review what i've done in spi_atben. that would also be useful. i also have a platform_device_register followed by platform_driver_probe in atben_init that i'm not entirely fond of. it works, but ...
<stefan_schmidt>
I'm just going through all this. Give me some time.
<wpwrak>
stefan_schmidt: usb_device ... just a pointer from atusb_prv ? the struct device is part of the SPI bureaucracy, it doesn't have much to do with what's underneath
<wpwrak>
sure :)
<stefan_schmidt>
need to reboot. Broke my system with a NULL pointer deref during modprobe :)
<stefan_schmidt>
brb
<stefan_schmidt>
wpwrak: going to split my changes in some sensible commits now and push it.
<stefan_schmidt>
wpwrak: The we can have a look why I think its different as you have a platform_device and I have a usb_device here
<stefan_schmidt>
that's different probe function parameters due to this.
<stefan_schmidt>
Maybe I don't see the easy solution.
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Move interface ignore function to the beginning of the probe function (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/b7cfe70
<qi-bot>
[commit] Stefan Schmidt: spi/atusb: Mimic atben on the latest changes for spi master. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/bf166fe
<stefan_schmidt>
wpwrak: I would be glad if you could have a look at the probe function in drivers/spi/atusb.c
<stefan_schmidt>
wpwrak: let me explain what I'm trying to do there
<stefan_schmidt>
wpwrak: I get the usb_device during probe. That one has a struct device in ->dev
<stefan_schmidt>
wpwrak: but I can't relay on spi_alloc_master for allocating my private data struct as this function already needs the struct device
<stefan_schmidt>
hmm, moment
<stefan_schmidt>
I should just use this without putting the usb device into my private struct
<stefan_schmidt>
ponders
<wpwrak>
ping -s 4000, unoptimized: round-trip min/avg/max = 521.951/538.744/665.387 ms
<wpwrak>
lightly optimized: round-trip min/avg/max = 505.119/521.531/643.175 ms
<wpwrak>
now, once i have debugged the heavily optimized version ...
<stefan_schmidt>
grumbl
<stefan_schmidt>
crashing your main machine is no fun
<wpwrak>
i can vividly imagine how badly this would suck ;-)
<stefan_schmidt>
heh
<stefan_schmidt>
wpwrak: making progress here
<stefan_schmidt>
wpwrak: at86rf230 starts probing now
<stefan_schmidt>
fails on irq as I don't provide this yet. Overruling it now
<wpwrak>
nice. you're close then :)
<stefan_schmidt>
yeah, but IRQ handling will be fun again
<stefan_schmidt>
I count on your experience for this :)
<wpwrak>
IRQ handler might be pretty easy - just reuse my stuff, then trigger the interrupt when you get an EP 1 URB
<wpwrak>
that will still give you races, but you should be able to make it at least through a basic functional test
<stefan_schmidt>
wpwrak: ok, overruling the irq was not a good idea :)
<wpwrak>
one of these days, i'll port myroot ... a ping without fractional seconds for the inter-packet delay, no calulation of stddev, ... oh the suckiness ...
<wpwrak>
stefan_schmidt: have you tried irq_alloc_desc ? if yes, what does it return ?
<stefan_schmidt>
wpwrak: not done yet. Coming to it now
<stefan_schmidt>
I hoped for a shortcut without IRQ
<stefan_schmidt>
but I need to get this up first
<wpwrak>
at least it shouldn't return 0. that's taken by the timer on PCs. 2 may be available. wonder what's there ...
<stefan_schmidt>
wpwrak: ah!! that explains one of my hard crashes. Using the timer irq number was not a good idea ;)
<wpwrak>
hmm RTC alarm
<wpwrak>
;-))
<wpwrak>
heavily optimized: round-trip min/avg/max = 498.807/517.709/640.434 ms
<wpwrak>
4 lousy milliseconds :-(((
<stefan_schmidt>
:/
<stefan_schmidt>
wpwrak: maybe optimize dirtpan as well?
<wpwrak>
you mean auto-ack ;-)
<stefan_schmidt>
wpwrak: the chip should be able to do it, right?
<stefan_schmidt>
I was able to get it working on cc2420
<stefan_schmidt>
and the 230 should do re-submit in hw as well
<wpwrak>
yeah, it can do quite a number of things automatically
<wpwrak>
including automatic CSMA-CA
<stefan_schmidt>
wpwrak: any reason that is not enabled? Just not done yet or hw problems?
<wpwrak>
just not done yet
<wpwrak>
hmm, optimized out one more writel. interesting: round-trip min/avg/max = 489.195/512.363/627.084 ms
<wpwrak>
for interrupt synchronization, i think it will be sufficient to just detect a FORCE_TX_ON write to TRX_STATE, and in this case wait ~ 10 ms for any news on EP 1
<wpwrak>
both cases where we need messy interrupt synchronization are forced transitions into TX_ON/PPL_ON
<stefan_schmidt>
hmm, fiddling with the data stream we route is not really nice imho :)
<stefan_schmidt>
even if it is only reading and only lookign for one pattern
<wpwrak>
at least it's a well-defined condition :)
<wpwrak>
anything else would be more complex
<stefan_schmidt>
hmm
<stefan_schmidt>
should be ok
<wpwrak>
actually, i should do this in spi_atben.c too. need to sync with the interrupt ... (not that this race is likely to ever go the wrong way, but ... ;-)
<wpwrak>
anyway. afk for a bit. getting my laundry.
<stefan_schmidt>
wpwrak: cu
<wpwrak>
back to hack
<wpwrak>
i wonder if there's a way to enqueue an URB at the host for reading such that it completes after one IN, whether there was DATA or a NAK from the device/gadget
<kristianpaul>
wpwrak: the overun signal should stop the acquisition or just fire a flag?
<wpwrak>
kristianpaul: how about just driving an I/O pin ? that way, you can measure with the scope. that gives you reasonably accurate time from a completely independent source
<kristianpaul>
sure
<wpwrak>
kristianpaul: what you do with the acquisition doesn't matter so much. it's just for testing that things are as expected until that point. if they are, you can proceed to the next stage. if not, well, then you'll have some fun ;-)
<kristianpaul>
stripping some wires
<wpwrak>
rejon: (trip details) thanks ! let's see how bad the delays are for my inbound flight. the volcano was busy again. not too badly this time, though.
<kristianpaul>
volcano?
<kristianpaul>
ah, you live near chile..
<wpwrak>
it's some 1500 km away, but messes up air traffic in the whole region
<qi-bot>
[commit] Werner Almesberger: spi_atben: added detection of FORCE_TX_ON commands for interrupt synchronization (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/46b0b6b