On Tuesday 06 March 2007 11:12 pm, Ajay Jain wrote: > Hello, > > We had the following questions for a peripheral controller driver. We > do have an idea about some of the answers, evidently our understanding > is not complete. > > 1. The gadget can ask the peripheral controller to send/receive zero > byte packets. Consider the following sub-cases: > a) req.zero : When set we have to send zero byte packet. > b) Similarly, when req.length = 0, zero length packets, have > to be sent/rcvd. > Why do have both of these, why a duplication ? Is it possible that we > have a length set to some value and a req.zero also set ?
As Alan explained ... or more directly, if you specify length == 0 then that will be sent, but if if length == N*maxpacket (N > 0) then there are two cases: req.zero set, it sends N packets then a ZLP; or else req.zero clear, it only sends the N packets. > 2. During a bulk xaction, if the size of transfer is equal to the max > packet size, then will the gadget queue a zero byte packet. Or is it > the peripheral's driver responsibility to send a zero byte packet. If > the former is a yes, then how is it accomplished ? Is a req.zero set > or length = 0 ? This is the same question as above, same answer. > 3. Do I have a request form the upper layer for a zero byte packet, > for a control xfer when the data stage is an 'OUT' stage ? If yes, why > ? Shouldn't, but some controller hardware (and hence drivers) might be happier seeing such a flag. The USB spec says what the packets should be for any given transfer length. However, some hardware designers appear not to have read that spec, or at least not to have understood the system-wide ramifications. > 4. Why use alloc_buffer call? I am not interested in doing any DMA. > This DMA is between what & what? Who uses these buffers ? Did you read the usb_ep_alloc_buffer() kerneldoc, in <linux/usb/gadget.h>? If your hardware can't DMA, then just kmalloc() that data. A good example of where it would be appropriate to use such buffers would be as the place for a camera sensor to dump its data, assuming raw sensor data gets sent out as an isochrounous video stream (no pre-processing). That would keep the data out of CPU caches ... the next best thing to being able to DMA directly from the camera sensor into the USB fifo, if the data rate could be matched up properly. - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
