| Message ID | 20240619183255.34107-1-brgl@bgdev.pl |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: sa8775p-ride: support both board variants | expand |
On Fri, Jun 21, 2024 at 03:14:13PM GMT, Bartosz Golaszewski wrote: > On Thu, 20 Jun 2024 at 18:04, Andrew Halaney <ahalaney@redhat.com> wrote: > > > > > + > > > +&mdio { > > > + compatible = "snps,dwmac-mdio"; > > > + #address-cells = <1>; > > > + #size-cells = <0>; > > > + > > > + sgmii_phy0: phy@8 { > > > + compatible = "ethernet-phy-id31c3.1c33"; > > > + reg = <0x8>; > > > + device_type = "ethernet-phy"; > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>; > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>; > > > + reset-assert-us = <11000>; > > > + reset-deassert-us = <70000>; > > > > I need to read your other series still wrt "ocsgmii", but any chance you > > have access to docs indicating the reset timing? I've never had docs for > > the specific Marvell phy on the prior board or the Aquantia one on the > > new board... > > > > I have but they're not public. :( > > > Boot time is something automotive is always concerned over, so I just > > want to make sure that this timing isn't any longer than it needs to be. > > Right now it looks the same as the Marvell phy's in the "v2" boards etc > > and that made me raise my eyebrows. > > > > That's a good point but what else can we do? This should typically > execute in its own thread anyway. I guess all I'm asking is are these timings accurate? Ethernet is often considered one of the things that needs to be up early (think about getting the vehicle reverse status off the network for example), so in this case I meant to consider it part of the "boot time". If this is actually the recommended values then we're good, just wanting to make sure we're not reusing the Marvell values (which may or may not be accurate as I don't have the doc) since they could be larger than necessary, etc! Dealing with the phys is a long pole in the time to get ethernet up in my benchmarks in the past, that's why I made this change etc: https://lore.kernel.org/netdev/20231127-net-phy-reset-once-v2-1-448e8658779e@redhat.com/ If these reset numbers are accurate then we're all good here, just confirming since they match the "r2" version which uses the marvell phy instead of the aquantia phy, and that seemed like a suspicious coincidence! Thanks, Andrew
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Split the current .dts into two: the existing one keeps the name and supports revision 2 of the board while patch 2 adds a .dts for revision 3. Bartosz Golaszewski (2): arm64: dts: qcom: move common parts for sa8775p-ride variants into a .dtsi arm64: dts: qcom: sa8775p-ride-r3: add new board file arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts | 42 + arch/arm64/boot/dts/qcom/sa8775p-ride.dts | 841 +------------------ arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi | 817 ++++++++++++++++++ 4 files changed, 882 insertions(+), 819 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/sa8775p-ride-r3.dts create mode 100644 arch/arm64/boot/dts/qcom/sa8775p-ride.dtsi