Re: [RESENDING] dwc2: Using internal phy (fs mode) for STM32F4x9 platform

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux