All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Karlman <jonas@kwiboo.se>
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, heiko@sntech.de,
	krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	robh@kernel.org
Subject: Re: [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY reset bindings for Lunzn Fastrhino R68S
Date: Wed, 10 Jul 2024 17:07:22 +0200	[thread overview]
Message-ID: <08cc4f4c-5c26-4dbd-8fbc-5686fbc06b80@kwiboo.se> (raw)
In-Reply-To: <20240710145010.688986-1-amadeus@jmu.edu.cn>

On 2024-07-10 16:50, Chukun Pan wrote:
>> Where do you find the 72ms in the datasheet?
> 
> I refer to this commit:
> https://github.com/torvalds/linux/commit/1c7412530d5d0e0a0b27f1642f5c13c8b9f36f05
> BTW I found that some boards use the RTL8211F-VD PHY,
> but I can't find the datasheet.

Thanks, I can also see in RTL8211F-VD-CG (Rev 1.0 - 08 February 2022):

  For a complete PHY reset, this pin must be asserted low for at least
  10ms for the internal regulator. Wait for at least 72ms* before
  accessing the PHY register. * Note: Not included the 0.9V rise time.

So using 80-100ms may be the best option to be on the safe side, should
probably send a fix for recently added boards where I used 50ms.

Regards,
Jonas

> 
>> In RTL8211F-CG v1.1 I see 10ms and minimum of 30ms, in v1.2 and v1.4
>> I see 10ms and minimum of 50ms.
> 
>> I have used 50ms on a few recently added boards and they seem to all
>> work fine with 50ms, wonder if the deassert delay should be changed for
>> those boards.
> 
> Thanks,
> Chukun
> 


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Karlman <jonas@kwiboo.se>
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, heiko@sntech.de,
	krzk+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	robh@kernel.org
Subject: Re: [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY reset bindings for Lunzn Fastrhino R68S
Date: Wed, 10 Jul 2024 17:07:22 +0200	[thread overview]
Message-ID: <08cc4f4c-5c26-4dbd-8fbc-5686fbc06b80@kwiboo.se> (raw)
In-Reply-To: <20240710145010.688986-1-amadeus@jmu.edu.cn>

On 2024-07-10 16:50, Chukun Pan wrote:
>> Where do you find the 72ms in the datasheet?
> 
> I refer to this commit:
> https://github.com/torvalds/linux/commit/1c7412530d5d0e0a0b27f1642f5c13c8b9f36f05
> BTW I found that some boards use the RTL8211F-VD PHY,
> but I can't find the datasheet.

Thanks, I can also see in RTL8211F-VD-CG (Rev 1.0 - 08 February 2022):

  For a complete PHY reset, this pin must be asserted low for at least
  10ms for the internal regulator. Wait for at least 72ms* before
  accessing the PHY register. * Note: Not included the 0.9V rise time.

So using 80-100ms may be the best option to be on the safe side, should
probably send a fix for recently added boards where I used 50ms.

Regards,
Jonas

> 
>> In RTL8211F-CG v1.1 I see 10ms and minimum of 30ms, in v1.2 and v1.4
>> I see 10ms and minimum of 50ms.
> 
>> I have used 50ms on a few recently added boards and they seem to all
>> work fine with 50ms, wonder if the deassert delay should be changed for
>> those boards.
> 
> Thanks,
> Chukun
> 



  reply	other threads:[~2024-07-10 15:07 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-30 15:00 [PATCH v2 0/9] arm64: dts: rockchip: fixes support for Lunzn Fastrhino R6xS Chukun Pan
2024-06-30 15:00 ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 1/9] arm64: dts: rockchip: fix regulator name " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 2/9] arm64: dts: rockchip: fix usb regulator " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 3/9] arm64: dts: rockchip: fix pmu_io supply " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 4/9] arm64: dts: rockchip: remove unused usb2 nodes " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 5/9] arm64: dts: rockchip: disable display subsystem " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 6/9] arm64: dts: rockchip: fixes PHY reset for Lunzn Fastrhino R68S Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY reset bindings " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-07-04 19:12   ` Heiko Stübner
2024-07-04 19:12     ` Heiko Stübner
2024-07-10 13:30     ` Chukun Pan
2024-07-10 13:30       ` Chukun Pan
2024-07-10 14:30       ` Jonas Karlman
2024-07-10 14:30         ` Jonas Karlman
2024-07-10 14:50         ` Chukun Pan
2024-07-10 14:50           ` Chukun Pan
2024-07-10 15:07           ` Jonas Karlman [this message]
2024-07-10 15:07             ` Jonas Karlman
2024-06-30 15:00 ` [PATCH v2 8/9] arm64: dts: rockchip: remove useless tx/rx_delay " Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-06-30 15:00 ` [PATCH v2 9/9] arm64: dts: rockchip: Enable UHS-I SDR-50 for Lunzn FastRhino R66S Chukun Pan
2024-06-30 15:00   ` Chukun Pan
2024-07-01 14:30 ` [PATCH v2 0/9] arm64: dts: rockchip: fixes support for Lunzn Fastrhino R6xS Chukun Pan
2024-07-01 14:30   ` Chukun Pan
2024-07-01 14:30   ` [PATCH v2 2/9] arm64: dts: rockchip: fix usb regulator " Chukun Pan
2024-07-01 14:30     ` Chukun Pan
2024-07-01 14:30   ` [PATCH v2 5/9] arm64: dts: rockchip: disable display subsystem " Chukun Pan
2024-07-01 14:30     ` Chukun Pan
2024-07-01 14:30   ` [PATCH v2 7/9] arm64: dts: rockchip: use generic Ethernet PHY reset bindings for Lunzn Fastrhino R68S Chukun Pan
2024-07-01 14:30     ` Chukun Pan
2024-07-04 19:10 ` (subset) [PATCH v2 0/9] arm64: dts: rockchip: fixes support for Lunzn Fastrhino R6xS Heiko Stuebner
2024-07-04 19:10   ` Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08cc4f4c-5c26-4dbd-8fbc-5686fbc06b80@kwiboo.se \
    --to=jonas@kwiboo.se \
    --cc=amadeus@jmu.edu.cn \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.