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. -- balbi
Attachment:
signature.asc
Description: PGP signature