Hello. On Sat, 2013-03-23 at 22:26, Werner Almesberger wrote: > Stefan Schmidt wrote: > > > 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.
Which means the firmware side would be already usable even if not finished? Seems I need to compile the newest firmware. :) > I should also steal your auto-ack changes :) Please do so :) > > 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. Fine with me. Nothing of this is urgent for me anyway. Just playing around with it. Let me know when you have anything for the new atusb kernel driver in a state where you would like some testing. Not much time at the pc over easter but afterwards I should be able to spare some. > > 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. Sounds good. Feature like auto ACK and auto retransmit will then be handled in the firmware as well I think. Basically the whole extended mode. Having control over the different features will also be needed at some point. E.g. the hw address filter callback in the atusb driver will need to transfer the changes, best in one go, to the firmware so it can set the registers for the filter accordingly > 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. Agreed. They will be to different to have a sane sharing of code between them. > > 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% :-( Yeah. At least now with the basic thing mainline it hopefully will be faster to get things picked up. > > 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. Makes you feel like the old ATM networking days or was that before DaveM was in charge? ;) > 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. Hmm. Is anything else using the uSD slot for plain SPI or is the spi_atben the only customer? If it is the only customer I would say keep spi host and stick them into ieee802154. If needs arises one could still split it of later. > > 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. The addr filter callback I just send. AACK and ARET code is there but have to wait for the stack to catchup here. You are still able to use them in the atusb hardmac firmware. Mostly state machine state changes anyway. regards Stefan Schmidt ------------------------------------------------------------------------------ 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
