On 6/9/2016 10:18 AM, Bruno Herrera wrote: > Hello all, > I'm bringing the linux kernel for the STM32F4 MCU (mmu-less). This MCU > has two DWC2 cores on it:one for USB OTG HS and one for USB OTG FS. > I was able to make the DWC2 driver to work in FS mode using a internal > phy in both cores (HS and FS), but I had to patch it (in a bad way, > see bellow). > Basically STM32 uses a GGPIO register to control the POWER state of > the internal phy as it describes in the reference manual: > > OTG general core configuration register (OTG_GCCFG) > Address offset: 0x038 > Reset value: 0x0000 0000 > > Powerdown -> BIT(16) > Used to activate the transceiver in transmission/reception > 0: Power down active > 1: Power down deactivated (“Transceiver active”) > > So far what I did was in the dwc2_core_init > > + /* Program the GGPIO register */ > + usbgpio = dwc2_readl(hsotg->regs + GGPIO); > + usbgpio |= GGPIO_PWRDWN; > + dwc2_writel(usbgpio, hsotg->regs + GGPIO); > > So I would like to check what would be you recommendation to implement > in it in the right way. > As it is a internal USB core register I could not find a way to > implement a phy that access it. > Syscon is also not the case (I guess) for the same reason. > > One way I thought would be to create a new property like: > > - snps,ggpio-reg: the value of GGPIO register for specific SoC/Vendor > > in my STM32 case could be something like that: > > snps,ggpio-reg = <0x10> > > The problem with this approach is that it could not be toggled > "logicaly" from let say some phy on/off code. > > please share you thoughts on this. > Hi Bruno, Unfortunately I'm not familiar enough with devicetree or the PHY framework to think of a good solution. Felipe, Do you have any advice on the best way to handle this? Looks like soc-specific PHY controls are mapped to the controller GPIO. We can add SOC specific code directly in the driver, but is there a better way? Regards, John -- 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
