[Gta04-owner] Small update to 3.7-gta04 kernel: faster wifi.

[NeilBrown]

On Sun, 20 Oct 2013 10:19:20 +0200 Andreas Kemnade <andreas at kemnade.info>
wrote:

> Hi,
> 
> On Sat, 19 Oct 2013 11:13:15 +0200
> "Neal H. Walfield" <neal at walfield.org> wrote:
> 
> > At Fri, 18 Oct 2013 20:44:22 +1100,
> > NeilBrown wrote:
> > > I've just pushed out a small update to 3.7-gta04.
> > > 
> > > This update adds support for the IRQ line from SDIO cards, such as the wifi
> > > in the gta04.
> > > This allows the wifi to go faster.
> > > With polling (the old behaviour) I get about 1Mb/sec
> > > With Interupts enabled and polling disabled I get about 4Mb/sec.
> > > If I have interrupts *and* polling (which admittedly is a strange
> > > config to even try) I get 5Mb/sec on my 800MHz board, and 6Mb/sec on
> > > my 1GHz board.
> > > 
> > > So the code currently does both.  It is a bit of a hack (and not the only
> > > hack) but it works OK for now.
> > 
> > I don't know how these two config options interact.  For what it is
> > worth, polling often has lower overhead than processing an interrupt
> > if there is data waiting.  The tradeoff is that if there is no data
> > waiting, then polling slightly potentially increases latency and burns
> > a significant amount of CPU cycles.  Thus, some device drivers will
> > switch to polling mode when it appears that a lot of data will arrive
> > and revert to interrupts when the throughput dips below some
> > threshold.  Perhaps this is what the two config options are enabling.
> > 
> Hmm, in that 2.6.32-hw-validation kernel, the interrupt mode works
> alone with highspeed (no polling). Somehow some interrupts are lost now,
> so I did not disable the polling.

Do you know what speed you can get with 2.6.32-hw?  I tried but my current
user-space doesn't seem to work properly with such and old kernel (which
surprised me).

The interrupts are lost because of a bug (or missing feature) in the OMAP
hardware.  The sdmmc module does not request a wakeup when an SDIO interrupt
arrives.  So if the module is put to sleep (FCLK (function clock) stopped),
interrupts are ignored.
You can work around this by polling, or by keeping FCLK enabled.

There are patches on the linux-omap mailing list list work around it by
reprogramming the input line to be a GPIO while hsmmc is asleep.  The GPIO
module does support the required wakeup so it should  pass the SDIO interrupt
in which would run the interrupt handler which would wake up the hsmmc module.

I couldn't get it to work though - no idea why.

> I guess, polling would be better at much higher data rates, but not at
> that low data rates we have here.

Agreed.  I am seeing SDIO interrupts at the rate of about 4000 per second,
or one per 250usecs.  On an 800MHz CPU, lots can be done in 250usecs.

So I don't think the speed problem would be fixed by interrupt mitigation
(which is replacing interrupts by polling).

I wonder if the libertas driver might be overly simplistic.  My understanding
is that most network cards can buffer a number of packets (in a ring) so you
download several packets, it starts sending and you get an interrupt when the
ring is half full at which point you down load some more packets.
But the libertas code seems to just do one packet per interrupt which
suggests there is no transmit ring.
I might be completely misunderstanding the code, but I wouldn't be surprised
if there were room to improve the driver code.

NeilBrown

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20131021/18d77428/attachment.bin>