On Mon, Sep 06, 2010 at 12:11:53PM -0700, David Brownell wrote:
>
>
> --- On Mon, 9/6/10, Pavan Kondeti <pkondeti@xxxxxxxxxxxxxx> wrote:
>
> > it would be good to have a simple API
> > to achieve the
> > following things.
> >
> > Id becomes ground --> start HCD
> > Id becomes float --> start HCD
> > HNP start --> suspend HCD
> > HNP complete --> resume HCD
>
> This all fits naturally inside of the
> "struct otg_transceiver" ... the reason it has
> handles to the Host and peripheral controller
> drivers is so that it can kick them as needed
> during operations like cable {dis,}connect
> (and those ID operations), HNP, and SRP. The
> transceiver driver can amanage most ofthe OTG
> state transitions, hardware permitting.
>
> The first OTG implementation worked without
> any new HCD methods, so it's not clear to me
> why newer implementations would need them...
>
I am developing OTG driver for MSM chips. I would like to start first with
with basic OTG (based on Id pin detection) then extend the driver to implement
OTG2.0 functionality (SRP and HNP).
When Id becomes false, HCD will be added and HCD will be removed when Id
becomes true. When VBUS becomes true (session valid), gadget is connected. We
have usb_gadget_vbus_connect to achieve the later. But a similar API is
missing for host.
I was working on 2.6.32 kernel and did not look at the recent kernel. It seems
usb/core/hcd.h is moved to include/linux/usb. So I can happily call
usb_add_hcd() and usb_remove_hcd() from OTG without introducing another API
between OTG-->HOST.
> >
> > I am proposing a new method "otg_request" in hc_driver
> > struct defined in
> > linux/usb/hcd.h. This method will take 2nd argument as
> > req_flags and 1st
>
>
> One thing to remember is that there are basically
> two models for how hardware does OTG: one is with
> discrete host and peripheral controllers connected
> by OTG logic (initial model in Linux -- OHCI with
> OMAP_UDC). The other has more integration between
> the OTG logic and the controllers (like MUSB, but
> one hopes less messy). That second case may make
> it awkward or pointless to have an "otg_request".
>
Okay. I will look at the above implementations.
> > enum {
> > ID_START_HOST,
> > ID_STOP_HOST,
> > HNP_SUSPEND_HOST,
> > HNP_RESUME_HOST,
>
> Why should it matter *why* the host was being
> started, stopped, suspended, or resumed?? ISTR
> then-current programming interfaces sufficed
> even back in the OTG1.2 days ...
>
As I told above, HCD calls usb_add_hcd() upon Id ground condition. But
usb_remove_hcd() can not be called during HNP due to timing issues. So HCD
simply set hcd->state to halt, clears CD_FLAG_HW_ACCESSIBLE bit, and set root
hub device state to USB_STATE_NOTATTACHED. But these all can be directly in
OTG given that hcd.h available to outside usb/core.
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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
