On Tue, Mar 22, 2022 at 09:25:12AM +0100, Ahmad Fatoum wrote:
>On 22.03.22 09:19, Michael Grzeschik wrote:
>> On Tue, Mar 22, 2022 at 06:35:22AM +0100, Ahmad Fatoum wrote:
>>> On 21.03.22 23:17, Michael Grzeschik wrote:
>>>> On Wed, Jan 06, 2021 at 11:05:43AM +0100, Sascha Hauer wrote:
>>>>> On Mon, Dec 21, 2020 at 01:32:50AM +0100, Ahmad Fatoum wrote:
>>>>>> Linux doesn't seem to enforce a fixed order between phy_init and
>>>>>> phy_power_on. The Linux dwc2 driver does power_on and then phy_init,
>>>>>> which is the inverse of what barebox is currently doing.
>>>>>>
>>>>>> The PHYs normally used with dwc2 are written with this in mind.
>>>>>> For example, our stm32-usbphyc driver fails to disable:
>>>>>>
>>>>>>   ERROR: stm32-usbphyc 5a006000.usbphyc@5a006000.of: PLL not reset
>>>>>>   ERROR: phy1: phy exit failed --> -5
>>>>>>
>>>>>> Because Linux does exit -> power_off, but barebox does power_off ->
>>>>>> exit.
>>>>>>
>>>>>> Issue was raised upstream:
>>>>>> https://lore.kernel.org/lkml/6cd01e79-fdc0-3bd4-32b5-a85142533f8a@pengutronix.de/T/#t
>>>>>>
>>>>>> Until this is settled, swap the order to follow what Linux does.
>>>>>> This is suboptimal, because it means controller drivers have different
>>>>>> order of the operations and that you can't combine arbitrary PHYs and
>>>>>> controllers, but it seems unlikely we will support combinations that
>>>>>> aren't supported by Linux in the first place anyway.
>>>>>
>>>>> This is valuable information and I don't want it to be lost, so instead
>>>>> of applying this as a fixup I rewrote the subject to:
>>>>>
>>>>> usb: dwc2: swap order of phy_init and phy_power_on to what Linux does
>>>>>
>>>>> and applied it as a separate patch.
>>>>
>>>> With this patch applied, some stm32mp1 do seem to timeout when
>>>> addressing the core.
>>>>
>>>> WARNING: dwc2 49000000.usb-otg@49000000.of: dwc2_core_reset: Timeout! Waiting for Core Soft Reset
>>>> ERROR: dwc2 49000000.usb-otg@49000000.of: probe failed: Connection timed out
>>>>
>>>> When I revert this patch. Everything works fine again.
>>>>
>>>> Is it possible that we can revert it in mainline now?
>>>
>>> Since 0e37f94fbe1b ("phy: stm32: sync with upstream"), the phy-stm32-usbphyc now
>>> has no poweron/poweroff callbacks, so a revert seems to only slightly change
>>> timing. I'd suggest you dig some more.
>>
>> That is not true. phy_power_on also enables the phy_regulator. Changing
>> this order has the effect that the regulator is enabled after or before
>> phy_init call.
>
>Oh, good point.
>
>>>> How can I reproduce the case this was fixing in the first place?
>>>
>>> The case was that barebox calls poweron/init in a different order than Linux.
>>> This point is moot now though because poweron is no longer provided by the
>>> driver.
>>
>> Still not true, though.
>
>Isn't this the same order Linux uses? Powering on regulator and then phy_init?
>Why does it lead to issues in barebox, but not in Linux?

I have no clue so far. Especially as this seems to have implications on
the platform I am working on but not on the dk2. Although both use the
same st,stpmic1 node vdd_usb for the phy_regulator.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |