[PATCH] usb: dwc3-meson-g12a: add power-on/off of the PHYs

Neil Armstrong narmstrong at baylibre.com
Mon Apr 20 16:47:56 CEST 2020


On 20/04/2020 16:10, Marek Vasut wrote:
> On 4/20/20 4:07 PM, Neil Armstrong wrote:
> [...]
> 
>>>>>>> Doesn't checkpatch complain about this extra space before semicolon ?
>>>>>>
>>>>>> Nop, even in --strict
>>>>>
>>>>> Shouldn't it though ? I thought this extra space was forbidden.
>>>>
>>>> No idea, this line is copied from the for loop doing the phy init,
>>>> itself copied from the Linux code passing all checkpatch checks.
>>>
>>> Could you change it to for (i = 0; i < PHY_COUNT; i++) please ?
>>
>> Sure
> 
> Thank you.
> 
> ( I'm still surprised checkpatch doesn't warn about it, I was quite sure
> it was one of the checks at some point, hmmmmm. )
> 
>>>>>>>
>>>>>>>> +		if (!priv->phys[i].dev)
>>>>>>>> +			continue;
>>>>>>>> +
>>>>>>>> +		ret = generic_phy_power_on(&priv->phys[i]);
>>>>>>>
>>>>>>> Do we really need to turn on all the PHYs ?
>>>>>>>
>>>>>>
>>>>>> Yes
>>>>>
>>>>> Then should we have something like clk_bulk_*(), but for phys ?
>>>>>
>>>>
>>>> Eventually, yes, but this goes beyond a fix.
>>>
>>> The merge window is open for quite a bit longer, so doing this in a
>>> generic way would be appreciated.
>>>
>>> btw while you're at it, shouldn't the PHY_COUNT be replaced with some
>>> PHY count detection by reading the DT ? ( I don't have the hardware and
>>> I don't know the amlogic SoCs though )
>>>
>>
>> Hmm, the PHYs list can have some holes (i.e only the second PHY could be used on 3),
>> and the name of the PHY determines it's type and position (PHY1 is a special OTG phy)
>> this is why we loop over a fixed array and check if the PHY pointer exists.
> 
> Um, that sounds like a vaguely familiar problem. Is that an issue with
> mapping between controller and a USB PHY ? Is that mapping fixed or is
> it configured from DT ? 

Mapping is done via DT, all PHYs are optional depending on the board layout.

> And then, should all PHYs really be powered on,
> or should only the PHY matching the currently used controller be powered
> on ?

All PHYs are connected to a glue that muxes 1 PHY between DWC2 and DWC3, and
the other USB2 PHYs (for now 1, but previous SoCs had 2) to DWC3, the USB3 PHY
is muxed between PCIe to dw-pcie and DWC3.

So we power-on only the PHYs specified in DT, thus the:
	if (!priv->phys[i].dev)
		continue;

I attached the USB complex diagram if you need it.

Neil

> 
>> This won't match a phy_bulk_code directly, I would still need to map the bulk PHYs to this
>> array for the OTG and USB3 management.
> 
> OK
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: G12A USB.svg
Type: image/svg+xml
Size: 51866 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200420/80913a8d/attachment-0001.svg>


More information about the U-Boot mailing list