> > 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. What's Link driver? Where its driver code at usb/. > > 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? > > 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? >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 - 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/) > > > 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/) > > From my point, PHY is the resource, any users can use it. > > sure. > > -- > balbi -- 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
