--- 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 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".
> 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 ...
--
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
