FYI the original didn't make it to the list due to an HTML attachment.

On Tue, 28 Feb 2006, David Brownell wrote:

> On Tuesday 28 February 2006 4:15 am, Li Yang-r58472 wrote:
> >
> > I'm doing OTG support on a Freescale PowerPC platform.
> > The basic ID specified role change can work correctly.
>
> Good ... that's the first milestone!  I'm assuming you're
> using a 2.6.10 (or newer) kernel, since that's where the
> first OTG implementation (for OMAP) was merged.  If not,
> then upgrade ASAP.
>
>
> > However, when I dig into the HNP role change, I don't
> > quite understand the operation mechanism for current
> > OTG design.  The HNP is triggered by host suspend, but
> > current host stack doesn't seem to suspend automatically.
>
> See drivers/usb/core/hub.c in usb_new_device() ...
>
>  - it checks devices for OTG descriptors, and sets
>    the host and peripheral side HNP capability bits
>    appropriately;
>
>  - when the device isn't in the whitelist (a.k.a. the
>    "Targeted Peripherals List" of the OTG spec) then
>    it's either (a) suspended if it supports HNP, or
>    else (b) enumeration is aborted.
>
> That's all clearly #ifdef CONFIG_USB_OTG so it should
> be easy to find.  On the peripheral side it should all
> be pretty automatic, both setting B_HNP_ENABLE feature
> and then kicking in HNP when the peripheral is suspended.
>
>
> > As far as I understand, the inputs of OTG state machine
> > a_bus_drop, a_suspend_req, a_bus_req and b_bus_req should
> > be set/cleared by high level application.
>
> For now we assume *_bus_req are true, though on the host
> side drivers will eventually be able to suspend themselves
> and thus implicitly clear their bus request.
>
>
> > What is the proper interface to control these parameters
> > according to the current design?
>
> Most of those are implicit; there's no requirement for any
> explicit control.
>
> When we start seeing more OTG-enabled products or systems,
> then we'll start learning more about what additional use
> cases are important.
>
> - Dave
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> linux-usb-devel@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>

--
 /------------------------------------+-------------------------\
|Stephen J. Gowdy                     | SLAC, MailStop 34,       |
|http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road,     |
|http://calendar.yahoo.com/gowdy      | Menlo Park CA 94025, USA |
|EMail: [EMAIL PROTECTED]       | Tel: +1 650 926 3144     |
 \------------------------------------+-------------------------/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to