On Thu, May 17, 2012 at 03:26:02PM -0400, Alan Stern wrote: > On Wed, 16 May 2012, Sarah Sharp wrote: > > > The USB 3.0 spec defines a new way of differentiating interrupt > > endpoints. The idea is that some interrupt endpoints are used for > > notifications, i.e. they continually NAK the transfer until something > > changes on the device. Other interrupt endpoints are used (as they > > should be, IMHO) as a way to periodically transfer data. > > > > The USB 3.0 endpoint descriptor uses bits 5:4 of bmAttributes for > > interrupt endpoints, to define the endpoint as either a Notification > > endpoint, or a Periodic endpoint. Introduce macros to dig out that > > information. > > Do you know the reasoning behind this? Interrupt endpoints provide two > things: guarantees on bandwidth and latency. The so-called Periodic > endpoints rely mainly on the bandwidth guarantee, whereas the > Notification endpoints rely on the latency guarantee. Either way, what > difference does it make to the host controller or the system software? Notification interrupt endpoints are used for things like modems or serial devices, to let the host know it should ask for data on a bulk endpoint. With USB 3.0 notification IN interrupt endpoints, the device will send an NRDY when there's no data to send, and then notify the host when data is ready by sending an ERDY. So there's likely to be a long period of time between packets. If the link goes into U1 or U2 during this time, the device is likely to be the one to initiate the exit to U0, in order to send the ERDY. So there's no reason for the host controller to add extra padding to its schedule to do a host-initiated transition to U0. So the host can allow the endpoint to go into U1 or U2 in between service intervals, and we only have to set the parent hub U1 timeout WRT the time it takes the device to initiate the exit to U0 (namely, the SEL value). > (And why do you think interrupt endpoints should always be of the > Periodic type?) It feels like an abuse of the interrupt endpoint type. Why not just use a bulk endpoint and NAK that IN transfer until there's data? I think device vendors just want to reserve bandwidth in case the bus is really full and the host is deferring bulk packets over periodic transfers. 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
