On Wed, May 16, 2012 at 03:06:19AM +0000, Chen Peter-B29397 wrote: > > > > > You're abusing the OTG concept. OTG is nothing more than a few additions > > to the USB standard in order to be able to dynamically switch between > > Host and Device roles based on a) cable (id pin) or b) HNP. > > > Correct, it is the OTG spec concept. > > > OTG doesn't know anything about PHYs, clocks, registers, etc... That > > should be done on each specific driver, meaning PHY will be completely > > managed by the PHY driver, Link/UDC will be completely managed by Link > > Driver. > I have different ideas for PHY driver, PHY driver just supplies its functions > with its APIs, the PHY user manages PHY through these APIs. that's fine, but you can't let anybody else e.g. control PHY's clock directly. That's what I meant. > > What's Link driver? Where its driver code at usb/. musb, dwc3, mv_udc, at91_udc, etc. > > The OTG layer will simply call hooks from those guys to put > > PHY/UDC on the desired state (e.g. suspending bus so HNP can happen, or > > kicking HNP polling and so on). > > > > Correct, so OTG layer will call PHY's API, correct? when necessary, but it doesn't mean it's controlling the PHY directly ;-) Implementation details should be completely hidden from the generic layer. > > > At this OTG driver, it will call phy->init, phy->set_wakeup, phy- > > >suspend > > > and phy->resume, etc. The code routines at device and host is active > > mode, > > > PHY is active and clocks are on. > > > > this is ok, but there's not need a drivers/usb/otg just for that. Like I > > said, it should be generic, small and sitting under drivers/core. > > drivers/usb/otg gets renamed to drivers/usb/phy. > > If drivers/usb/otg gets renamed to drivers/usb/phy, where to put current otg > drivers, like fsl_otg.c, msm_otg.c, mv_otg.c, otg_fsm.c, etc? Those are misnamed PHY drivers. Look at what they do. I guess only fsl_otg kicks a some OTG timers but, like I said on previous mail, kicking OTG timers should be a generic feature of the USB core. > From the hardware point, one OTG capable USB port includes: > - USB Core Controller > - USB PHY > > From the software (functional) point, one USB port includes: > - One OTG driver I still don't know what you call OTG driver. > - One Host driver > - One Device driver > - One PHY driver > Assume all three drivers share the same register mapping. So, USB PHY, USB Clock, > USB register mapping, PIN MUX (optional) are all resources, all three drivers > need resources to finish its correct function. Then, the question is where to > manage these resources? My OTG driver does not only include OTG functions, > but also as these resources manager. Of course, you can also have the core code > manages this resources. Then, how files layout for all these things, if otg driver > takes as resource manager, it likes as below: > - One OTG driver (OTG function and resource manager, drivers/usb/otg/) > - One Host driver (host function, drivers/usb/host/) > - One Device driver (device function, drivers/usb/gadget/) > - One PHY driver (PHY function supplier, drivers/usb/phy/) tell me what you call "OTG driver" > > > If the user hasn't OTG driver, the host-only or device-only driver > > takes the > > > same responsibilities like above OTG driver. > > > > This isn't entirelly correct either. We can have DRD devices which don't > > comply with the OTG specifications. One such instance is the current > > DWC3 implementation on OMAP5. Because OTG v3.0 isn't finalized, it's not > > OTG v3.0 compliant, but we can still switch between Host and Device > > roles through sysfs or cable (timings might be violated though). > > > Maybe you has misunderstood me, if the controller is not OTG capable, it likes below: > For device-only controller: > - One Host driver (host function and resource manager, drivers/usb/host/) > - One PHY driver (PHY function supplier, drivers/usb/phy/) > For host-only controller: > - One Device driver (device function and resource manager, drivers/usb/gadget/) > - One PHY driver (PHY function supplier, drivers/usb/phy/) You seem to be misunderstanding. Just because a controller isn't OTG-capable, it doesn't mean it can't switch between Host and Device roles. It's like this: All OTG devices are DRD (Dual-Role Device), but not all DRD are OTG. This is what you seem to be missing. OTG is a standard way to switch between Host and Device sides, but it doesn't mean we can't support Host & Device roles without being compliant to that standard. It's like saying all USB Host Controllers are xHCI, which isn't true. MUSB, for instance, has a completely proprietary host implementation. -- balbi
Attachment:
signature.asc
Description: Digital signature
