Stefan Schmidt wrote: > Lucky enough for you I did not. :) Excellent :-)
> I was talking about the original > atusb driver we wrote. Working and stable but slow. :) Oh dear. No, I wouldn't unleash that on mainline :) It's nice enough as a proof of concept, but as you move on to doing fancier things, like sending TCP over it, the delays kill it quite horribly. Background: the driver we're talking about provides an SPI host, complete with interrupts, to run underneath at86rf230.c It then sends the SPI operations via a device-specific USB protocol to the atusb dongle's ATmega32U2, which then talks to the AT86RF231. The code of the Linux driver is here: http://projects.qi-hardware.com/index.php/p/qi-kernel/source/tree/ben-wpan/drivers/ieee802154/spi_atusb.c One problem with this approach is that at86rf230.c needs a lot of register accesses for each frame, and many operations incur a 1 ms delay from USB. Since the AT86RF230/1 is a half-duplex device (a bit like the 3c501), these delays mean that two-way communication usually doesn't work because replies arrive while the driver is still busy turning the transceiver around. > Did you finish the hardmac firmware for the atusb already? I fixed a few bugs I found with the user-space drivers, but it'll need a bit more work for the kernel driver. I should also steal your auto-ack changes :) > If you plan > on working on the hardmac firmware and driver I would simply skip my > submission of the older driver. Yes, I don't think it would make much sense to send that critter to mainline. > So state machine in the firmware I guess. Yes, packet sending and reception will be handled in the firmware, such that the driver needs only one or two USB transfers for each: - when a packet arrives, the firmware retrieves it and sends the length followed by the frame content in a bulk transfer. - when the kernel driver wants to send a packet, it does a ATUSB_TX control transfer with the packet in tow. When the sending is done, the firmware sends an acknowledgement. Things like setting the channel and such will use the ATUSB_REG_* or ATUSB_SPI_* control transfers. This will duplicate a bit of the functionality in at86rf230.c, but it's probably not worth to try to share code at that level. > Talking about > the TX sync fixes you did. Already checked if they are still needed > with the mainlined driver? Lemme see ... part of the debug output patches made it. Interrupts and locking were ignored but it seems that Sascha Herrmann is now giving the same area a new try. No luck with sharing the register definitions and the platform-specific reset and slp_tr functions. Also the redundant setting of RX_SAFE_MODE still seems to be there. The spi->irq check is still wrong. RX skb overflows due to a bad PHR also still seem to be possible. Seems that the patch loss ratio in the patchwork days has been in the order of 90% :-( > What should we do with your patches to the main at86rf230 driver that > are still sitting in the ben-wpan branch on qi-kernel? Hmm, I guess I'll update and resubmit at least the fixes and the bits needed for atben (as RFC) once the dust around the IRQ changes settles. Now that DaveM merges directly into net-next, things should be much smoother. spi_atben.c will need testing and a bit of cleanup. I'm also not quite sure where this driver should go. It's a SPI host BUT also has AT86RF230-specific functions AND intimate knowledge of the Jz4740's registers AND the Ben's uSD power circuit. Splitting it doesn't sound too appealing either. > I will try to take care about my additions. Address filter should come > as a patch tomorrow and automatic retransmission could follow once the > stack has mechanisms for it. Great ! That should make things a lot more usable. > In any case, nice to read you again. :) Heh, thanks :-) Good to see you again, too ! - Werner ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Linux-zigbee-devel mailing list Linux-zigbee-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
