On Wed, May 16, 2012 at 10:23:50AM +0000, Chen Peter-B29397 wrote: > > > > > 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? read the USB specification. It defines the PHY layer and Link layer. > > > 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. ID switch has nothing to do with OTG, the ID pin is connected to the USB PHY. OTG is all about the timers (VBUS Rise, VBUS Fall, etc, etc), plus HNP polling. > What's your picture for file/folder layout for otg and phy? whatever's OTG-related (really OTG related, don't confuse OTG and PHY), should be done generally under drivers/usb/core/. This is probably the 5th time I'm saying this. > > > 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. they are both controlling a PHY. You seem to be missin all my comments when I say that OTG and PHY are *not* the same thing. So, just to make it really clear: OTG State machine (where applicable), OTG Timers, HNP polling... all of that *MUST* be done generically under drivers/usb/core. The way the underlying HW implements the OTG specification is meaningless to the SW side. The point is that it doesn't which PHY/Link we're using, the OTG specification is always the same, so all those timers and HNP polling and whatnot, can be done generically. > > 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. It's the same with the DWC3 controller. I'm planning on adding a drivers/usb/drd/ folder for these devices. What I did for DWC3 is that I'm always building Host and Device roles and deciding in runtime if I should probe Host and/or Device by looking into the controller's registers. At some point I will change that and let users also compile out e.g. Host if they don't want to use it, but for the next 2 merge windows, I plan to keep it as is, because it forces me to keep the code clean and always compilable. -- balbi
Attachment:
signature.asc
Description: Digital signature
