The RGMII interface is designed for speeds up to 1G. Phylink already
imposes the design limits for MII interfaces, and additional
specification is unnecessary. Therefore, we can remove this property
without any effect.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/E1u3bkm-000Epw-QU@rmk-PC.armlinux.org.uk
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The `tx-sched-sp` property was removed in commit aed6864035 ("net:
stmmac: platform: Delete a redundant condition branch").
Therefore, it can be safely removed from the device tree.
Signed-off-by: Lad Prabhakar <prabhakar.csengg@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250218125157.412701-1-prabhakar.csengg@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
pcie2a and pcie3a both cause interrupt storms to occur. However, when
both are enabled simultaneously, the two combined interrupt storms will
lead to rcu stalls. Red Hat is the only company still using this board
and since we still need pcie3a, just disable pcie2a.
Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/qcoqksikfvdqxk6stezbzc7l2br37ccgqswztzqejmhrkhbrwt@ta4npsm35mqk
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
SA8540P-ride is one of the Qualcomm platforms that does not have access
to UEFI runtime services and on which the RTC registers are read-only,
as described in:
https://lore.kernel.org/all/20230202155448.6715-1-johan+linaro@kernel.org/
Reserve four bytes in one of the PMIC registers to hold the RTC offset
the same way as it was done for sc8280xp-crd which has similar
limitations:
commit e67b45582c ("arm64: dts: qcom: sc8280xp-crd: enable rtc")
On SA8540P-ride, the register bank SDAM6 of the first PMIC is not
writable. Following recommendations provided during the review, use
SDAM2 from the second PMIC at offset 0xa0 instead.
Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
Signed-off-by: Eric Chanudet <echanude@redhat.com>
Link: https://lore.kernel.org/r/20230809203506.1833205-1-echanude@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
With wider usage on more boards, there have been reports of the
following:
[ 315.016174] qcom-ethqos 20000.ethernet eth0: no phy at addr -1
[ 315.016179] qcom-ethqos 20000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
which has been fairly random and isolated to specific boards.
Early reports were written off as a hardware issue, but it has been
prevalent enough on boards that theory seems unlikely.
In bring up of a newer piece of hardware, similar was seen, but this
time _consistently_. Moving the reset to the mdio bus level (which isn't
exactly a lie, it is the only device on the bus so one could model it as
such) fixed things on that platform. Analysis on sa8540p-ride shows that
the phy's reset is not being handled during the OUI scan if the reset
lives in the phy node:
# gpio 752 is the reset, and is active low, first mdio reads are the OUI
modprobe-420 [006] ..... 154.738544: mdio_access: stmmac-0 read phy:0x08 reg:0x02 val:0x0141
modprobe-420 [007] ..... 154.738665: mdio_access: stmmac-0 read phy:0x08 reg:0x03 val:0x0dd4
modprobe-420 [004] ..... 154.741357: gpio_value: 752 set 1
modprobe-420 [004] ..... 154.741358: gpio_direction: 752 out (0)
modprobe-420 [004] ..... 154.741360: gpio_value: 752 set 0
modprobe-420 [006] ..... 154.762751: gpio_value: 752 set 1
modprobe-420 [007] ..... 154.846857: gpio_value: 752 set 1
modprobe-420 [004] ..... 154.937824: mdio_access: stmmac-0 write phy:0x08 reg:0x0d val:0x0003
modprobe-420 [004] ..... 154.937932: mdio_access: stmmac-0 write phy:0x08 reg:0x0e val:0x0014
Moving it to the bus level, or specifying the OUI in the phy's
compatible ensures the reset is handled before any mdio access
Here is tracing with the OUI approach (which skips scanning the OUI):
modprobe-549 [007] ..... 63.860295: gpio_value: 752 set 1
modprobe-549 [007] ..... 63.860297: gpio_direction: 752 out (0)
modprobe-549 [007] ..... 63.860299: gpio_value: 752 set 0
modprobe-549 [004] ..... 63.882599: gpio_value: 752 set 1
modprobe-549 [005] ..... 63.962132: gpio_value: 752 set 1
modprobe-549 [006] ..... 64.049379: mdio_access: stmmac-0 write phy:0x08 reg:0x0d val:0x0003
modprobe-549 [006] ..... 64.049490: mdio_access: stmmac-0 write phy:0x08 reg:0x0e val:0x0014
The OUI approach is taken given the description matches the situation
perfectly (taken from ethernet-phy.yaml):
- pattern: "^ethernet-phy-id[a-f0-9]{4}\\.[a-f0-9]{4}$"
description:
If the PHY reports an incorrect ID (or none at all) then the
compatible list may contain an entry with the correct PHY ID
in the above form.
The first group of digits is the 16 bit Phy Identifier 1
register, this is the chip vendor OUI bits 3:18. The
second group of digits is the Phy Identifier 2 register,
this is the chip vendor OUI bits 19:24, followed by 10
bits of a vendor specific ID.
With this in place the sa8540p-ride's phy is probing consistently, so
it seems the floating reset during mdio access was the issue. In either
case, it shouldn't be floating so this improves the situation. The below
link discusses some of the relationship of mdio, its phys, and points to
this OUI compatible as a way to opt out of the OUI scan pre-reset
handling which influenced this decision.
Link: https://lore.kernel.org/all/dca54c57-a3bd-1147-63b2-4631194963f0@gmail.com/
Fixes: 57827e87be ("arm64: dts: qcom: sa8540p-ride: Add ethernet nodes")
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230608201513.882950-1-ahalaney@redhat.com
Enable both the MACs found on the board.
ethernet0 and ethernet1 both ultimately go to a series of on board
switches which aren't managed by this processor.
ethernet0 is connected to a Marvell 88EA1512 phy via RGMII. That goes to
the series of switches via SGMII on the "media" side of the phy.
RGMII_SGMII mode is enabled via devicetree register descriptions.
The switch on the "media" side has auto-negotiation disabled, so
configuration from userspace similar to:
ethtool -s eth0 autoneg off speed 1000 duplex full
is necessary to get traffic flowing on that interface.
ethernet1 is in a mac2mac/fixed-link configuration going to the same
series of switches directly via RGMII.
Tested-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230501205105.2518373-3-ahalaney@redhat.com
The cdsp.mbn firmware that's referenced in sa8540p-ride.dts is actually
named cdsp0.mbn in the deliverables from Qualcomm. Let's go ahead and
correct the name to match what's in Qualcomm's deliverable.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230307232340.2370476-1-bmasney@redhat.com
It isn't obvious in the current devicetree what is connected. Go ahead
and document what's on the other end.
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Eric Chanudet <echanude@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230130154823.117542-2-ahalaney@redhat.com
Some of the pinctrl groups were invalid for the selected pins. Select
the proper qup group to fix these warnings:
[ 6.523566] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio135" for function "qup15"
[ 6.535042] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio136" for function "qup15"
[ 6.597536] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio158" for function "qup15"
[ 6.597544] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio159" for function "qup15"
[ 6.597991] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio0" for function "qup15"
[ 6.597996] sc8280xp-tlmm f100000.pinctrl: invalid group "gpio1" for function "qup15"
Fixes: e073899ec3 ("arm64: dts: qcom: sa8540p-ride: add i2c nodes")
Reviewed-by: Shazad Hussain <quic_shazhuss@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230130154823.117542-1-ahalaney@redhat.com
Add the necessary nodes in order to get i2c0, i2c1, i2c12, i2c15, and
i2c18 functioning on the automotive board and exposed to userspace.
This work was derived from various patches that Qualcomm delivered
to Red Hat in a downstream kernel. This change was validated by using
i2c-tools 4.3.3 on CentOS Stream 9:
[root@localhost ~]# i2cdetect -l
i2c-0 i2c Geni-I2C I2C adapter
i2c-1 i2c Geni-I2C I2C adapter
i2c-12 i2c Geni-I2C I2C adapter
i2c-15 i2c Geni-I2C I2C adapter
i2c-18 i2c Geni-I2C I2C adapter
[root@localhost ~]# i2cdetect -a -y 15
Warning: Can't use SMBus Quick Write command, will skip some addresses
0 1 2 3 4 5 6 7 8 9 a b c d e f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60:
70:
Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Shazad Hussain <quic_shazhuss@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230103182229.37169-9-bmasney@redhat.com
In preparation for adding the missing SPI and I2C nodes to
sc8280xp.dtsi, it was decided to rename all of the existing qupX_
uart, spi, and i2c nodes to drop the qupX_ prefix. Let's go ahead
and rename qup2_uart17 to uart17. Note that some nodes are moved in the
file by this patch to preserve the expected sort order in the file.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/lkml/20221212182314.1902632-1-bmasney@redhat.com/
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230103182229.37169-4-bmasney@redhat.com
pm8450a.dtsi was introduced for the descriptions of pmics used on
sa8540p based boards. Rename the dtsi to make this relationship
explicit.
Signed-off-by: Eric Chanudet <echanude@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com> # sa8540p-ride
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221219191000.2570545-2-echanude@redhat.com
Add the pcie2a, pcie2a_phy, and respective tlmm nodes that are needed to
get pcie 2a controller enabled on Qdrive3.
This patch enables 4GB 64bit memory space for PCIE_2A to have BAR
allocations of 64bit pref mem needed on this Qdrive3 platform with dual
SoCs for root port and switch NT-EP. Hence this ranges property is
overridden in sa8540p-ride.dts only.
Moved tlmm node at the end as it tends to become rahter long.
Link: https://lore.kernel.org/lkml/Y49k1k8ayI9%2FrK+R@hovoldconsulting.com/
Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221213095922.11649-1-quic_shazhuss@quicinc.com
Add the vreg_l11a, pcie3a, pcie3a_phy, and tlmm nodes that are necessary
in order to get PCIe working on the QDrive3.
This patch also increases the width of the ranges property for the PCIe
switch that's found on this platform. Note that this change requires
the latest trustzone (TZ) firmware that's available from Qualcomm as
of November 2022. If this is used against a board with the older
firmware, then the board will go into ramdump mode when PCIe is probed
on startup.
The ranges property is overridden in this sa8540p-ride.dts file since
this is what's used to describe the QDrive3 variant with dual SoCs.
There's another variant of this board that only has a single SoC where
this change is not applicable, and hence why this specific change was
not done in sa8540p.dtsi.
These changes were derived from various patches that Qualcomm
delivered to Red Hat in a downstream kernel.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202120918.2252647-1-bmasney@redhat.com
Introduce the Qualcomm SA8540P ride automotive platform, also known as
Qdrive-3 development board.
This initial contribution supports SMP, CPUFreq, cluster idle, UFS, RPMh
regulators, debug UART, PMICs, remoteprocs and USB.
The SA8540P ride contains four PM8450 PMICs. A separate DTSI file has
been created for PMIC, so that it can be used for future SA8540P based
boards.
Signed-off-by: Parikshit Pareek <quic_ppareek@quicinc.com>
Tested-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Tested-by: Eric Chanudet <echanude@redhat.com>
Reviewed-by: Eric Chanudet <echanude@redhat.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221118025158.16902-3-quic_ppareek@quicinc.com
