Julian
David Brownell wrote:
Miroslaw KLABA wrote:
Hello,
I wanted to know if there are any controller driver already written for Gadget
API, other than the netchip 2280 one?
Yes, like the pxa2xx_udc ... the net2280 isn't the simplest example, I'd agree. Not all controller hardware supports transfer queues in hardware; but then, not all controllers handle 40+ MByte/sec either!
I've got problems with the usb_ep_queue function. The chip, I want to write the
code for (Philips D12), has no FIFO inside, so either I have to make the
usb_ep_queue not really as a queue function, but rather as a direct write
function (which makes the driver not conform to the Gadget API doc), either
I have to write a FIFO queue in the driver and a write function to the usb
device controller at the end.
Am I right?
I don't understand the question. The queue() entry just adds another transfer buffer, one or more packets. Every controller driver maintains a queue; <linux/list.h> makes that trivial. By definition, the queues use a first-in/first-out (FIFO) policy -- unless dequeue() is used, which can force arbitrary early completions. (And on net2280 that gets complicated when hardware DMA queues are in use.)
Controller drivers can differ with respect to what happens when a buffer
gets to the head of the queue. All will transmit (or receive) data using
that buffer and the facilities in the controller ... which could be a FIFO,
shared memory, a DMA controller, or something else. Many controllers
offer some simple PIO scheme, as well as one or more DMA-based schemes.
The D12 seems to have a kind of hardware FIFO. If a gadget driver queues
a bulk transfer to an empty queue, the ep_queue() method would start that
I/O immediately (assuming the hardware's ready) and add it to the queue
(assuming that didn't complete the transfer). If the queue were non-empty,
that buffer would just be appended (list_add_tail). Queues advance when a
transfer completes, often in_irq().
The PIO paths on the pxa2xx_udc driver might be more informative, even though they know they talk to a FIFO ... and I think the queuing code is more cleanly structured in that code. Don't use its ep0 code as a model -- that part of the chip is perverse, the errata tend to be both wrong and incomplete! -- though the ep0 states may be informative.
- Dave
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
