> Milan Svoboda napisa?(a):
> > IMHO, gadgetfs' .speed declares maximum supported speed that gadgetfs
is
> > able to work with. Thus it's better to look at the at91_udc driver and
> > find it's probe function and change it to support gadgets that
> > supports at least USB_SPEED_FULL speed (USB_SP
Milan Svoboda napisa?(a):
> IMHO, gadgetfs' .speed declares maximum supported speed that gadgetfs is
> able to work with. Thus it's better to look at the at91_udc driver and
> find it's probe function and change it to support gadgets that
> supports at least USB_SPEED_FULL speed (USB_SPEED_FULL an
> Also I forgot to mention that I was unable to use at91_udc with gadgetfs
> because gadgetfs' driver uses .speed = USB_SPEED_HIGH for probing
> controller name. at91_udc supports only USB_SPEED_FULL, so it seems that
> no one has tested this setup recently. The patch is trivial, as the real
> usb_
On Tue, 12 Sep 2006, David Brownell wrote:
> > First of all, at91_udc activates the pullup in ..._register_driver(),
> > so even if I don't load any gadget module, the host starts enumeration.
>
> I don't follow. If you (successfully) register a gadget driver
> and don't usb_gadget_disconnect() i
> First of all, at91_udc activates the pullup in ..._register_driver(), so
> even if I don't load any gadget module, the host starts enumeration.
I don't follow. If you (successfully) register a gadget driver
and don't usb_gadget_disconnect() in the gadget driver bind()
method, it's *required* to
I've been playing around with a AT91RM9200-based board for couple of
days and I'm stuck with some problems regarding at91_udc and gadgetfs.
First of all, at91_udc activates the pullup in ..._register_driver(), so
even if I don't load any gadget module, the host starts enumeration.
Obviously no dev
