> > that's fine, but you can't let anybody else e.g. control PHY's clock > directly. That's what I meant. > Of course, PHY's clock on/off at its init/shutdown/set_suspend API's. The user can only call PHY's API. > > > > What's Link driver? Where its driver code at usb/. > > musb, dwc3, mv_udc, at91_udc, etc. I am not familiar with musb and dwc3, but I know mv_udc and at91_udc is device driver, they supply USB device function. Are there any common definition to explain Link driver? > > 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. > These controller's otg file includes otg function(msm only supplies id switch) and PHY control. What's your picture for file/folder layout for otg and phy? > > 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" This kinds of OTG driver is like what current msm_otg.c and mv_otg.c do. > > > > > 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: Sorry, I use some words unclearly, It is not any OTG related. The USB controller can be designed to device-only (seldom) or host-only function. The chipidea USB controller has DCCPARAMS register, there are two bits at this register, Host Capable (HC) and Device Capable (DC) bit. If HC=0, it is device only function. If DC=0, it is host only function. My layout above is just for one function only driver, not OTG related. > > -- > 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
