Hi, 2016-06-10 8:56 GMT+02:00 Felipe Balbi <balbi@xxxxxxxxxx>: > > Hi, > > John Youn <John.Youn@xxxxxxxxxxxx> writes: >> 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? > > the best scenario would be to runtime detection of this based on some > register. If that's not possible, then a DT flag would be nice, but I > would call the flag by something more human readable such as > "snps,activate-transceiver" or something like that. In case auto-detection is not possible, shouldn't be better to have a stm32 compatible, and associate it with dedicated params as done for other platforms? See drivers/usb/dwc2/platform.c Regards, Maxime -- 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
