> Hi, > > On Mon, Jan 02, 2012 at 08:29:07AM -0800, Ido Shayevitz wrote: >> > On Sun, Jan 01, 2012 at 12:44:59PM -0800, idos@xxxxxxxxxxxxxx wrote: >> >> I wonder if there is a work being done for OTG2.0 driver support over >> >> the Synopsys dwc3 core? If so, which git/branch contain this driver? >> > >> > Sure there is :-) But in order to get there we must first stabilize >> the >> > host side and that we haven't achieved yet. >> > >> > Still, the newest code for this driver lies in my master branch. Just >> > grab a hold of that one. >> > >> > -- >> > balbi >> > >> >> Thanks Felipe, >> >> I see that in the dwc3_probe also xhci host device is constructed with >> the >> same irq and address base(of dwc3 core), but I couldn't see any > > true, but we still have some pending patches on the xHCI stack to get > the whole thing working out of the box with mainline kernel. > Unfortunately we won't have that on 3.3 merge window. But on 3.4 it's > likely that it will be there. > >> configuration done to the OTG registers nor a read of OSTS.ConIDSts for >> determining A or B device. > > That OTG address space isn't implemented by all cores. So you need to > find a way to implement that address space without breaking other users. > > The best way would be to check if GHWPARAMS6[10] is 1. In that case you > will have SRP enabled, which means DWC_USB3_EN_OTG is also enabled. If > that's true, then you can access the OTG address space. > >> I guess that the otg driver should implement the programming model >> starting from figure 12-4 in the dwc3 controller spec. > > Indeed. See that you _must_ be sure that GHWPARAMS6 says you support > OTG. Otherwise this will not work for everybody. > >> If this implementation exists, can you give me a pointer, if not, what >> are the plans? > > We _do_ have plans, but not before mid-2012. Patches are welcome of > course. > > -- > balbi > Hi Felipe, all, I was thinking on some kind of architecture to the dwc3 driver that will support also otg and use this opportunity, which the dwc3 driver is still clean and neat, to keep it that way and let us better maintenance in the future. First of all, I noticed that Heikki already sent a patch on separating the otg_transceiver struct to usb_otg and usb_phy. IMO this is important if we want to create neat otg drivers, that will implement only otg logic, as I want to do now. http://marc.info/?l=linux-usb&m=132342667512493&w=2 I currently see the following as the dwc3 driver design: 1. SoC unique logic is implemented at the level of dwc3-xxx, as for example dwc3-omap. All platform specific initializations, logic that is related to the HW core which wrap the dwc3 core in some specific SoC solution is implemented in this layer. This operates as a standalone kernel module which will activate the core.c kernel module by adding the appropriate platform device. 2. core.c implements all logic done against the global register space of the dwc3 IP core. This kernel module also responsible for common tasks that are in use of the dwc3 different modes (peripheral/host/drd/otg) such as allocating the event buffers. This layer activates the appropriate software stack according to the DWC3_MODE (gadget/host) 3. gadget.c (and ep0.c) implement the gadget/peripheral mode and all logic done against the device register space of the dwc3 IP core. This is not a kernel module of its own, but as part of core.c kernel module. 4. xhci host: using "standard" xhci driver kernel module. I was thinking about adding new otg.c driver under the dwc3 directory, which will implement only otg related logic (no phy/transceiver logic) as explained in chapter 12.1 in Synopsys spec. This driver will be activated ("probed") by core.c when the DWC3_MODE is DRD. In Felipe's master branch, the core.c activates the gadget and host in case the DWC3_MODE is DRD. Instead I suggest that the core.c will activate the new otg.c driver which will implement the programming model as started in figure 12-4 in Synopsys spec. After the activation of the otg.c, it will check the GHWPARAMS6[10](=SRPSupport), for determining if OTG register space is available (as also illustrated in the figure 12-4) and if the otg interrupt handler can be settled, otg registers can be initialized, etc... As for the phy logic, I am not sure where it's goes in this design, I tried to follow the "OTG rework" loop and I understand that this in check by Kishon? Please correct or comment me on the above. If it is ok with you, I think I will be able to supply some initial patch to review in a few days. Thanks, Ido. -- Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- 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
