On Fri, 8 Jan 2010, shiraz hashim wrote: > On Wed, Jan 6, 2010 at 2:28 PM, shiraz hashim > <shiraz.linux.kernel@xxxxxxxxx> wrote: > > Hi, > > > > I am using a synopsys designware usb device controller on one of our > > ARM based platform, which I intend to submit to the mailing list. > > Is anybody else working on this device? and whether it is ready for > > inclusion in to mainline? > > > > I have one more query. This device has a set of registers (UDC_REGS) > > which has to be programmed for each logical endpoint used in the > > gadget design. So, > > for each endpoint we must know, its > > 1- number > > 2- direction > > 3- type (bulk, isoch etc) > > 4- config no. (config no. to which this endpoint belongs) > > 5- interface no. (interface no. to which endpoint belongs) > > 6- alt interface no. (alt intf to which endpoint belongs) > > 7- maxpktsize > > Among these, 1, 2, 3, 7 and 4(to some extent) are readily available on > > set_config. But 5, 6 are embedded in the interface descriptors and the hierarchy > > of descriptors which is dependent on the gadget. > > Now the driver is actually not aware of this (descriptor) layout i.e. > > which endpoint belongs to > > which interface and alt interface. > > It (the descriptors) are not supplied to the driver but are > > transmitted by the gadget on > > corresponding request, which again is hard to track. > > In ep_enable also we only get endpoint descriptor in the driver which > > doesn't carry interface > > and alt interface details. > > How to configure device in this case? > > Any help on this. We think to achieve this (configuring endpoints) > with above info > through ioctl option in the gadget framework. Is it the right approach. The gadget framework does not include any ioctl options. Why is this necessary? That is, why does the hardware need to know the endpoint's config #, interface #, and altsetting #? How does it use that information? 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
