2011-06-25 00:00 wpwrak: Why do you have this line of code? 2011-06-25 00:00 prv = spi_master_get_devdata(master); 2011-06-25 00:01 prv is atben_usb and master gets in atben->master one line later 2011-06-25 00:01 prv->master = master; 2011-06-25 00:01 because my private structure was allocated when i got the master 2011-06-25 00:01 I have seen this before in other drivers. Never understood 2011-06-25 00:01 prv->master is my pointer back to the master. not sure if i actually need it ... 2011-06-25 00:01 some spi foo 2011-06-25 00:02 well, master is clear but devdata() to the atben struct looked odd 2011-06-25 00:02 that's what other spi drivers do. i didn't bother finding out if they're right ;-) (well, i looked mainly at the s3c24xx driver) 2011-06-25 00:03 yeah, I have seen it at other spi drivers as well but never understood why 2011-06-25 00:03 well, lets keep it :) 2011-06-25 00:03 spi_alloc_master gets the size of your "private" data block and allocates it for you 2011-06-25 00:03 spi_master_get_devdata just give you the pointer to your area 2011-06-25 00:04 ah! 2011-06-25 00:04 no I get it. 2011-06-25 00:04 I have a pointer to master in atben but the master driver needs a pointer to the private data (atben) as well 2011-06-25 00:04 makes sense :) 2011-06-25 00:04 the pings are going strong: [ 3737.570000] at86rf230 spi2.0: PHR 0xaa >= buffer 128 bytes 2011-06-25 00:05 the master driver being spi_atben, yes 2011-06-25 00:05 cool 2011-06-25 00:11 how about this ? http://downloads.qi-hardware.com/people/werner/wpan/tmp/rssi-wlan-tees.png 2011-06-25 00:12 wpwrak: indicating wifi activity on this channels? 2011-06-25 00:13 try it. atrf-rssi -g 2011-06-25 00:13 it'll look more interesting on your machine 2011-06-25 00:13 (my the atusb board i'm using is half-dead. can't wait to actually get some working boards on monday :) 2011-06-25 00:14 s/my// 2011-06-25 00:14 the blue tees are static. they indicate the US channel assignment. still have to add a means to switch to EU. 2011-06-25 00:16 fancy 2011-06-25 00:16 actually need to shrink the lines a bit. otherwise they'd overlap with the EU assignment. 2011-06-25 00:16 the "pikes" are data it sees on the channels? 2011-06-25 00:17 the peaks are just some signal. it doesn't try to demodulate, just measures the power 2011-06-25 00:17 ouch, switching the workspace kills the sdl app :) 2011-06-25 00:17 all very crude. super-simple spectrum analyzer 2011-06-25 00:17 yeah, sorry, wrong wording I meant signal not data 2011-06-25 00:17 wrong layer :) 2011-06-25 00:17 switching my virtual screens doesn't. you should use fvwm ;-) 2011-06-25 00:18 thinks about is as to prepare some nice pictures for the thesis :) 2011-06-25 00:18 wpwrak: enlightenemnt e17 here 2011-06-25 00:18 your thesis will about meshes, right ? 2011-06-25 00:18 I'm pretty sure raster thinks its your app ;) 2011-06-25 00:18 wpwrak: no 2011-06-25 00:18 ;-)) 2011-06-25 00:18 wpwrak: delay tolerant networking over ieee802154 2011-06-25 00:19 my main work is to extend out convergence layer for it which I wrote during my study thesis 2011-06-25 00:19 ah :) good. not the stylish nonsense everyone else tries their luck at :) 2011-06-25 00:19 but right now I'm sitting in the low level hell :) 2011-06-25 00:20 what sort of application would run over that delay tolerance layer ? 2011-06-25 00:20 wpwrak: Not that I'm so much interested in delay tolerant networking (DTN) but its a nice thesis after all 2011-06-25 00:20 wpwrak: whatever you like 2011-06-25 00:20 we also have video streaming over it :) 2011-06-25 00:21 in combination with ieee802154 we want to use it in wireless sensor networks 2011-06-25 00:21 so I would bridge between 802154 and standard IP/TCP/UDP 2011-06-25 00:22 catching data from the sensor nodes and bringing it inot the main network 2011-06-25 00:22 ah, i see. so typically very large delays 2011-06-25 00:23 (sdl crash) its actually just pressing alt that kills it here 2011-06-25 00:23 yeah, driving around now and the and collect data 2011-06-25 00:23 ah yes, i implemented the "any key" quite literally ;-) 2011-06-25 00:23 heh 2011-06-25 00:23 "its a feature" 2011-06-25 00:24 that means you switch workspaces by mice? 2011-06-25 00:24 (feature) it actually is :) 2011-06-25 00:24 no, but my workspaces are larger than 320x200 pixels :) 2011-06-25 00:25 more network trouble: [ 4612.960000] ieee802154: Bad frame received (type = 5) 2011-06-25 00:25 [ 4857.990000] at86rf230 spi2.0: PHR 0x9a >= buffer 128 bytes 2011-06-25 00:25 and still continuing. very good. 2011-06-25 00:25 well, without focus it obviously does not crash 2011-06-25 00:25 and maybe we should start looking at those CRCs ;-) 2011-06-25 00:25 looks like your PHR fix is working as it shoudl 2011-06-25 00:25 should 2011-06-25 00:26 does it do hardware crc? 2011-06-25 00:26 it doesn't crash ! when pressing any key, it does a clean normal exit 2011-06-25 00:26 the chip does 2011-06-25 00:26 the driver ignores it :) 2011-06-25 00:27 eventually, some higher layer may catch it, but ... 2011-06-25 00:27 (crash) its a question of what I expect. :) 2011-06-25 00:28 wpwrak: it should fill the two CRC bytes with other data like rssi, lqi and a crc flag, no? 2011-06-25 00:28 I'm ignoring the packets with wrong CRC in the driver now (cc2420) 2011-06-25 00:29 besides debugging I see no use for them in the stack. 2011-06-25 00:29 you have to read the CRC result separately 2011-06-25 00:30 urgs 2011-06-25 00:30 thats not nice 2011-06-25 00:31 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. 2011-06-25 00:33 and you even get 2 "truly random" bits on top of that. you could feed them into the entropy pool ;-) 2011-06-25 00:33 heh 2011-06-25 00:54 [commit] Werner Almesberger: tools/atrf-rssi/: added WLAN channel display (US, EU, and JP) http://qi-hw.com/p/ben-wpan/9af0f93 2011-06-25 00:54 stefan_schmidt: use E, J, U to select regulation domain, Q to quit 2011-06-25 00:55 wpwrak: you are such an UI hacker 2011-06-25 00:55 ;-) 2011-06-25 00:55 still 3000 pings to go 2011-06-25 00:55 two more bad PHRs 2011-06-25 00:56 works great 2011-06-25 00:56 hmm, I'm fighting with having a usb_register for the usb side and a platform_register for the fake spi side 2011-06-25 00:57 they don't want to go with one generic probe and remove functions 2011-06-25 00:57 wrong device struct type as params 2011-06-25 00:57 but when I have to I need to sync the private data struct somehow 2011-06-25 00:58 i would just overwrite spi->dev.platwhatever 2011-06-25 00:58 in atben_setup 2011-06-25 01:01 hmm 2011-06-25 01:01 not really elegant 2011-06-25 01:01 but maybe it does the job 2011-06-25 01:01 that's exactly the idea ;-) 2011-06-25 01:31 [commit] Werner Almesberger: tools/atrf-rssi/: added menu for regulation area selection http://qi-hw.com/p/ben-wpan/5392401 2011-06-25 01:31 stefan_schmidt: more GUI fun :) 2011-06-25 01:32 wpwrak: yay :) 2011-06-25 01:34 700 pings to go ... 2011-06-25 01:34 how's the platform manipulation working ? 2011-06-25 01:38 got sidetracked by the motorola atrix. A smartphone with android _and_ a ubuntu system side by side sounds interesting 2011-06-25 01:38 especially with a laptop dock and a normal dock available 2011-06-25 01:39 kinda the idea raster had at openmoko. Normal phone in the pocket and desktop system when docked 2011-06-25 01:39 anyway, back to coding now :) 2011-06-25 01:51 not too bad: 10000 packets transmitted, 9999 packets received, 0% packet loss 2011-06-25 01:51 that's on the end with lots of errors. the other side got: 10000 packets transmitted, 10000 packets received, 13 duplicates, 0% packet loss 2011-06-25 01:52 nice 2011-06-25 01:52 what size are the ping packets? 2011-06-25 01:53 (some errors must have killed acks, hence the DUPs) 2011-06-25 01:53 standard size, 64 bytes 2011-06-25 01:53 round-trip min/avg/max = 11.034/11.858/81.130 ms 2011-06-25 01:53 ben to ben 2011-06-25 01:53 plus ieee802154 header overhead 2011-06-25 01:53 thats 77 bytes 2011-06-25 01:53 or 76 2011-06-25 01:54 yup. one byte for dirtpan, not sure if ping counts with or without IP header. 2011-06-25 01:54 maybe worth to test with full size packets sometime later 2011-06-25 01:54 but its nearly 2/3 already 2011-06-25 01:55 i tried that a while ago. 4000 bytes. dirtpan takes care of fragmentation and reassembly. 2011-06-25 01:55 and the packet loss is nice 2011-06-25 01:55 ah, right. I always forgot as I don't use IP over it 2011-06-25 01:56 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. 2011-06-25 01:56 but I will steal your fragmentation and reassembly when I get to the higher layers here 2011-06-25 01:56 its also on my list :D 2011-06-25 01:56 it's as ugly and simple as it can possibly get ;-) 2011-06-25 01:56 sure, I can expand from there. At least it is known to work 2011-06-25 01:57 I want my atbens! tuxbrain where are you? 2011-06-25 01:59 wpwrak: no more warnings and the driver still loads without crashing. Not to bad. :) 2011-06-25 01:59 wpwrak: the usb_device does have a struct device under ->dev. Convenient. 2011-06-25 02:00 wolfspraul: my boards are already in buenos aires. i should get them monday. finally :) 2011-06-25 02:00 hi wolfspraul 2011-06-25 02:00 wolfspraul: and no a day too early - i'll leave for FISL tuesday morning. well, volcano willing ... 2011-06-25 02:00 wpwrak: I should rip out all the mac802154 stuff again as is will be a simple usb<->spi driver 2011-06-25 02:01 stefan_schmidt: yeah, you won't need that anymore :) 2011-06-25 02:01 wpwrak: and also all the sysfs debug stuff. Hardware info printing during probe. No need for sysfs there 2011-06-25 02:01 but thats later 2011-06-25 02:02 I'm not so lucky. Wired money to the big mega corporation, since then silence. 2011-06-25 02:02 The question now is how I get the 230 to speak to my spi master driver 2011-06-25 02:02 that smells like it needs some copyleft hardware competition, a NanoNote with integrated ben-wpan :-) 2011-06-25 02:03 stefan_schmidt: ah yes, this will be a little tricky 2011-06-25 02:03 wolfspraul: yes !! ;-) 2011-06-25 02:03 wpwrak: no board file to set it up, hmm 2011-06-25 02:03 wolfspraul: maybe ping victor about the boards. he's usually more responsive. 2011-06-25 02:03 wolfspraul: is there space left in the case and SPI testpoints available? 2011-06-25 02:04 stefan_schmidt: you could probably do all the formalities in atusb_init ... :) 2011-06-25 02:04 ducks 2011-06-25 02:05 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. 2011-06-25 02:05 I wouldn't want to try to cram it into the current case. 2011-06-25 02:05 wolfspraul: ah, you plan for the next. I was thinking about a drop into for the current note 2011-06-25 02:06 ok, got it 2011-06-25 02:06 (current case) that wouldn't work anyway 2011-06-25 02:06 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... 2011-06-25 02:06 wpwrak: I would not mind putting it there. I just don't see how. I mean the 230 have to "find" our master somehow 2011-06-25 02:06 up to three of then, to be precise :) 2011-06-25 02:06 s/then/them/ 2011-06-25 02:06 another idea is to use the Milkymist SoC for the next NanoNote, but it may be a year too early 2011-06-25 02:07 stefan_schmidt: spi_register_board_info ? see arch/mips/jz4740/board-qi_lb60.c 2011-06-25 02:07 there's so much work everywhere, it's hard to find the shortest path to something we can sell today 2011-06-25 02:07 needs more thinking :-) 2011-06-25 02:07 wolfspraul: yes, make the MM+NN merge later. that will needs some power management work first. 2011-06-25 02:07 when I finally have Milkymist One RC3 out, I will go back to that 2011-06-25 02:08 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) 2011-06-25 02:08 wpwrak: hmm, good point. There is no reason that can't life in our driver instead of a board file. 2011-06-25 02:08 Sometimes it sounds to easy :) 2011-06-25 02:08 wolfspraul: Ya should be what the Ben ought to have been. properly free'd, own case, no silly performance/feature restrictions 2011-06-25 02:09 Maybe I do need to give myself a kick one of these days and go back to our Ingenic friends :-) 2011-06-25 02:09 but first m1 now... 2011-06-25 02:09 and waiting for my ben-wpans 2011-06-25 02:09 really not the best customer service there, I have to say 2011-06-25 02:10 stefan_schmidt: there are a few variations of the theme in include/linux/spi/spi.h, right after spi_register_board_info 2011-06-25 02:10 wpwrak: Has stefan committed his stuff yet? I checked out jz-2.6.38 but cannot see any of Stefan's code 2011-06-25 02:11 wpwrak: yeah, I actually worked with it before. But somehow I believed thats bound to board file. No idea why :) 2011-06-25 02:11 wolfspraul: yeah, the vanishing act gets a little silly 2011-06-25 02:11 rsharpe: its in ben-wpan-stefan 2011-06-25 02:11 rsharpe: hi, btw 2011-06-25 02:11 Yeah, I just noticed ... thanks 2011-06-25 02:12 rsharpe: but some of it will be obsolete soon. Working on the SPI master driver side now as wpwrak showed that it is possible 2011-06-25 02:13 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 ;-) 2011-06-25 02:17 stefan_schmidt: OK, I will read through the emails ... 2011-06-25 02:17 rsharpe: oki 2011-06-25 02:17 I saw the new branches when I pulled from upstream. 2011-06-25 02:17 wpwrak, wolfspraul. What kind of FPGA is needed for m1 soc? 2011-06-25 02:18 right now it runs on a Xilinx Spartan-6 2011-06-25 02:18 using about 44% of it (slx45 variant) 2011-06-25 02:19 one of the design goals was portability between fpgas, so we try to stay away from Xilinx-specific features 2011-06-25 02:19 IIRC, its some time since my fpga course, that more like a high end model, right? 2011-06-25 02:19 but bringing it to another chip is definitely work 2011-06-25 02:19 verilog or vhdl? 2011-06-25 02:19 stefan_schmidt: no not at all. the spartan is the low-end series for Xilinx 2011-06-25 02:20 Verilog 2011-06-25 02:20 vhdl = cobol :) 2011-06-25 02:20 wolfspraul: good to know. Brain is getting old :) 2011-06-25 02:20 the fpga in m1 costs about 39 USD 2011-06-25 02:20 Yeah, verilog is great ... 2011-06-25 02:20 wpwrak: well, I had verilog as well, but vhdl is used a lot here in .de 2011-06-25 02:21 so is Java 2011-06-25 02:21 :-) 2011-06-25 02:21 wolfspraul: thats ok. And going for an asic is just no option in this quantities 2011-06-25 02:21 that's another long story 2011-06-25 02:21 and we can still update the soc in filed :) 2011-06-25 02:21 field 2011-06-25 02:21 there are multiple 'asic' approaches 2011-06-25 02:22 though 39 USD is still expesive. the spartan 3a is a lot cheaper i gues but m1 might be far to large 2011-06-25 02:22 there's this 'structured asic' stuff, where I believe you can make chips at volumes of a few hundred 2011-06-25 02:22 i actually like the idea of having an fpga around. once llhdl works, there would be an awful lot you could do with it. 2011-06-25 02:22 wolfspraul: interesting. Did not know about it 2011-06-25 02:22 yes correct, then there are tools issues, like llhdl 2011-06-25 02:23 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) 2011-06-25 02:23 wolfspraul: thus I know again. But I would not like to think about all the details of IP partners. :) 2011-06-25 02:23 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 2011-06-25 02:24 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 2011-06-25 02:24 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 :-) 2011-06-25 02:25 or 28nm as the upcoming Xilinx -7 series 2011-06-25 02:25 so I look at this from product back 2011-06-25 02:25 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 2011-06-25 02:25 where is the product? how many can we sell? what is the best way to build the product? 2011-06-25 02:25 plan B: build a direct writer for wafers and let azonenberg make the asic ;-) 2011-06-25 02:25 yes correct 2011-06-25 02:26 stefan_schmidt: that's our latest mental exercise - follow azonenberg and his #homecmos project 2011-06-25 02:26 very cool stuff! 2011-06-25 02:26 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... 2011-06-25 02:27 it's not further away than llhdl :-) 2011-06-25 02:30 that's his chipmaking lab http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-06-10/S7300808.JPG 2011-06-25 02:30 I think his first big goal is to make a replica of the Intel 4004 CPU :-) 2011-06-25 02:30 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 ... 2011-06-25 02:31 sorry wrong url, one sec 2011-06-25 02:32 this is the lab http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-06-10/S7300809.JPG 2011-06-25 02:32 i was about to ask in which of the boxes he sleeps ;-) 2011-06-25 02:34 wpwrak: usrp? 2011-06-25 02:34 (lab) nice and compact :) 2011-06-25 02:34 stefan_schmidt: yeah, i could fire up the usrp. that one's good for jam sessions. 2011-06-25 02:36 chipmaking http://colossus.cs.rpi.edu/~azonenberg/images/homecmos/2011-06-08/S7300798.JPG 2011-06-25 02:36 I need to put these pics into a nice gallery... 2011-06-25 03:21 [commit] Werner Almesberger: Revert "at86rf230: initialize unused buffers in struct spi_transfer to NULL" http://qi-hw.com/p/qi-kernel/01c171f 2011-06-25 03:21 [commit] Werner Almesberger: at86rf230: check PHR of inbound packets and make sure frame fits into skb http://qi-hw.com/p/qi-kernel/fe7850b 2011-06-25 03:22 [commit] Werner Almesberger: at86rf230: check PHR of inbound packets and make sure frame fits into skb http://qi-hw.com/p/qi-kernel/eb5fe3b 2011-06-25 03:23 hmm, without indicating the branch, such commits are a tad confusing 2011-06-25 03:35 aha. seems i have a very noisy neighbour at wifi channel 1. good, just where it causes the most interesting effects :) 2011-06-25 03:51 aaaaargh 2011-06-25 03:51 two hours checking a linking problem 2011-06-25 03:52 and it turns out that I'm not able to use spi_register_board_info in the driver 2011-06-25 03:52 and then there is this magic spi_new_device() call which takes a master and a board_info and glues them together 2011-06-25 03:53 hmm, but 230 seems still not happy 2011-06-25 03:54 anyway, its 6am and I need some sleep 2011-06-25 03:54 night all 2011-06-25 08:51 moo 2011-06-25 08:52 any issues with PM flooding recently, anybody? 2011-06-25 08:52 there's been a runaway or rogue bot at 74.63.*.* 2011-06-25 08:52 seems freenode sorted it 2011-06-25 11:22 whitequark: any news about the ubbs? 2011-06-25 12:04 dvdk: yeah, they came two days ago 2011-06-25 12:12 cool 2011-06-25 12:12 so still % of loss with german mail is 0 2011-06-25 12:21 dvdk: here in russia, germans are commonly perceived as being incredibly accurate and pedantic, even a bit obsessed about keeping things in order :) 2011-06-25 12:21 whitequark: yeah, here, too :) 2011-06-25 12:22 there's even a phrase "exemplary deutsch order". somewhat like that 2011-06-25 14:49 ffffffffff.... 2011-06-25 14:49 :-/ 2011-06-25 15:00 kristianpaul: NO SATELLITES FOUND. ARE YOU INDOORS ? 2011-06-25 15:01 wpwrak: atenna is no indoor 2011-06-25 15:01 i already tested it worked with a gps receivre i have 2011-06-25 15:02 (fffff) just testing a different way of sampling 2011-06-25 15:02 i was polling fromaÂ Â register, but i did something wrong surelly 2011-06-25 15:06 kristianpaul: you suspect over/underruns ? 2011-06-25 15:07 kristianpaul: that register is in the FPGA, right ? maybe add logic that checks for overrun/underrun and generates some signal 2011-06-25 15:08 yeah, i will do that better, as i was detecting overrun by reading a pointer 2011-06-25 15:10 a pointer coming from the counter that address the buffer 2011-06-25 15:20 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.. 2011-06-25 15:20 do you actually need a counter ? why not a fifo ? 2011-06-25 15:20 hum, you suguested the circular buffer time ago, so i implemented sort of that :) 2011-06-25 15:20 i remenber.. 2011-06-25 15:21 well, depends on how much data can pile up 2011-06-25 15:22 if you need to collect lots of data, when a circular buffer is better 2011-06-25 15:22 if you're polling anyway, a FIFO may be lighter 2011-06-25 15:23 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 ? 2011-06-25 15:24 well in theory it should be correct as the counter clk is coming from the sync signal from the sige chip 2011-06-25 15:25 but i realize now, i may be reading same value many times.. because i wasnt taking care of overrun 2011-06-25 15:26 "shuold be correct" means that you may be chasing a problem that's elsewhere :) 2011-06-25 15:27 if things refuse to work as stubbornly as your data collection, it makes sense to systematically verify every single step for correctness 2011-06-25 15:27 but how i can measure the sampling rate? 2011-06-25 15:27 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 ;-) 2011-06-25 15:28 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 2011-06-25 15:33 okay i'll try that 2011-06-25 15:34 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 2011-06-25 15:47 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) 2011-06-25 17:10 [commit] Werner Almesberger: spi_atben: added section titles (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/4926b10 2011-06-25 17:10 [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 2011-06-25 17:10 [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 2011-06-25 17:10 [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 2011-06-25 17:10 [commit] Werner Almesberger: spi_atben: allocate SPIP bus_num dynamically (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/e08d156 2011-06-25 17:10 [commit] Werner Almesberger: spi_atben: some cleanup (ben-wpan-atben) http://qi-hw.com/p/qi-kernel/3e7de60 2011-06-25 17:12 stefan_schmidt: the rest should be trivial ;-) 2011-06-25 17:13 wpwrak: let me dig through it. 2011-06-25 17:13 has also some stuff to push 2011-06-25 17:13 [commit] Stefan Schmidt: ieee802154/atusb: Remove all ieee802154 informations again. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/38c3128 2011-06-25 17:13 [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 2011-06-25 17:13 [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 2011-06-25 17:13 [commit] Stefan Schmidt: spi/atusb: Remove the sysfs entry for firmware build version. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/c704f64 2011-06-25 17:13 [commit] Stefan Schmidt: spi/atusb: Move atusb_id informations to probing as well. (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/f5cd312 2011-06-25 17:13 [commit] Stefan Schmidt: spi/atusb: Clean up error path in probing and removing (ben-wpan-stefan) http://qi-hw.com/p/qi-kernel/cba21e8 2011-06-25 17:14 wpwrak: Lets see if we have the same solution for the spi board info in the driver now :) 2011-06-25 17:14 wpwrak: you tested yours already? 2011-06-25 17:14 hehe :) 2011-06-25 17:14 sure 2011-06-25 17:17 there are still 1-2 things i need to clean up. but by and large, that's how it should work 2011-06-25 17:17 wpwrak: great 2011-06-25 17:18 wpwrak: for reset I would just use the reset command? 2011-06-25 17:18 ATUSB_RESET I mean 2011-06-25 17:19 wpwrak: stefan_schmidt: I want to push a small change that uses snprintf rather than sprintf 2011-06-25 17:19 Hmmm, looks like atusb.c did not get compiled in my recent build. 2011-06-25 17:20 ATUSB_RF_RESET 2011-06-25 17:20 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 2011-06-25 17:20 wpwrak: ok 2011-06-25 17:22 rsharpe: the information in the files is so static that giving them during driver probe is fine IMHO 2011-06-25 17:22 and the reg reads for the 230 will come from the driver itself then 2011-06-25 17:22 OK, so you are working on the at86rf230 driver then? 2011-06-25 17:23 Anyway, make menuconfig does not seem to give me a way to build atusb.c or at86rf230 that I can find 2011-06-25 17:23 btw, spi_atben is stiill only in branch ben-wpan-atben. i'll merge into ben-wpan once done with it. 2011-06-25 17:24 rsharpe: on which branch are you ? 2011-06-25 17:24 rsharpe: the driver moved also to drivers/spi now as it will only handle spi stuff no ieee802154 2011-06-25 17:24 rsharpe: I bit rough right now 2011-06-25 17:25 I just have to change some things back as wpwrak showed that the spi master idea will work 2011-06-25 17:25 I am on ben-wpan-stefan ... 2011-06-25 17:26 OK, I guess I do not understand the architecture so well. 2011-06-25 17:26 rsharpe: let us help to explain it to you :) 2011-06-25 17:27 rsharpe: etben and atusb are similar as they connect a 230 over SPI to a host 2011-06-25 17:27 rsharpe: atusb uses USB for this and atben GPIOs 2011-06-25 17:28 And we don't want to re-implement the at86rf230 driver that is already there and working 2011-06-25 17:28 that is the base we start from 2011-06-25 17:29 as the given at86rf230 speaks SPI in slave mode we are implementing these driver to be the SPI master counterpart 2011-06-25 17:30 So does the at86rf230 think it is an SPI slave to the 230 on the SPI bus? 2011-06-25 17:30 So we abstract the connection to the host in the drivers and let at86rf230 work as normally by speaking to a SPI master driver 2011-06-25 17:30 rsharpe: yes 2011-06-25 17:30 rsharpe: and thus needs no changes 2011-06-25 17:31 On the other hand that makes the atben and atusb driver simpler as they only handle data shifting without knowing about the payload 2011-06-25 17:31 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? 2011-06-25 17:31 Anyway, sounds interesting. 2011-06-25 17:31 rsharpe: That is handled by the linux spi framework already 2011-06-25 17:31 Huh, pretty neat. 2011-06-25 17:32 rsharpe: at86rf230 is just a plain slave driver and we can setup in our driver that it gets bound to our master driver 2011-06-25 17:32 thats what in embedded normally is handled in the machine (board) file 2011-06-25 17:35 OK, I gotta look at that some more ... I should have been on this board weeks ago ... 2011-06-25 17:35 almost plain. it knows some gpios, reset and slp_tr 2011-06-25 17:35 wpwrak: did I miss anything or got it wrong? 2011-06-25 17:36 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 2011-06-25 17:37 also, atusb can't be 100% generic spi. the firmware only implements a few transfer patterns. (optimized for what the 230/1 can do) 2011-06-25 17:38 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. :) 2011-06-25 17:38 stefan_schmidt: I really want whatever works ... and you have just clued me in on some interesting stuff ... so no problems. 2011-06-25 17:38 rsharpe: cool, glad you see it this way! 2011-06-25 17:40 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 :-) 2011-06-25 17:40 rsharpe: thanks 2011-06-25 17:41 :) 2011-06-25 17:41 np. I study Mandarin and speak some Cantonese, and really wish that native speakers would correct me more often. They are just too polite. 2011-06-25 17:48 Dinner now. Will check wpwrak's latest commits after this and see what atusb can use from them 2011-06-25 17:48 rsharpe: hmm, you'll need some thoroughly westernized chinese for that ;-) 2011-06-25 17:48 stefan_schmidt: just finished brunch :) now, the remaining cleanup .... 2011-06-25 17:53 So, what is needed is a driver that is an SPI master to the at86rf230 and speaks USB out the other side ... 2011-06-25 17:53 That is kind of like a SCSI LLD that is also a SCSI Target driver, ie, scst_local ... 2011-06-25 17:56 wpwrak: Is my understanding correct? 2011-06-25 17:56 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) 2011-06-25 18:15 wpwrak: Hmmmm, the spi.h include file suggests that there is no slave-side support. Have I misunderstood this? 2011-06-25 18:16 hmm, dunno. could be. in any case, we don't need a slave :) 2011-06-25 18:17 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. 2011-06-25 18:18 rsharpe: right, there is no slave support. What we need as slave support is only the protocol part 2011-06-25 18:18 rsharpe: The slave itself is the at86rf230 chip 2011-06-25 18:18 OK, now I have that clear. 2011-06-25 18:28 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? 2011-06-25 18:29 rsharpe: correct 2011-06-25 18:31 yes. see spi_atben.c. the registration process is a little tricky 2011-06-25 18:31 OK, thanks. Now I have a better mental picture. 2011-06-25 18:32 wpwrak: on atusb it is tricky as well, but different :) 2011-06-25 18:38 anybody home this fine Saturday? 2011-06-25 18:38 home, hacking :) 2011-06-25 18:40 wpwrak: You are in a similar time zone to me aren't you? 2011-06-25 18:40 cool.I just learned about the $2K fee to get a USB address block. I assume Wolfgang had tp pomy up? it really sucks. 2011-06-25 18:41 [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 2011-06-25 18:41 is GMT +8 (usa pacific daylight time zone) is now 11:42am Saturday 2011-06-25 18:42 rsharpe: you're still US west coast ? i'm argentina (east) coast. one hour "east" of US east cost. so somewhat similar 2011-06-25 18:42 you guys will also need.reset_data for spi_atusb. i think all the bits and pieces are now in place. 2011-06-25 18:43 ah, and i'll kick out the transfer classifier soonish. 2011-06-25 18:44 that is, thinking of it ... maybe i'm not in a hurry with that. may still be useful 2011-06-25 18:44 OK, so you are four hours ahead of me 2011-06-25 18:45 wpwrak: yeah, I was already thinking about reset_data :) 2011-06-25 18:45 wpwrak: spi_atben is now ready from your side? 2011-06-25 18:49 yeah, should be good to copy from now 2011-06-25 18:49 wpwrak: oki 2011-06-25 18:50 i still have to optimize the bit-banging functions a little. still got some precious cycles to squeeze out of them ;-) 2011-06-25 18:50 wpwrak: only the irq forwarding with usb irqs is unknown to me now 2011-06-25 18:50 oh, wait. one mistake ... 2011-06-25 18:53 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? 2011-06-25 18:54 [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 2011-06-25 18:54 now it's better :) 2011-06-25 18:54 rsharpe: the latter, unfortunately. we have a perfectly good SPI controller, doing nothing :-( 2011-06-25 18:55