On Tue, Jan 06, 2009 at 08:02:06PM +0000, Dave wrote: > Andrey Borzenkov wrote: > > On 05 January 2009 23:32:13 Dave wrote: [snip] > > By the way. Agere driver takes different approach. The only thing it > > does in interrupt handler directly is to turn off Hermes interrupts and > > start off another thread to process pending events. After all events are > > processed interrupts are enabled again. It means the bulk of code is > > executed in non-interrupt context; and looking how much is done in > > orinoco driver during interrupt processing, this does not sound like bad > > idea. Do you see any obvious cons here? > > When I moved the RX handling into a tasklet I had a go at moving all the > interrupt handling code into the tasklet, and just couldn't get the card > to play nice. It might have worked if I disabled the interrupts (which I > didn't try), but my personal preference is not to touch interrupt > enables if we don't have to. Anyway, cons I can think of? : Heh. Glad to see it wasn't just me that had perrennial problems with locking in the orinoco driver due to trouble with the hardware. Incidentally, the approach descibed in the Agere driver sounds not-dissimilar to an approach I thought about, which I think would fix most of the problems we've seen, but I never got around to implementing. That is to run all the guts of the driver in a single kernel thread, which just loops most of the time sending any queued packets, receiving any available packets and otherwise sleeping. The interrupt path and the userland entry points would do nothing except flag and wakeup the main thread. Because everything would be single threaded, we'd no longer need any locks for hardware contention, which sidesteps all the problems we've seen with the hardware taking too damn long to respond for operations that could contend. Even for reset, which takes ages, and on Prism firmware with WEP enabled when the BAP occasionally takes ages to respond. The only locks would be to protect the flags/queues that are used to signal the master thread, and since that's entirely under software control we can make sure the critical sections are small enough. I suspect it would also allow support for USB orinoco hardware to be integrated more sanely than the current organization. It's not exactly a high throughput approach, but given the hardware's so crappy anyway, I don't think it would be a significant problem. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
