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 -- 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
