On Wed, 23 May 2012, Pratyush Anand wrote: > On 5/23/2012 12:02 AM, Paul Zimmerman wrote: > > The sequence should go like this: > > > > - The host sends the Set Interface command that enables the isoc > > endpoint. > > > So, is it necessary to have a different alternate setting for isoc > transfer? Is Set Interface mandatory to start isoc? According to the USB spec, devices aren't allowed to use isochronous transfers in altsetting 0 on any interface. Consequently yes, Set-Interface is mandatory to start isoc. In practice there are devices which do not obey this restriction. (Hopefully all of the Linux gadget driver do follow the rules properly.) Therefore the actual situation is that one of Set-Configuration or Set-Interface is mandatory to start isoc. Which isn't saying much, because without Set-Config it's impossible to communicate with anything other than endpoint 0. > Is it that, there can not be asynchronous isoc transfer? Host sends IN > token. Core receives it, sends 0 packet to host, Does it? This is a question of judgment; I would expect that if a device doesn't have any data to send then it wouldn't send anything -- not even a zero-length packet. > generates xfernotready > to SW, gadget is not ready to send data now. Host is still sending IN > token and receives 0 byte packet. Gadget becomes ready after an > *undefined* time. Now it does not have track of micro frame number. The Gadget API has a weakness in that it does not give drivers a way to specify which microframe a particular isochronous packet should belong to. So what happens if an IN packet from the host gets corrupted or lost? Does all the following isochronous data get shifted back by one interval, or does some of the data get skipped? The Gadget API doesn't say. Alan Stern -- 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
