Hi, On Tue, Aug 09, 2011 at 10:07:42AM -0400, Alan Stern wrote: > On Mon, 8 Aug 2011, Sarah Sharp wrote: > > > > Bursting is handled almost entirely by the hardware, so in theory > > > Windows shouldn't have any trouble coping with it. For the same > > > reason, gadget drivers shouldn't have to worry about it -- the UDC > > > driver should be responsible for setting the bMaxBurst fields. > > > > There's no official Windows driver, so this answer is a bit moot, but I > > have seen the NEC/Rensas Windows driver use bursts with mass storage > > devices. > > > > I think it makes sense to set a non-zero burst size in the MSC gadget > > driver if it can handle it. The driver will have to handle that number > > of packets being sent without receiving an ACK from the host (in the > > case of bulk IN), or being able to receive that number of packets > > without needing to send an ACK between packets (in the case of bulk > > OUT). Can the driver currently handle that? > > Does the driver need to do anything at all? As far as I can tell, > bursting is controlled by the NumP field in the ACK transaction packet. > This value is set automatically by the UDC driver or hardware; the > gadget driver has nothing to do with it. Therefore the mass-storage > gadget drivers shouldn't need any changes to support bursting. In that case, I'll change that to a non-zero value (2) and later we go the exercise of finding the best number to stick in there. -- balbi
Attachment:
signature.asc
Description: Digital signature
