Re: Override endpoint attributes (was: RE: [PATCH] zd1211rw: change endpoint types of EP_REGS_OUT and EP_INT_IN from interrupt to bulk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 8 Feb 2011, Jussi Kivilinna wrote:

> Atleast with zd1211rw, after usb_reset_device() endpoints still show  
> as interrupt type and device requires firmware to be transferred  
> again.

Ah, this is one of those bogus devices which has no way of telling the 
host when its descriptors change.  Have you tried testing this device 
across hibernation?

>  I cannot tell if zd1211 firmware actually changes endpoint  
> types (as ath9k_htc)

Use "lsusb -v".

>  but I know that vendor driver uses these  
> endpoints with bulk urbs and using those solve/workaround CPU usage  
> problem. Increasing interrupt interval from 1 to 255 didn't help.
> 
> I think zd1211rw have been trying to use bulk urbs too, but  
> usb_bulk_msg() silently switches to interrupt mode. I don't know if  
> editing endpoint descriptors is right way solve this, or why CPU usage  
> is higher.
> 
> CPU usage comes from writing beacon frame to device, this is done  
> usually every 100ms on AP-mode. On Atom writing beacon (multiple  
> usb_bulk_msg() calls) with interrupt endpoints usually takes ~20msec  
> and this is when CPU usage goes up. By changing endpoints to bulk,  
> time to write beacon drops to 0~3msec.

That's part of the problem -- the driver shouldn't use usb_bulk_msg().  
Create a bunch of URBs and submit them explicitly all at once; don't
wait for one to finish before submitting the next.  Setting the
URB_NO_INTERRUPT flag on all but the last could also help.  This might 
use even less CPU time than you see currently.

> Endpoint descriptors appear to be edited by two drivers,  
> drivers/media/IR/mceusb.c (bulk to intr) and  
> /drivers/net/wireless/ath/ath9k/hif_usb.c (intr to bulk). Also bulk  
> endpoints are changed to interrupt type for buggy low-speed devices in  
> drivers/usb/core/config.c.
> 
> So what is right way to proceed? Is problem in usb core or with  
> device? Deal with buggy device in driver and override endpoint as  
> patch does?

There are at least three problems that I can see.  First, the device 
doesn't disconnect from and reconnect to the USB bus when it starts 
using new firmware.  Second, the device loses its firmware when it is 
reset.  Third, the driver wastes too much CPU time writing beacon 
frames.

The first two problems are the device's fault, and the third is the 
driver's fault.  None of them are the fault of usbcore.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux