[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <967484d9-4165-4b75-bbb7-a203c36e8beb@gmx.net>
Date: Mon, 26 May 2025 14:14:24 +0200
From: Stefan Wahren <wahrenst@....net>
To: Christoph Stoidner <C.Stoidner@...tec.de>, Andrew Lunn <andrew@...n.ch>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"upstream@...ts.phytec.de" <upstream@...ts.phytec.de>
Subject: Re: [PATCH v3] arm64: dts: freescale: imx93-phycore-som: Delay the
phy reset by a gpio
Am 26.05.25 um 12:04 schrieb Christoph Stoidner:
> On Mo, 2025-05-26 at 11:24 +0200, Stefan Wahren wrote:
>> Am 26.05.25 um 11:09 schrieb Christoph Stoidner:
>>> Hi Stefan,
>>>
>>> On Mo, 2025-05-26 at 08:44 +0200, Stefan Wahren wrote:
>>>> Hi Andrew,
>>>> hi Christoph
>>>>
>>>> Am 24.05.25 um 19:44 schrieb Andrew Lunn:
>>>>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-phycore-
>>>>>> som.dtsi
>>>>>> b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> index 88c2657b50e6..b481097f08a4 100644
>>>>>> --- a/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/freescale/imx93-phycore-som.dtsi
>>>>>> @@ -68,6 +68,8 @@ mdio: mdio {
>>>>>> ethphy1: ethernet-phy@1 {
>>>>>> compatible = "ethernet-phy-ieee802.3-c22";
>>>>>> reg = <1>;
>>>>>> + reset-gpios = <&gpio4 23 GPIO_ACTIVE_HIGH>;
>>>>>> + reset-assert-us = <30>;
>>>>> Is there anything in the datasheet about needing a delay after
>>>>> the
>>>>> reset? There is a DT property for this:
>>>>>
>>>>> reset-deassert-us:
>>>>> description:
>>>>> Delay after the reset was deasserted in microseconds.
>>>>> If
>>>>> this property is missing the delay will be skipped.
>>>> is it the time until the PHY finished its post reset
>>>> stabilization
>>>> (datasheet to call it T2 "reset to SMI ready")?
>>> The T2 ("Post reset stabilization time") in the datasheet is the
>>> time
>>> "prior to MDC preamble for register access", that is defined with
>>> 2ms.
>>> I did not use reset-deassert-us for it, because the first register
>>> access does anyway occur much later (I measured 4000ms).
Just to be sure, do you really mean 4000 milliseconds ?
>>>
>>> And we have the same for T4, the "Post power-up stabilization
>>> time".
>>> It is defined with a time of 50ms as "prior to MDC preamble for
>>> register access". But also here we just know, the register access
>>> happens much later - and treated it as enough.
>>>
>>> Formally, this may be valid to specify the 2ms as reset-deassert-
>>> us.
>>> But since the first register access is so much later, I thought we
>>> can
>>> save those 2ms.
>>>
>>> Are you fine with that?
>> I don't insist on an additional "reset-deassert-us". The question was
>> more about understanding.
> Great, thanks for thr feedback.
>
>>> Regards,
>>> Christoph
>>>
>>>
>>>>> Anyway:
>>>>>
>>>>> Reviewed-by: Andrew Lunn <andrew@...n.ch>
>>>>>
>>>>> Andrew
>>>>>
Powered by blists - more mailing lists