I wrote: >> After that, the use of SDIO interrupts wants looking into.
By the way, the thread with the discussion of it is over here: http://thread.gmane.org/gmane.linux.ports.arm.kernel/45116/focus=46380 Of course, using the SDIO interrupt isn't a goal in itself. The reason why it is important is that polling for interrupts in real life either absorbs lot of resources or contributes to latency (in theory, if you're really good at predicting when interrupts happen, it could even reduce latency without extra effort). But the SDIO interrupt doesn't seem to be our main problem there. I briefly resurrected the old SPI-based patch set and looked at the latency if using a direct and dedicated interrupt line from WLAN to the CPU. Here's what I got: host => neo: min /avg /max stddev (100 samples) 15.30/ 77.66/ 222.00 44.52 ms neo => host: min /avg /max stddev (98 samples) 9.92/ 80.64/ 230.18 48.30 ms This looks good on the low end (in fact the 10ms are great), but average and standard deviation are similar to the poor results we get when using either stack with the S3C MCI interface. So before the ~2x improvement of using better interrupts will pay off, there's still a ~5x improvement to be found elsewhere. - Werner
