On Mon, Apr 20, 2015 at 01:47:33PM +0800, Macpaul Lin wrote:
> Hi Peter,
>
> 2015-04-20 13:30 GMT+08:00 Peter Chen <[email protected]>:
> > On Thu, Apr 16, 2015 at 02:56:59PM +0800, Macpaul Lin wrote:
> >> Introduce kernel feature CONFIG_USB_OTG20 and related
> >> gadget_is_otg20() API for supporting OTG20 compliant
> >> drivers.
> >> This patch also updated usb_otg_descritpor.
> [Deleted]
> >
> > Do we really need another usb_otg_descritor20, how about define
> > otg descriptor like below:
> >
> > struct usb_otg_descriptor {
> > __u8 bLength;
> > __u8 bDescriptorType;
> >
> > __u8 bmAttributes; /* support for HNP, SRP, etc */
> > #ifdef CONFIG_USB_OTG20
> > __le16 bcdOTG; /* OTG release number */
> > #endif
> >
> > } __attribute__ ((packed));
>
> This is because some OTG-2.0 compatible OTG hardware might also
> compatible with OTG-1.3.
> These kind of hardware may have dynamic detection compatibility and
> could adjust their response timing at electrical level.
> These could be adjusted by register configuration after re-enumeration.
> Hence we may need to prepare OTG 1.3 and OTG 2.0 descriptors for these
> hardware which can do dynamic
> detection when the other A/B device will be connected.
>
Where this kind of dynamic otg descriptor requirement comes from?
(or it's just to meet your specific needs?)
OTG 2.0 device should be compatible with OTG 1.3, that's only for a 2.0 host
how to react with a connected OTG 1.3 peripheral, if in peripheral mode, it's
either 2.0 or 1.3 per OTG spec.
Li Jun
> > At gadget driver, assign otg descriptor like below:
> >
> > static const struct usb_descriptor_header *otg_desc[] = {
> > (struct usb_descriptor_header *) &(struct usb_otg_descriptor){
> > .bLength = sizeof(struct usb_otg_descriptor),
> > .bDescriptorType = USB_DT_OTG,
> >
> > /*
> > * REVISIT SRP-only hardware is possible, although
> > * it would not be called "OTG" ...
> > */
> > .bmAttributes = USB_OTG_SRP | USB_OTG_HNP,
> > #ifdef CONFIG_USB_OTG20
> > .bcdOTG = cpu_to_le16(0x0200),
> > #endif
> > },
> > NULL,
> > };
>
> And these array should be specified by gadget's hardware driver by
> querying included their capabilities.
> Instead of hard-coded capabilities.
> Like Li Jun's previous comment,
>
> "After you introduce some flags for controller to decide if HNP/SRP/ADP can be
> supported, this setting in all gadget drivers should be override
> according to those
> flags too, otherwise there will be possible mismatch between the OTG
> descriptor
> within config(like above setting) and the response for getting OTG descriptor
> request(your patch 3 does in composite.c)."
>
> Hence this kind of descriptor should be dynamic queried from gadget's
> hardware driver instead
> hard-code at compiling stage.
>
> --
> Best regards,
> Macpaul Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
