On Tuesday 27 January 2009, Sarah Sharp wrote: > On Tue, Jan 27, 2009 at 11:53:53AM +0800, Kawshol Devilal SHARMA wrote: > > DB, > > > > Your observations from device point are correct. I am reading the "Gadget > > stack". My initial thought are > > > > 1. Do you think there is "no-change" required on "gadget layer" as the bus > > has become full-duplex? or you leave this to peripheral controller to > > execute the queues? > > 3.We will need to be added is the bursting capability to the endpoint. May > > be a change in each peripheral controller, does protocol layer need change? > > The interesting point with the bus being full-duplex is that gadgets and > hosts can send packets at the same time. Based on some negotiation, the > host can send several packets in a row without receiving acknowledgments > from the device. Or the device can send several packets without waiting > for a host ACK. That's what "data bursting" is all about. The "max > burst size" before either end has to wait for an explicit acknowledgment > is configurable per endpoint. It's set in the endpoint companion > descriptor. > > Dave, will there need to be changes in the gadget layer for data > bursting without waiting for explicit ACKs? In terms of I/O, I don't think so ... for OUT (tx) transfers the usb_request completions are issued when the data is ready. For IN (tx) it's OK to issue the completion as soon as the data is fully in-flight ... example, it may be in a FIFO but not yet seen by the host. In terms of endpoint configuration, that burst configuration descriptor probably needs to be passed down to the controller driver in an updated version of usb_ep_enable(). > > 2. As you pointed out "stream state" machine is to be added. Though the > > streams are used by the class driver, there is a new state machine per > > endpoint and we need to see how and where to implement this? Specially > > switching the streams over a endpoint. This needs "Gadget layer" intervene > > the operation of "Peripheral controller" to change the steam buffer or > > manage? You at-least need to define how a PCD has to work. > > PCD? (USB) "Peripheral Controller Driver", I'd assume. For the hardware abstracted by a usb_gadget. > I suspect the stream management will need to be done by the gadget > driver (correct term?) that handles the USB 3.0 MSD functionality. It > would be up to that driver to decide which stream to respond to (which > corresponds to what queued SCSI command it wants to respond to). There > might need to be some generic gadget layer for stream switching to > implement part of the stream state machine; I'm not sure yet. It could be as trivial as adding a stream ID to the usb_request objects passsed to usb_ep_queue() ... that's clearly sufficient on the TX side. Presumably there's some higher level protocol for allocating/freeing those IDs? (Even as trivial as having an out-of-band agreement between host and peripheral.) RX side might need some thought. It'd be easy enough to treat the stream ID as an input, so there'd be sub-queues on each endpoint. What does the USB 3.0 spec say about data sent to streams that aren't ready for it -- no usb_request queued? If it's not OK to NAK such data, it gets messy. > > 4. power management are you sure as you say " link power management should > > ideally not be visible outside the peripheral controller driver". Just that. The spec even says: "After being configured by software, the U1 and U2 link states are entered and exited via hardware autonomous control." The peripheral controller should set some sane default for the relevant timers. If it's ever needed, and there's a good argument for changing that, a new interface could be defined to permit changing them. But it's my observation that such things are poorly understood at first, especially at higher levels (i.e. the function and gadget drivers). > > I think > > though implemented in the peripheral controller driver it will be needed to > > be exposed to protocol layer. > > I think a little explanation is needed for the link power management. > U0 is the active state, U3 is the host-initiated "device suspend" state. > USB 3.0 bus spec appendix C, section C.1.1.1, gives suggestions for what > hardware to shutdown on the gadget side in the other low power link > states (U1 and U2). The gadget side doesn't *have* to follow those > suggestions, but it does have to meet the electrical requirements in 6.7 > and 6.8. > > Will the gadget later have to deal with powering down hardware when it > receives a request to go to U1 or U2? For example, a suggestion for U1 > power savings would be to power off the TX and RX circuitry. In U2, > some clock generation circuitry could be quiesced. I assume those would > be under software control? If so, the gadget side will need calls > similar to whatever it does for device suspend. That doesn't mesh with that language about "autonomous control"... > Hardware control aside, the gadget also has to report the time it takes > to transition out of the U1 and U2 states (the U1 and U2 exit > latencies). This includes hardware bring up and any time the software > needs to respond to packets. This would probably be unique across > devices, so it might make sense to have a gadget interface to add those > exit latencies to the SuperSpeed Extension Capabilities BOS descriptor. Maybe. Alternatively, let Kconfig override some defaults; this sounds like the kind of setting that is often not used well. (He says, looking at his VCR clock, which the cable company always sets incorrectly...) > Most of the link power management policy is left up to the host OS and > the hubs in the tree. The host OS looks at the exit latencies for the > whole tree, down to the device, and then programs the U1/U2 exit > latencies for that hub's downstream port. The hub will initiate a link > state transition when that inactivity timer times out. > > Therefore, the device doesn't have to deal with setting the link power > state. However, it can aggressively set the link power state sooner if > it wants to. There should probably be a gadget API for that. > > But the link power management stuff is really moot until the host > controller driver sets the U1/U2 inactivity time-outs in the hub. Until > then, the whole tree will stay in U0 (aside from host-initiated device > transitions into U3). That too. So again: worry about that *much* later. ;) > > 5. Enumeration I do not have full idea, if "set_address(0)" is what a > > "peripheral controller" understands as reset. So it will change if there is > > no set_address(0) from the host some of them wait for the set_address(0). > > I'm not really sure about the enumeration changes either. A set_address(0) would be extremely unusual; I don't think I've ever seen it. There's a USB level reset, yes. Those parts of enumeration are hidden from the gadget drivers in any case (and the function drivers layered over them). - Dave > Sarah > > > -----Original Message----- > > From: David Brownell [mailto:david-b@xxxxxxxxxxx] > > Sent: 2009 Jan 27 7:14 AM > > To: Sarah Sharp > > Cc: viral.mehta@xxxxxxxxxxxxxx; Kawshol Devilal SHARMA; John Youn; Paul > > Zimmerman; Joel Gotesman; sridharan.ranganathan@xxxxxxxxx; David Vrabel; > > linux-usb@xxxxxxxxxxxxxxx > > Subject: Re: USB 3.0 gadget stack > > > > > > Start with a rough description of what needs to change, > > > > then work up to proposals. > > > > > > So, I know what needs to change for to support USB 3.0 on the host-side, > > > but I'm not familiar with the gadget side of things. > > > > > > > Example, changes to <linux/usb/ch9.h> will cover both > > > > host and peripheral sides of the stack; mostly new or > > > > updated descriptors, but presumably also updating the > > > > device speed enumeration. That would likely go well > > > > as a single early patch. > > > > > > One new thing for USB 3.0 devices is the requirement for an endpoint > > > companion descriptor after every endpoint. You can see what sort of > > > information is in that descriptor by looking at section 9.6.7 of the USB > > > 3.0 bus spec. I have a patch to add the structure to > > > include/linux/usb/ch9.h and parse that descriptor on the host side. > > > Would the gadget size need more than that? > > > > Interfaces for the hardware to report its bMaxBurst capabilities, > > for the gadget stack to use them when autoconfiguring interfaces, > > and for the gadget stack to come up with new "SuperSpeed" config > > descriptors ... maybe more, too. > > > > I've done no more than skim those 3.0 bus specs; it looks from > > that level as if drivers can mostly treat data transfers as just > > being faster, and use the same I/O models. One exception being > > the new bulk "stream" capability, multiplexing different logical > > data flows on one endpoint. I'm not sure what to make of the > > notion of exposing data CRC errors ... that seems like something > > the peripheral (and host) controllers might not necessarily be > > exposing to upper layers of software. > > > > > > > There's also a new Binary Object Store descriptor required for USB 3.0 > > > devices (section 9.6.2.2). I don't have any patches that deal with > > > descriptor yet. David Vrabel said the wireless USB stack has some code > > > to parse the BOS descriptor. The new SuperSpeed USB Device Capability > > > BOS descriptor structure would still need to be added to > > > include/linux/usb/ch9.h. > > > > Right. And the composite gadget framework would need to > > provide some of those, possibly with non-generic input at > > the time device configurations are being assembled. > > > > > > > > The basic design problem here will be converting what > > > > comes out of the spec development process -- likely a > > > > "formats and protocols" level spec -- into updates for > > > > the Linux-USB stack. Is enumeration affected? How? > > > > > > There are enumeration changes for USB 3.0 devices, but I think much of > > > it is taken care of by the PHY. One interesting thing to note is that > > > USB 3.0 devices in a tree structure are reset and link trained in > > > parallel by the PHY. > > > > So users would need to handle more than the usual number of > > function-level reset/reinitialize events? Currently those > > events are rare ... and only stateless devices/drivers manage > > to avoid presenting them to users. > > > > > > > By the time the OS receives the port status change notification, all USB > > > 3.0 devices below that root port are all at address 0. So there is no > > > need for the OS to reset them. The OS addresses USB 3.0 devices by > > > using a route string (you can see an example of this in section 10.1.3.2 > > > of the USB 3.0 bus spec). > > > > > > I have host-side code that modifies the host-side enumeration sequence > > > to take care of this. I'm not sure how much new gadget side support is > > > needed. Ideas? > > > > Any reason they shouldn't be treated just like a standard > > reset event? Including re-initializing from scratch, based > > on what the host tells them to do. > > > > > > > > That could affect the hub and HCD interfaces. What > > > > (if anything) will interface and function drivers > > > > need to understand differently? > > > > > > There is a new hub descriptor for USB 3.0, new requests, and new state > > > machines for devices. I worked around these requirements by pretending > > > the xHCI USB 3.0 root hubs had a USB 2.0 descriptor with the speed > > > changed. So the xHCI driver won't work with external hubs yet. I think > > > there will need to be some changes made to khubd, but I haven't looked > > > at the hub state machines in a while. > > > > Unless hubs are visible to the peripherals, that's entirely > > a host side issue. > > > > > > > With the USB 3.0 bus spec, they tried to get rid of the polling of > > > interrupt endpoints. If a device doesn't have data, it can respond with > > > a NRDY (not ready) packet. The host will then wait for the device to > > > send a ERDY (endpoint ready) packet before communicating with that > > > endpoint again. There will be some gadget-side changes necessary for > > > this. I think the host-side changes are all taken care of in the > > > hardware, but I would have to check on that. > > > > Why would the gadget stack need to change? That seems like > > something the hardware should handle. The gadget driver will > > either have queued data, or not; NRDY gets sent if not, and > > then later ERDY. If the controller needs help, that's all > > in the hands of its driver -- invisible to upper layers. > > > > > > > > Stuff that percolates into usbcore deserves some > > > > discussion; ditto stuff affecting how e.g. composite > > > > gadgets get assembled. > > > > > > Of course these changes discussed don't even cover the new link power > > > management and function suspend for USB 3.0 devices. > > > > My quick glance suggests that "function suspend" may be a > > misnomer, since it's an *interface* feature flag ... while > > functions are not limited to single interfaces. > > > > I'm thinking the link power management should ideally not > > be visible outside the peripheral controller driver. > > > > - Dave > > > > > > > Those will both be > > > a requirement for USB 3.0 device compliance, but we can discuss those > > > after we have an idea of the changes necessary for basic USB 3.0 > > > gadget-side support. > > > > > > Can anyone think of any other changes for USB 3.0 gadget side support? > > > > > > Sarah Sharp > > > > > > > > > > > > -- 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
