[rt2x00-users] [RFC] rt2x00: Use tasklets for rt2x00usb

Ivo Van Doorn ivdoorn at gmail.com
Thu Jul 22 20:17:02 AEST 2010


On Thu, Jul 22, 2010 at 12:11 PM, Helmut Schaa
<helmut.schaa at googlemail.com> wrote:
> Am Donnerstag 22 Juli 2010 schrieb Ivo Van Doorn:
>> On Thu, Jul 22, 2010 at 9:19 AM, Helmut Schaa
>> <helmut.schaa at googlemail.com> wrote:
>> > Am Donnerstag 22 Juli 2010 schrieb Ivo Van Doorn:
>> >> On Thu, Jul 22, 2010 at 8:53 AM, Helmut Schaa
>> >> <helmut.schaa at googlemail.com> wrote:
>> >> > Am Donnerstag 22 Juli 2010 schrieb Mark Asselstine:
>> >> >> On Wed, Jul 21, 2010 at 6:32 PM, Ivo van Doorn <ivdoorn at gmail.com> wrote:
>> >> >> > This updates the rt2x00usb driver to use tasklets for handling interrupts.
>> >> >> > This simplifies the code in rt2x00lib since it no longer needs to check if the
>> >> >> > device is USB or PCI to decide which mac80211 function should be used.
>> >> >> >
>> >> >> > This patch is work in progress, but I would to hear if there are any comments
>> >> >> > on the approach taken.
>> >> >> >
>> >> >> > Signed-off-by: Ivo van Doorn <IvDoorn at gmail.com>
>> >> >> > ---
>> >> >>
>> >> >> Ivo,  I know it has been far too long since I have done any work on
>> >> >> this project and I am far from an expert so feel free hit the delete
>> >> >> key... that being said. Tasklets are used less and less in the kernel
>> >> >> as there are now other mechanisms which offer the same flexibility.
>> >> >> Seeing this trend makes me feel rt2x00 is moving in the opposite
>> >> >> direction. Have you looked at threaded interrupts (which are now in
>> >> >> mainline) as an alternative? If I can get my development environment
>> >> >> setup quickly I will try to do better then these few words and
>> >> >> actually attempt an implementation if you think it is worth it.
>> >> >
>> >> > I agree. We switched all rt2x00 PCI drivers to use threaded interrupts
>> >> > already. However, since the USB versions don't have something like an
>> >> > interrupt handler I don't know how we could move the rx/tx handling
>> >> > into process context without introducing delays (for example when using a
>> >> > workqueue) and concurrency.
>> >>
>> >> The reason why I made the switch was in preparation for a different patch,
>> >> which actually needs a short delay between the URB callback function and
>> >> the processing of the data. And a side-benefit is that it manages to clean some
>> >> stuff up in the TX/RX processing which is also nice. :)
>> >
>> > Ok, understood. I don't know what you're working on right now ;)
>>
>> Oh, lets say that I am working on one of your ideas regarding rt2800usb
>> and rate control mechanisms :P
>
> Cool!
>
>> > but the
>> > tasklet approach should be fine (in regard to the mac80211 interaction at
>> > least).
>>
>> Well I just did some testing and rt2800usb needs to use a mutex, so
>> tasklets aren't the right tool (Doh!). I'll convert it to the workqueue :)
>
> Hmm, hopefully the workqueue doesn't delay too much.

Doesnt really matter I think. There must be a delay because when the
URB callback
function is called, the packet isn't transmitted yet. So the delay is
mandatory to
make sure the TX status is set in the registers. I think the danger
with delays with
this feature is a too short delay rather then a too long delay.

Ivo




More information about the users mailing list