On Wed, Jun 15, 2016 at 2:04 AM, John Youn <John.Youn@xxxxxxxxxxxx> wrote: > On 6/13/2016 8:21 AM, Bruno Herrera wrote: >> Hi >> >> On Mon, Jun 13, 2016 at 9:19 AM, Maxime Coquelin >> <mcoquelin.stm32@xxxxxxxxx> wrote: >>> 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 >> >> looking into the documentation I could not find a way to auto detect >> the core is running on STM32. >> And the register used by ST is GGPIO, so it could be used for >> different purposes according to the SoC vendor. >> We will need to have a stm32 complatible dwc2_core_params because the >> parameters for the FS core are not the hw detected ones. >> >> So in this case I see 2 options: >> 1 - We create a param in the dwc2_core_params that is only for ST: >> int stm_activate_transceiver; >> >> 2 - We create a ST specific DT option for that: >> - stm32, activate-transceiver: >> > > Hi Bruno, > > For now, let's not create a DT and stick to the params based on > compatible string. It sounds like you need to implement that > anyways. > > We have some changes in the works redoing some of the parameter stuff > to make it more consistent. We can always change around that params > struct. But DT might be harder. > > Thanks, > John Hi John, Thanks for the feedback, I'll implement that way! Br, Bruno -- 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
