Re: [PATCH] usb: gadget: bcm63xx UDC driver

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

 



On Tue, Aug 21, 2012 at 1:34 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>> It is a silicon feature: the core will intercept SET_CONFIGURATION /
>> SET_INTERFACE requests, store wValue/wIndex in the appropriate
>> USBD_STATUS_REG field (cfg/intf/altintf), send an acknowledgement to
>> the host, and raise a control interrupt.
>
> Your explanation is not clear.  The operations you listed are exactly
> what any UDC should do when it receives any control request: It should
> store the bRequestType, bRequest, wValue, wIndex, and wLength values in
> appropriate registers, send an ACK back to the host, and generate an
> IRQ.  What's special about Set-Config and Set-Interface?

For "most" control requests (such as GET_DESCRIPTOR), this core writes
the raw packet data out to a buffer in DRAM and raises an IUDMA IRQ.
The UDC driver passes this data on to the gadget driver and allows it
to decide what to send back in subsequent phases.

But some requests are handled entirely in hardware, including the status phase:

SET_ADDRESS
SET_CONFIGURATION
SET_INTERFACE
SET_FEATURE
CLEAR_FEATURE
GET_FEATURE

Where appropriate, the hardware block will update its registers to
indicate the new settings and raise a control IRQ.

>> I haven't found it to be terribly helpful, but I don't know of a way
>> to turn it off.
>
> Why would you want to turn this off?  Isn't is exactly what you want to
> have happen?  And why do you need a workqueue to handle the request?

SET_CONFIGURATION and SET_INTERFACE need to generate setup callbacks
for the gadget driver, and the proper ordering of events needs to be
enforced.  It is possible to receive IRQs for "SET_CONFIGURATION has
happened," "SET_INTERFACE has happened," and "there is another control
request pending," all at nearly the same time, before the gadget
driver has had an opportunity to respond to the first setup request.
But if that happened, we would not want to generate three setup
callbacks in a row.

Example:

1) SET_CONFIGURATION transfer completes (including status phase), all
handled by hardware.  Control interrupt is raised.

2) Setup packet is sent to USB gadget driver (say, gadgetfs)

3) SET_INTERFACE transfer completes, and another control interrupt is raised

4) Gadget driver eventually gets around to queuing the SET_CONFIGURATION reply.

5) Now we are in the UDC queue function and the gadget driver is
probably holding a spinlock.  We want to invoke the setup callback
with the spoofed SET_INTERFACE packet, but it's not safe to do it from
here.

To complicate the situation, another setup packet can arrive between
steps 3 and 4.  But the worker function makes sure everything plays
out in the right order.
--
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