The vcc3v3-btreg regulator only has 1 state and no state gpios defined,
so "regulator-gpio" is not the correct binding to use. "regulator-fixed"
is the correct binding to use. It supports an enable GPIO which is
needed in this case.
Signed-off-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250409205047.1522943-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Follow most others rk356x based boards, and u-boot only use mmc0/1
as mmc boot targets, so aliase sdhci as mmc0.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
[demo-board only used internally by Rockchip, so changing the alias order
does not affect public users]
Link: https://lore.kernel.org/r/20241221104920.4193034-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
While looking through the vendor U-Boot code Heiko spotted that a SoC
GPIO is connected to the ethernet phy's reset pin. Add the respective
reset-gpios property with pinmuxing for the GPIO to the phy node.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/49f66206fccc714a8745b9ac35247615ad5cc369.1742331667.git.ukleinek@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
With the binding header now providing the SCMI_SRST_H_TRNG_NS constant,
switch back to it from the temporary numeric value.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Until now the emmc worked when booting because the bootrom set up the
pin config correctly to load the initial bootloader from it.
So when the kernel started it "just" reused this setup but never made
sure it was actually correct.
This then breaks when the system is started via some other means, like
downloading the initial bootloader via the bootrom usb download.
With actual emmc pin-config added, barebox is able to access the eMMC
even when booted via USB.
Fixes: 9da1c0327d ("arm64: dts: rockchip: Add basic support for QNAP TS-433")
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
[refined commit message to explain that we're currently just running
on bootom-goodwill]
Link: https://lore.kernel.org/r/20250319113138.125192-2-uwe@kleine-koenig.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The differences in the vendor-approved CPU and GPU OPPs for the standard
Rockchip RK3588 variant [1] and the industrial Rockchip RK3588J variant [2]
come from the latter, presumably, supporting an extended temperature range
that's usually associated with industrial applications, despite the two SoC
variant datasheets specifying the same upper limit for the allowed ambient
temperature for both variants. However, the lower temperature limit is
specified much lower for the RK3588J variant. [1][2]
To be on the safe side and to ensure maximum longevity of the RK3588J SoCs,
only the CPU and GPU OPPs that are declared by the vendor to be always safe
for this SoC variant may be provided. As explained by the vendor [3] and
according to the RK3588J datasheet, [2] higher-frequency/higher-voltage
CPU and GPU OPPs can be used as well, but at the risk of reducing the SoC
lifetime expectancy. Presumably, using the higher OPPs may be safe only
when not enjoying the assumed extended temperature range that the RK3588J,
as an SoC variant targeted specifically at higher-temperature, industrial
applications, is made (or binned) for.
Anyone able to keep their RK3588J-based board outside the above-presumed
extended temperature range at all times, and willing to take the associated
risk of possibly reducing the SoC lifetime expectancy, is free to apply
a DT overlay that adds the higher CPU and GPU OPPs.
With all this and the downstream RK3588(J) DT definitions [4][5] in mind,
let's delete the RK3588J CPU and GPU OPPs that are not considered belonging
to the normal operation mode for this SoC variant. To quote the RK3588J
datasheet [2], "normal mode means the chipset works under safety voltage
and frequency; for the industrial environment, highly recommend to keep in
normal mode, the lifetime is reasonably guaranteed", while "overdrive mode
brings higher frequency, and the voltage will increase accordingly; under
the overdrive mode for a long time, the chipset may shorten the lifetime,
especially in high-temperature condition".
To sum the RK3588J datasheet [2] and the vendor-provided DTs up, [4][5]
the maximum allowed CPU core, GPU and NPU frequencies are as follows:
IP core | Normal mode | Overdrive mode
------------+-------------+----------------
Cortex-A55 | 1,296 MHz | 1,704 MHz
Cortex-A76 | 1,608 MHz | 2,016 MHz
GPU | 700 MHz | 850 MHz
NPU | 800 MHz | 950 MHz
Unfortunately, when it comes to the actual voltages for the RK3588J CPU and
GPU OPPs, there's a discrepancy between the RK3588J datasheet [2] and the
downstream kernel code. [4][5] The RK3588J datasheet states that "the max.
working voltage of CPU/GPU/NPU is 0.75 V under the normal mode", while the
downstream kernel code actually allows voltage ranges that go up to 0.95 V,
which is still within the voltage range allowed by the datasheet. However,
the RK3588J datasheet also tells us to "strictly refer to the software
configuration of SDK and the hardware reference design", so let's embrace
the voltage ranges provided by the downstream kernel code, which also
prevents the undesirable theoretical outcome of ending up with no usable
OPPs on a particular board, as a result of the board's voltage regulator(s)
being unable to deliver the exact voltages, for whatever reason.
The above-described voltage ranges for the RK3588J CPU OPPs remain taken
from the downstream kernel code [4][5] by picking the highest, worst-bin
values, which ensure that all RK3588J bins will work reliably. Yes, with
some power inevitably wasted as unnecessarily generated heat, but the
reliability is paramount, together with the longevity. This deficiency
may be revisited separately at some point in the future.
The provided RK3588J CPU OPPs follow the slightly debatable "provide only
the highest-frequency OPP from the same-voltage group" approach that's been
established earlier, [6] as a result of the "same-voltage, lower-frequency"
OPPs being considered inefficient from the IPA governor's standpoint, which
may also be revisited separately at some point in the future.
[1] https://wiki.friendlyelec.com/wiki/images/e/ee/Rockchip_RK3588_Datasheet_V1.6-20231016.pdf
[2] https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2403201054_Rockchip-RK3588J_C22364189.pdf
[3] https://lore.kernel.org/linux-rockchip/e55125ed-64fb-455e-b1e4-cebe2cf006e4@cherry.de/T/#u
[4] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
[5] https://raw.githubusercontent.com/rockchip-linux/kernel/604cec4004abe5a96c734f2fab7b74809d2d742f/arch/arm64/boot/dts/rockchip/rk3588j.dtsi
[6] https://lore.kernel.org/all/20240229-rk-dts-additions-v3-5-6afe8473a631@gmail.com/
Fixes: 667885a686 ("arm64: dts: rockchip: Add OPP data for CPU cores on RK3588j")
Fixes: a7b2070505 ("arm64: dts: rockchip: Split GPU OPPs of RK3588 and RK3588j")
Cc: stable@vger.kernel.org
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Alexey Charkov <alchark@gmail.com>
Helped-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/eeec0d30d79b019d111b3f0aa2456e69896b2caa.1742813866.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 thermal sensor driver only receives interrupts when a
higher-temperature threshold is crossed; it cannot notify when the
sensor cools back off. As a result, the driver must poll for temperature
changes to detect when the conditions for a thermal trip are no longer
met. However, it only does so if the DT enables polling.
Before this patch, the RK1 DT did not enable polling, causing the fan to
continue running at the speed corresponding to the highest temperature
reached.
Follow suit with similar RK3588 boards by setting a polling-delay of
1000ms, enabling the driver to detect when the sensor cools back off,
allowing the fan speed to decrease as appropriate.
Fixes: 7c8ec5e6b9 ("arm64: dts: rockchip: Enable automatic fan control on Turing RK1")
Cc: stable@kernel.org # v6.13+
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250329165017.3885-1-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There is new support for additional on-chip devices on Apple, Mediatek,
Renesas, Rockchip, Samsung, Google, TI, ST, Nvidia and Amlogic devices.
The Arm Morello reference platform gets a devicetree for booting in
normal aarch64 mode. The hardware supports experimental CHERI support,
which requires a modified kernel.
The AMD (formerly Xilinx) Versal NET SoC gets added, this is a combined
FPGA with Cortex-A78 CPUs in a SoC.
Six new ST STM32MP2 SoC variants are added. Like the earlier STM32MP25,
the MP211, MP213, MP215, MP231, MP233 and MP235 models are based on one
or two Cortex-A35 cores but each feature a different set of I/O devices.
Mediatek MT8370 is a minor variation of MT8390 with fewer CPU and
GPU cores
Apple T2 is the baseboard management controller on earlier Intel CPU
based Macs, with 16 models now gaining initial support.
All the above come with dts files for the reference boards. In
addition, these boards are added for the SoCs that are already supported.
- The Milk-V Jupiter board based on SpacemiT K1/M1
- NetCube Systems Kumquat board based on the 32-bit Allwinner V3s SoC
- Three boards based on 32-bit stm32mp1
- 11 distinct board variants from Toradex and one from Variscite,
all based on i.MX6
- Google Pixel Pro 6 phone based on gs101 (Tensor)
- Three additional variants of the i.MX8MP based "Skov" board
- A second variant of the i.MX95 EVK board
- Two boards based on Renesas SoCs
- Four boards based the Rockchip RK35xx series, plus the RK3588
"MNT Reform 2" laptop
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmfkN4kACgkQYKtH/8kJ
Uied/g/+OA7VTWS9K9DMjmrDvrMn73GPRRuC3Se7NutHt5kQeQ8I0oFk3VILxiLx
/Rck8imIac65ANejy7M0omPYbVak6lyC0PRT9v/gZT++3rQzbd5/MAXHyKftVk6V
aEgIcFcbu3805dPf+ioIsyk5DshhlqRg0o3u9iMIJlzaykoLapSirnOW0/dcbz8V
kZlxuJRkQopx/+7/sbOtKXcL6ybif9jmgflQHUdGBT7Z7lAnhnIceelfKWPCQPki
TrQXG5YITJXEebyM399SwnAOl9pXs6z4KSYsULAfCONKOGwIXmcD1wDhZOtDUvoH
tu/V07R70fbEhJMTY5eZEc4Ym0firfk3IU3VRGxxOZJEuBOXN49snZzutNZEyqjX
WOjy4jgHTHhQQKc7++mB+5G7zfBPI2gcMnLWgU18Bq8LRcdLGOYPfQ6+PvkMJI8K
Vn/otYr80cSoJIPAmJZ9KvZiRmdqkK1YLxfOcNNjmFwk2YJxta7wmnbYX4g+zkkT
ZdlU5+iQp0BQnd37m3WU+b4Ed60dH/g5bflj6TzXEYqiHY4Kxoud9Z7AQTPj4FIu
PJiz+7J1p4a/uKK8BbVMjvnomARggdacrVDTB2mCfr6Av6c9RifAcREm0x6hZ2L8
dTR5fnh8zJ7sbmFwoS6ncUp4hgqotfZ/fYfK91xJ9rpyucOpnTE=
=6ZZ6
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC devicetree updates from Arnd Bergmann:
"There is new support for additional on-chip devices on Apple,
Mediatek, Renesas, Rockchip, Samsung, Google, TI, ST, Nvidia and
Amlogic devices.
The Arm Morello reference platform gets a devicetree for booting in
normal aarch64 mode. The hardware supports experimental CHERI support,
which requires a modified kernel.
The AMD (formerly Xilinx) Versal NET SoC gets added, this is a
combined FPGA with Cortex-A78 CPUs in a SoC.
Six new ST STM32MP2 SoC variants are added. Like the earlier
STM32MP25, the MP211, MP213, MP215, MP231, MP233 and MP235 models are
based on one or two Cortex-A35 cores but each feature a different set
of I/O devices.
Mediatek MT8370 is a minor variation of MT8390 with fewer CPU and GPU
cores
Apple T2 is the baseboard management controller on earlier Intel CPU
based Macs, with 16 models now gaining initial support.
All the above come with dts files for the reference boards. In
addition, these boards are added for the SoCs that are already
supported:
- The Milk-V Jupiter board based on SpacemiT K1/M1
- NetCube Systems Kumquat board based on the 32-bit Allwinner V3s SoC
- Three boards based on 32-bit stm32mp1
- 11 distinct board variants from Toradex and one from Variscite, all
based on i.MX6
- Google Pixel Pro 6 phone based on gs101 (Tensor)
- Three additional variants of the i.MX8MP based "Skov" board
- A second variant of the i.MX95 EVK board
- Two boards based on Renesas SoCs
- Four boards based the Rockchip RK35xx series, plus the RK3588 'MNT
Reform 2' laptop"
* tag 'soc-dt-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (538 commits)
arm64: dts: Add gpio_intc node for Amlogic A5 SoCs
arm64: dts: Add gpio_intc node for Amlogic A4 SoCs
arm64: dts: hi3660: Add property for fixing CPUIdle
arm64: dts: rockchip: remove ethm0_clk0_25m_out from Sige5 gmac0
arm64: dts: marvell: Use preferred node names for "simple-bus"
arm64: dts: marvell: Drop unused CP11X_TYPE define
arm64: dts: marvell: Move arch timer and pmu nodes to top-level
arm64: dts: rockchip: Fix PWM pinctrl names
arm64: dts: rockchip: fix RK3576 SCMI clock IDs
dt-bindings: clock: rk3576: add SCMI clocks
arm64: dts: rockchip: Fix pcie reset gpio on Orange Pi 5 Max
arm64: dts: amd/seattle: Drop undocumented "spi-controller" properties
arm64: dts: amd/seattle: Fix bus, mmc, and ethernet node names
arm64: dts: amd/seattle: Move and simplify fixed clocks
arm64: dts: amd/seattle: Base Overdrive B1 on top of B0 version
arm64: dts: rockchip: Enable HDMI audio output for ArmSoM Sige7
arm64: dts: rockchip: Enable onboard eMMC on Radxa E20C
arm64: dts: rockchip: Add SDHCI controller for RK3528
arm64: dts: rockchip: Remove bluetooth node from rock-3a
arm64: dts: rockchip: Move rk356x scmi SHMEM to reserved memory
...
Updates to the usual drivers (scsi_debug, ufs, lpfc, st, fnic, mpi3mr,
mpt3sas) and the removal of cxlflash. The only non-trivial core change
is an addition to unit attention handling to recognize UAs for power
on/reset and new media so the tape driver can use it.
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCZ+RQ2yYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishe6DAQCdW/21
S1Y6BDlJLQfpWChGv6GIzanC+5sMfylw4d6ULgEA8upOE5L3fC29IY958jXig0o1
uLjxylwYEfVLDf8gwJ0=
=mkM+
-----END PGP SIGNATURE-----
Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI updates from James Bottomley:
"Updates to the usual drivers (scsi_debug, ufs, lpfc, st, fnic, mpi3mr,
mpt3sas) and the removal of cxlflash.
The only non-trivial core change is an addition to unit attention
handling to recognize UAs for power on/reset and new media so the tape
driver can use it"
* tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (107 commits)
scsi: st: Tighten the page format heuristics with MODE SELECT
scsi: st: ERASE does not change tape location
scsi: st: Fix array overflow in st_setup()
scsi: target: tcm_loop: Fix wrong abort tag
scsi: lpfc: Restore clearing of NLP_UNREG_INP in ndlp->nlp_flag
scsi: hisi_sas: Fixed failure to issue vendor specific commands
scsi: fnic: Remove unnecessary NUL-terminations
scsi: fnic: Remove redundant flush_workqueue() calls
scsi: core: Use a switch statement when attaching VPD pages
scsi: ufs: renesas: Add initialization code for R-Car S4-8 ES1.2
scsi: ufs: renesas: Add reusable functions
scsi: ufs: renesas: Refactor 0x10ad/0x10af PHY settings
scsi: ufs: renesas: Remove register control helper function
scsi: ufs: renesas: Add register read to remove save/set/restore
scsi: ufs: renesas: Replace init data by init code
scsi: ufs: dt-bindings: renesas,ufs: Add calibration data
scsi: mpi3mr: Task Abort EH Support
scsi: storvsc: Don't report the host packet status as the hv status
scsi: isci: Make most module parameters static
scsi: megaraid_sas: Make most module parameters static
...
- Support for hard indices on RISC-V. The hart index identifies a hart
(core) within a specific interrupt domain in RISC-V's Priviledged
Architecture.
- Rework of the RISC-V MSI driver.
This moves the driver over to the generic MSI library and solves the
affinity problem of unmaskable PCI/MSI controllers. Unmaskable PCI/MSI
controllers are prone to lose interrupts when the MSI message is
updated to change the affinity because the message write consists of
three 32-bit subsequent writes, which update address and data. As these
writes are non-atomic versus the device raising an interrupt, the
device can observe a half written update and issue an interrupt on the
wrong vector. This is mitiated by a carefully orchestrated step by step
update and the observation of an eventually pending interrupt on the
CPU which issues the update. The algorithm follows the well established
method of the X86 MSI driver.
- A new driver for the RISC-V Sophgo SG2042 MSI controller
- Overhaul of the Renesas RZQ2L driver.
Simplification of the probe function by using devm_*() mechanisms,
which avoid the endless list of error prone gotos in the failure paths.
- Expand the Renesas RZV2H driver to support RZ/G3E SoCs
- A workaround for Rockchip 3568002 erratum in the GIC-V3 driver to
ensure that the addressing is limited to the lower 32-bit of the
physical address space.
- Add support for the Allwinner AS23 NMI controller
- Expand the IMX irqsteer driver to handle up to 960 input interrupts
- The usual small updates, cleanups and device tree changes.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmff454THHRnbHhAbGlu
dXRyb25peC5kZQAKCRCmGPVMDXSYoZqoD/4kdHzbxfLpf7vC3NnG8NWwTq5FpbSx
6grQC9hWNMAs4n2IFjJRFLrjeX3AcdAQXL/BWuM0LfW9tQDQaVmqlSIlB/bn69KB
7HyAR6ozbOgnHKGAqFUXSLf+4pq+6q3mOgGKIF289dy14HFu4ta0DqKgkPZeQnVs
R/J8i7REUnn+YuxzSt5eOqyDPyt2EHJosSUABSWQZBlrM9jy1W7f6NqDFwawiVsa
+tv4U/bz91vjzVxwTIgt7nJK+b2HVYdxoZYuKJwPaTsj26ANPp6ltjRTeOmZhb5h
uKgw+OyzDnk6q+tjGcRqrqwl291VKxCvnRiqHFfu3CERdmI9qvpN9IRcEJqIbkcN
cakekhAyt7OO7sEPcql5vBL97e9hpb7EcH78gYxwHf8Dy0rFZUvSC5v+L6VRFnJS
XcKA1L+f9B6u5qxnBtLan9IW08HYNdvmPq6AuVjk+ndKioPUFqB2q6AtXpuA3Rmu
Y3XH/wh/q5wk0pgeByxQW6swsfpMN3OYK3mpLx475wFh2NKzcdGlwGhDFhiw8DKX
m1AESy3UZatj1a0qGaFS/M+mm9KGrDYIMrje832Wf4Yf1LGmTsDkd3/V99oazSsq
Jm4qhDASXChJXd0imQICX9hPw0aHTlLYNs54obUXVULH4HivQKIgWhUXrjG0dBDL
+tttjuv5FJxr3A==
=jPHa
-----END PGP SIGNATURE-----
Merge tag 'irq-drivers-2025-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq driver updates from Thomas Gleixner:
- Support for hard indices on RISC-V. The hart index identifies a hart
(core) within a specific interrupt domain in RISC-V's Priviledged
Architecture.
- Rework of the RISC-V MSI driver
This moves the driver over to the generic MSI library and solves the
affinity problem of unmaskable PCI/MSI controllers. Unmaskable
PCI/MSI controllers are prone to lose interrupts when the MSI message
is updated to change the affinity because the message write consists
of three 32-bit subsequent writes, which update address and data. As
these writes are non-atomic versus the device raising an interrupt,
the device can observe a half written update and issue an interrupt
on the wrong vector. This is mitiated by a carefully orchestrated
step by step update and the observation of an eventually pending
interrupt on the CPU which issues the update. The algorithm follows
the well established method of the X86 MSI driver.
- A new driver for the RISC-V Sophgo SG2042 MSI controller
- Overhaul of the Renesas RZQ2L driver
Simplification of the probe function by using devm_*() mechanisms,
which avoid the endless list of error prone gotos in the failure
paths.
- Expand the Renesas RZV2H driver to support RZ/G3E SoCs
- A workaround for Rockchip 3568002 erratum in the GIC-V3 driver to
ensure that the addressing is limited to the lower 32-bit of the
physical address space.
- Add support for the Allwinner AS23 NMI controller
- Expand the IMX irqsteer driver to handle up to 960 input interrupts
- The usual small updates, cleanups and device tree changes
* tag 'irq-drivers-2025-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (40 commits)
irqchip/imx-irqsteer: Support up to 960 input interrupts
irqchip/sunxi-nmi: Support Allwinner A523 NMI controller
dt-bindings: irq: sun7i-nmi: Document the Allwinner A523 NMI controller
irqchip/davinci-cp-intc: Remove public header
irqchip/renesas-rzv2h: Add RZ/G3E support
irqchip/renesas-rzv2h: Update macros ICU_TSSR_TSSEL_{MASK,PREP}
irqchip/renesas-rzv2h: Update TSSR_TIEN macro
irqchip/renesas-rzv2h: Add field_width to struct rzv2h_hw_info
irqchip/renesas-rzv2h: Add max_tssel to struct rzv2h_hw_info
irqchip/renesas-rzv2h: Add struct rzv2h_hw_info with t_offs variable
irqchip/renesas-rzv2h: Use devm_pm_runtime_enable()
irqchip/renesas-rzv2h: Use devm_reset_control_get_exclusive_deasserted()
irqchip/renesas-rzv2h: Simplify rzv2h_icu_init()
irqchip/renesas-rzv2h: Drop irqchip from struct rzv2h_icu_priv
irqchip/renesas-rzv2h: Fix wrong variable usage in rzv2h_tint_set_type()
dt-bindings: interrupt-controller: renesas,rzv2h-icu: Document RZ/G3E SoC
riscv: sophgo: dts: Add msi controller for SG2042
irqchip: Add the Sophgo SG2042 MSI interrupt controller
dt-bindings: interrupt-controller: Add Sophgo SG2042 MSI
arm64: dts: rockchip: rk356x: Move PCIe MSI to use GIC ITS instead of MBI
...
The GPIO3 A4 pin on the ArmSoM Sige5 is routed to the 40-pin GPIO
header. This pin can serve a variety of functions, including ones of
questionable use to us on a GPIO header such as the 25MHz clock of the
ethernet controller.
Unfortunately, this is the precise function that it is being claimed for
by the gmac0 node in the Sige5 board dts, meaning it can't be used for
anything else despite serving no useful function in this role. Since it
goes through a RS0108 bidirectional voltage level translator with a
maximum data rate of 24Mbit/s in push-pull mode and 2Mbit/s data rate in
open-drain mode, it's doubtful as to whether the 25MHz clock signal
would even survive to the actual user-accessible pin it terminates in.
Remove it to leave the pin for users to play with. It's infinitely more
useful as a GPIO or even as a PWM.
Fixes: 40f742b07a ("arm64: dts: rockchip: Add rk3576-armsom-sige5 board")
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250314-rk3576-sige5-eth-clk-begone-v1-1-2858338fc555@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
These Rockchip boards assign "active" as the pinctrl name for PWM
controllers, which has never been supported in mainline Rockchip PWM
driver. It seems the name used by downstream kernel is accidentally
brought into maineline. Let's fix them.
Fixes: 4403e1237b ("arm64: dts: rockchip: Add devicetree for board roc-rk3308-cc")
Fixes: 964ed0807b ("arm64: dts: rockchip: add rk3318 A95X Z2 board")
Fixes: e7a0959082 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Fixes: 3f5d336d64 ("arm64: dts: rockchip: Add support for rk3588s based board Cool Pi 4B")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Link: https://lore.kernel.org/r/20250310140916.14384-2-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Downstream Linux, and consequently both downstream and mainline TF-A,
all use a different set of clock IDs from mainline Linux. If we want to
fiddle with these clocks through SCMI, we'll need to use the right IDs.
If we don't do this we'll end up changing unrelated clocks all over the
place.
Change the clock IDs to the newly added SCMI clock IDs for the CPU and
GPU nodes, which are currently the only ones using SCMI clocks. This
fixes the terrible GPU performance, as we weren't reclocking it
properly.
Fixes: 57b1ce9039 ("arm64: dts: rockchip: Add rk3576 SoC base DT")
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Closes: https://libera.irclog.whitequark.org/linux-rockchip/2025-03-09#1741542223-1741542875;
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250310-rk3576-scmi-clocks-v1-2-e165deb034e8@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to the schematic, pcie reset gpio is GPIO3_D4,
not GPIO4_D4.
Fixes: c600d252dc ("arm64: dts: rockchip: Add Orange Pi 5 Max board")
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Reviewed-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250311141245.2719796-1-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Radxa E20C may come with an onboard eMMC (8GB / 16GB / 32GB / 64GB).
Enable support for the onboard eMMC on Radxa E20C.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250305214108.1327208-4-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The SDHCI controller in Rockchip RK3528 is similar to the one included
in RK3588.
Add device tree node for the SDHCI controller in RK3528.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250305214108.1327208-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Bluetooth node described in the device tree is actually on an M.2
slot. What module is present depends on what the end user installed,
and should be left to an overlay.
Remove the existing bluetooth node. This gets rid of bogus timeout
errors.
Fixes: 8cf890aabd ("arm64: dts: rockchip: Add nodes for SDIO/UART Wi-Fi/Bluetooth modules to Radxa Rock 3A")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20250220165051.1889055-1-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
0x0 to 0xf0000000 are SDRAM memory areas where 0x10f000 is located.
So move the SHMEM memory of arm_scmi to the reserved memory node.
Fixes: a3adc0b907 ("arm64: dts: rockchip: add core dtsi for RK3568 SoC")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250308100001.572657-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
ArmSoM Sige7 uses the PCI-e AP6275P Wi-Fi 6 module. The pcie@0 node can
be used as Bridge1, so the wifi@0 node is used as a device under the
bridge 1 similar with Khadas Edge 2.
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Link: https://lore.kernel.org/r/20250311142825.2727171-1-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The current max-frequency 200000000 of emmc is not stable. When doing
heavy write there will be I/O Error. After setting max-frequency to
150000000 the emmc is stable under write.
Also remove property mmc-hs200-1_8v because we are already running at
HS400 mode.
Tested with fio command:
fio -filename=./test_randread -direct=1 -iodepth 1 -thread \
-rw=randwrite -ioengine=psync -bs=16k -size=1G -numjobs=10 \
-runtime=600 -group_reporting -name=mytest
Signed-off-by: Jianfeng Liu <liujianfeng1994@gmail.com>
Link: https://lore.kernel.org/r/20250228143341.70244-1-liujianfeng1994@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The SPI NOR chip is connected on the FSPI0 core, so enable the sfc0 node
and add the flash device to it.
The SPI NOR won't work at higher speed than 50 MHz, specify the limit.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20250228145304.581349-3-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E20C has two buttons, one SARADC maskrom button and one GPIO user
button.
Add support for the maskrom button using a adc-keys node, also add the
regulators used by SARADC controller.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250304201642.831218-5-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E20C has two buttons, one SARADC maskrom button and one GPIO user
button.
Add support for the user button using a gpio-keys node.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250304201642.831218-3-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E20C has three gpio controlled leds (sys, wan and lan).
Add led nodes and set default trigger to heartbeat for the sys led and
netdev for the lan and wan leds.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250304201642.831218-2-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Same as RK3568, RK3528 uses SCMI clk instead of ARMCLK.
Add SCMI clk for CPU, GPU and RNG will also use it.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250307100008.789129-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rock 5B has a Micro HDMI port, which can be used for receiving
HDMI data. This enables support for it.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Link: https://lore.kernel.org/r/20250307091857.646581-3-dmitry.osipenko@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Quality-of-Service (QsS) node stores/restores specific
register contents when the power domains is turned off/on.
Add QoS node so that they can connect to the power domain.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250306123809.273655-3-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
MNT Reform 2 is an open source laptop with replaceable CPU modules,
including a version with the RK3588-based MNT RCORE[1], which is based
on Firefly's iCore-3588Q SoM:
- Rockchip RK3588
- Quad A76 and Quad A55 CPU
- 6 TOPS NPU
- up to 32GB LPDDR4x RAM
- SD Card slot
- Gigabit ethernet port
- HDMI port
- 2x mPCIe ports for WiFi or NVMe
- 3x USB 3.0 Type-A HOST port
[1] https://shop.mntre.com/products/mnt-reform
Co-developed-by: "Lukas F. Hartmann" <lukas@mntre.com>
Signed-off-by: "Lukas F. Hartmann" <lukas@mntre.com>
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Link: https://lore.kernel.org/r/Z8S6uDM634KJuyKP@windev.fritz.box
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E20C route UART0 M0 pins (GPIO4_C7 and GPIO4_D0) to the onboard
CH340B for debug console use.
Add pinctrl for UART0 M0 pins used for serial console.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250228064024.3200000-6-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add pinctrl and gpio nodes for RK3528 and import rk3528-pinctrl.dtsi
from vendor linux-6.1-stan-rkr5 kernel with the hdmi-pins-idle node
removed due to missing label reference to pcfg_output_low_pull_down.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250228064024.3200000-5-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0"
node in the Pine64 RockPro64 board dtsi file. This eliminates the following
warnings from the kernel log:
rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator
rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator
These additions improve the accuracy of hardware description of the RockPro64
and, in theory, they should result in no functional changes to the way board
works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are
always enabled. [1][2] However, extended reliability testing, performed by
Chris, [3] has proven that the age-old issues with some PCI Express cards,
when used with a Pine64 RockPro64, are also resolved.
Those issues were already mentioned in the commit 43853e843a (arm64: dts:
rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01),
together with a brief description of the out-of-tree enumeration delay patch
that reportedly resolves those issues. In a nutshell, booting a RockPro64
with some PCI Express cards attached to it caused a kernel oops. [4]
Symptomatically enough, to the commit author's best knowledge, only the Pine64
RockPro64, out of all RK3399-based boards and devices supported upstream, has
been reported to suffer from those PCI Express issues, and only the RockPro64
had some of the PCI Express supplies missing in its DT. Thus, perhaps some
weird timing issues exist that caused the "vcca_1v8" always-on regulator,
which is part of the RK808 PMIC, to actually not be enabled before the PCI
Express is initialized and enumerated on the RockPro64, causing oopses with
some PCIe cards, and the aforementioned enumeration delay patch [4] probably
acted as just a workaround for the underlying timing issue.
Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard
PCI Express slot, allowing use of various standard cards, but pretty much
standard PCI Express cards have been attached to other RK3399 boards as well,
and the commit author is unaware ot such issues reported for them.
It's quite hard to be sure that the PCI Express issues are fully resolved by
these additions to the DT, without some really extensive and time-consuming
testing. However, these additions to the DT can result in good things and
improvements anyway, making them perfectly safe from the standpoint of being
unable to do any harm or cause some unforeseen regressions.
These changes apply to the both supported hardware revisions of the Pine64
RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2]
[1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
[2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf
[3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements
[4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gmail.com/T/#u
Fixes: bba821f547 ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64")
Cc: stable@vger.kernel.org
Cc: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Cc: Peter Geis <pgwipeout@gmail.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Reported-by: Diederik de Haas <didi.debian@cknow.org>
Tested-by: Chris Vogel <chris@z9.de>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Tested-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.1740941097.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add missing "avdd-0v9-supply" and "avdd-1v8-supply" properties to the "hdmi"
node in the Pine64 RockPro64 board dtsi file. To achieve this, also add the
associated "vcca_0v9" regulator that produces the 0.9 V supply, [1][2] which
hasn't been defined previously in the board dtsi file.
This also eliminates the following warnings from the kernel log:
dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator
dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator
There are no functional changes to the way board works with these additions,
because the "vcc1v8_dvp" and "vcca_0v9" regulators are always enabled, [1][2]
but these additions improve the accuracy of hardware description.
These changes apply to the both supported hardware revisions of the Pine64
RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2]
[1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
[2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf
Fixes: e4f3fb4909 ("arm64: dts: rockchip: add initial dts support for Rockpro64")
Cc: stable@vger.kernel.org
Suggested-by: Diederik de Haas <didi.debian@cknow.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Tested-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/df3d7e8fe74ed5e727e085b18c395260537bb5ac.1740941097.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Property "supports-sd" isn't documented anywhere and is unnecessary for
mainline driver to function. It seems a property used by downstream
kernel was brought into mainline.
This should be reported by dtbs_check, but mmc-controller-common.yaml
defaults additionalProperties to true thus allows it. Remove the
property to clean the devicetree up and avoid possible confusion.
Fixes: 8d94da58de ("arm64: dts: rockchip: Add EmbedFire LubanCat 1")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Link: https://lore.kernel.org/r/20250228163117.47318-2-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Jaguar has two type-c ports connected to fusb302 controllers that can
work both in host and device mode and can also run in display-port
altmode.
While these ports can work in dual-role data mode, they do not support
powering the device itself as power-sink. This causes issues because
the current infrastructure does not cope well with dual-role data
without dual-role power.
So add the necessary nodes for the type-c controllers as well as enable
the relevant core usb nodes. So far host modes works reliably, but
device-mode does not. So devicemode needs more investigation.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250228150853.329175-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enabling the GPU power domain requires that the GPU regulator is
enabled. The regulator is enabled at boot time, but gets disabled
automatically when there are no users.
This means the system might run into a failure state hanging the
whole system for the following use cases:
* if the GPU driver is being probed late (e.g. build as a
module and firmware is not in initramfs), the regulator
might already have been disabled. In that case the power
domain is enabled before the regulator.
* unbinding the GPU driver will disable the PM domain and
the regulator. When the driver is bound again, the PM
domain will be enabled before the regulator and error
appears.
Avoid this by adding an explicit regulator dependency to the
power domain.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reported-by: Adrián Martínez Larumbe <adrian.larumbe@collabora.com>
Tested-by: Adrian Larumbe <adrian.larumbe@collabora.com> # On Rock 5B
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20250220-rk3588-gpu-pwr-domain-regulator-v6-8-a4f9c24e5b81@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the only HDMI output port on the Orange Pi 5 Ultra
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Tested-By: Johannes Erdfelt <johannes@erdfelt.com>
Link: https://lore.kernel.org/r/20250222193332.1761-5-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 Single Board Computer includes
- eMMC
- microSD
- UART
- 2 PWM LEDs
- RTC
- RTL8125 network controller on PCIe 2.0x1.
- M.2 M-key connector routed to PCIe 3.0x4
- PWM controlled heat sink fan.
- 2 USB2 ports
- lower USB3 port
- upper USB3 port with OTG capability
- Mali GPU
- SPI NOR flash
- Mask Rom button
- Analog audio using es8388 codec via the headset jack and onboard mic
- HDMI1
- HDMI IN
the vcc5v0_usb30 regulator shares the same enable gpio pin as the
vcc5v0_usb20 regulator.
The Orange Pi 5 Ultra is a single board computer powered by the Rockchip
RK3588 with similar board layout as the 5 Max but with the HDMI0 swapped
for HDMI IN.
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Tested-By: Johannes Erdfelt <johannes@erdfelt.com>
Link: https://lore.kernel.org/r/20250222193332.1761-4-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Orange Pi 5 Plus and Orange Pi 5 Max have 2SK3018s attached to the
PWM LEDs. The Orange Pi 5 Ultra does not, and thus needs the PWM
polarity inverted.
Also remove the model/compatible from the dtsi. It should be at the
board level only.
Fixes: c600d252dc ("arm64: dts: rockchip: Add Orange Pi 5 Max board")
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250222193332.1761-2-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
UART5 uses GPIO0_B5 as UART RTS but muxed in its GPIO function,
therefore UART5 must request this pin to be muxed in that function, so
let's do that.
Fixes: 5963d97aa7 ("arm64: dts: rockchip: add rs485 support on uart5 of px30-ringneck-haikou")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250225-ringneck-dtbos-v3-2-853a9a6dd597@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
UART0 pinmux by default configures GPIO0_B5 in its UART RTS function for
UART0. However, by default on Haikou, it is used as GPIO as UART RTS for
UART5.
Therefore, let's update UART0 pinmux to not configure the pin in that
mode, a later commit will make UART5 request the GPIO pinmux.
Fixes: c484cf93f6 ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250225-ringneck-dtbos-v3-1-853a9a6dd597@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The u2phy1_host should always have the same status as usb_host1_ehci
and usb_host1_ohci, otherwise the EHCI and OHCI drivers may be
initialized for a disabled usb port.
Per the NanoPi R4S schematic, the phy-supply for u2phy1_host is set to
the vdd_5v regulator.
Fixes: db792e9adb ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S")
Cc: stable@vger.kernel.org
Signed-off-by: Justin Klaassen <justin@tidylabs.net>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250225170420.3898-1-justin@tidylabs.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
HDMI audio is available on the Rock 5B HDMI TX ports.
Enable it for both ports.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Fixes: 419d191810 ("ASoC: simple-card-utils: use __free(device_node) for device node")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20250217215641.372723-4-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
For hdmi0_sound, use the simple-audio-card driver with the hdmi0 QP node
as CODEC and the i2s5 device as CPU.
Similarly for hdmi1_sound, the CODEC is the hdmi1 node and the CPU is
i2s6, but only added in the rk3588-extra.dtsi device tree as the second
TX HDMI port is not available on base versions of the SoC.
The simple-audio-card,mclk-fs value is set to 128 as it is done in
the downstream driver.
The #sound-dai-cells value is set to 0 in the hdmi0 and hdmi1 nodes so
that they can be used as audio codec nodes.
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Tiger Haikou
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Fixes: 419d191810 ("ASoC: simple-card-utils: use __free(device_node) for device node")
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20250217215641.372723-3-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT changes to enable the second HDMI output port on
Rockchip RK3588 EVB1.
While at it, switch the position of &vop_mmu and @vop to maintain the
alphabetical order.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250223-vop2-hdmi1-disp-modes-v2-5-f4cec5e06fbe@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
VOP2 on RK3588 is able to use the HDMI PHY PLL as an alternative and
more accurate pixel clock source to improve handling of display modes up
to 4K@60Hz on video ports 0, 1 and 2.
The HDMI1 PHY PLL clock source cannot be added directly to vop node in
rk3588-base.dtsi, along with the HDMI0 related one, because HDMI1 is an
optional feature and its PHY node belongs to a separate (extra) DT file.
Therefore, add the HDMI1 PHY PLL clock source to VOP2 by overwriting its
clocks & clock-names properties in the extra DT file.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250223-vop2-hdmi1-disp-modes-v2-4-f4cec5e06fbe@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Since commit c4b09c5620 ("phy: phy-rockchip-samsung-hdptx: Add clock
provider support"), the HDMI PHY PLL can be used as an alternative and
more accurate pixel clock source for VOP2 to improve display modes
handling on RK3588 SoC.
Add the missing #clock-cells property to allow using the clock provider
functionality of HDMI1 PHY.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250223-vop2-hdmi1-disp-modes-v2-3-f4cec5e06fbe@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable USB3 OTG and it's related PHY node. And the PHY will
also be shared with the upcoming DisplayPort controller.
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20250223100757.73531-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add dt node for RK3528 clock and reset unit. Clock "gmac0_clk" is
generated by internal Ethernet phy, a fixed clock node is added as a
placeholder to avoid orphans.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Link: https://lore.kernel.org/r/20250217061142.38480-9-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add ufshc node to rk3576.dtsi, so the board using UFS could enable it.
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/1738736156-119203-8-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
RK3588 Tiger routes I2C2 signals to the Q7 Camera FFC connector (P2) but
nothing on the SoM itself is on that bus, therefore it'll be up to the
adapter connected to the Q7 Camera FFC connector (P2) to enable the I2C2
controller, if need be.
Thus, disable it by default.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-9-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
PX30 Ringneck only exposes I2C3 as LVDS_BLC_CLK/DAT on Q7 golden fingers
but nothing is on that bus on the SoM itself. Therefore, let's enable
the I2C3 bus where it makes sense, in the Haikou carrierboard DTS.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-8-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The signals are exposed on Q7 golden fingers but it's not a given that
the carrierboard will have an Ethernet jack. So let's move the enabling
of the Ethernet controller to the carrierboard DTS instead.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-7-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Haikou carrierboard has an EEPROM on LVDS_BLC_CLK/DAT which are
signals that can carry either I2C or be used as HPD for eDP0/1.
Only eDP0 is routed from RK3399 Puma SoM but only exposed on Haikou
through the Video Connector, a fake PCIe connector. So to be able to use
eDP one would need to use a Device Tree overlay. Therefore, let's
default to having an EEPROM in Haikou carrierboard DTS.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-6-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
I2S0 is routed to the Q7 golden fingers and, on Haikou carrierboard, to
an I2S codec. Nothing aside from signal routing is done on the SoM,
therefore it's the duty of the carrierboard to enable I2S0 whenever an
I2S codec is present.
Such is the case of the Haikou carrierboard, therefore let's migrate the
enabling of this controller to the carrierboard DTS instead of the SoM
DTSI.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-5-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The bus is only exposed on Q7 Camera FFC connector which accepts
external adapters such as Q7 Camera Demo.
The enabling of I2C6 should therefore be done in the adapter Device Tree
Overlay and not in the SoM DTSI, so let's disable it by default.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-4-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
I2C6 is not exposed on Q7 golden fingers which is for routing signals to
the carrierboard but on Q7 Camera connector, for routing signals to an
additional adapter (e.g. Q7 Camera Demo adapter).
Therefore, let's move the modification of I2C6 bus to Puma DTSI.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-3-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The DDC bus is necessarily on I2C3, that's how it's exposed by RK3399
Puma on the Q7 golden fingers, so let's move it to the SoM DTSI instead.
If the carrierboard doesn't route it for some reason, /delete-property/
can be used to remove it.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-2-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In its default configuration (SW2 on "UART1"), UART5 is exposed on the
DB9 RS232/RS485 connector. While the same signals are also exposed on
Q7_GPIO5 and Q7_GPIO6, a GPIO header, and thus could be used for other
purposes, RK3399 Puma Haikou and PX30 Ringneck Haikou do enable the UART
controller exposed on the DB9 connector, so let's keep consistency
across our modules and enable it on RK3588 Tiger Haikou by default too.
Add a comment while at it to explicit where this controller is routed
to.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250218-tsd-align-haikou-v1-1-5c44d1dd8658@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Radxa ROCK 4D board is based on the Rockchip rk3576 SoC.
The device tree adds support for basic devices:
- UART
- SD Card
- Ethernet
- USB
- RTC
It has 4 USB ports but only 3 are usable as the top left one is used
for maskrom.
It has a USB-C port that is only used for powering the board.
Signed-off-by: Stephen Chen <stephen@radxa.com>
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20250218160714.140709-3-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This adds the otp node to the rk3576 soc devicetree including the
individual fields we know about.
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250210224510.1194963-7-heiko@sntech.de
This adds support for the video-demo-adapter DEVKIT ADDON CAM-TS-A01
(https://embedded.cherry.de/product/development-kit/) for the Haikou
devkit with RK3399 Puma SoM.
The Video Demo adapter is an adapter connected to the fake PCIe slot
labeled "Video Connector" on the Haikou devkit.
Its main feature is a Leadtek DSI-display with touchscreen and a camera
(that is not supported yet because the expected clock rate by the driver
cannot be exactly reached by the clock driver). To drive these
components a number of additional regulators are grouped on the adapter
as well as a PCA9670 gpio-expander to provide the needed additional
gpio-lines.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250221-ringneck-dtbos-v2-5-310c0b9a3909@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This adds support for the video-demo-adapter DEVKIT ADDON CAM-TS-A01
(https://embedded.cherry.de/product/development-kit/) for the Haikou
devkit with PX30 Ringneck SoM.
The Video Demo adapter is an adapter connected to the fake PCIe slot
labeled "Video Connector" on the Haikou devkit.
Itss main feature is a Leadtek DSI-display with touchscreen and a camera
(that is not supported yet because the expected clock rate by the driver
cannot be exactly reached by the clock driver). To drive these
components a number of additional regulators are grouped on the adapter
as well as a PCA9670 gpio-expander to provide the needed additional
gpio-lines.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250221-ringneck-dtbos-v2-4-310c0b9a3909@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The HAIKOU-LVDS-9904379 adapter is an adapter for PX30 Ringneck with the
Haikou carrierboard. It is to be inserted in the fake PCIe slot labelled
Video Connector.
This adapter expects an Admatec 9904379 1024x600 LVDS display with
backlight and touchscreen. An EEPROM is also found on the adapter.
This adds support for this adapter on PX30 Ringneck when inserted in
Haikou carrierboard.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250221-ringneck-dtbos-v2-3-310c0b9a3909@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Rockchip 356x device-tree now supports GIC ITS. Move PCIe controller's
MSI to use ITS instead of MBI. This removes extra CPU overhead of handling
PCIe MBIs by letting GIC's ITS to serve the PCIe MSIs.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250216221634.364158-4-dmitry.osipenko@collabora.com
Rockchip 356x SoC's GIC has two hardware integration issues that
affect MSI functionality of the GIC. Previously, both these GIC
issues were worked around by using MBI for MSI instead of ITS
because kernel GIC driver didn't have necessary quirks.
First issue is about RK356x GIC not supporting programmable
shareability, while reporting it as supported in a GIC's feature
register. Rockchip assigned Erratum ID #3568001 for this issue. This
patch adds dma-noncoherent property to the GIC node, denoting that a SW
workaround is required for mitigating the issue.
Second issue is about GIC AXI master interface addressing limited to
the first 4GB of physical address space. Rockchip assigned Erratum
ID #3568002 for this issue.
Now that kernel supports quirks for both of the erratums, add
MSI controller node to RK356x device-tree.
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/20250216221634.364158-3-dmitry.osipenko@collabora.com
The sdhci controller supports cqe it seems and necessary code also is in
place - in theory.
At this point Jaguar and Tiger are the only boards enabling cqe support
on the rk3588 and we are seeing reliability issues under load.
This can be caused by either a controller-, hw- or driver-issue and
definitly needs more investigation to work properly it seems.
So disable cqe support on Tiger for now.
Fixes: 6173ef24b3 ("arm64: dts: rockchip: add RK3588-Q7 (Tiger) SoM")
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250219093303.2320517-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The sdhci controller supports cqe it seems and necessary code also is in
place - in theory.
At this point Jaguar and Tiger are the only boards enabling cqe support
on the rk3588 and we are seeing reliability issues under load.
This can be caused by either a controller-, hw- or driver-issue and
definitly needs more investigation to work properly it seems.
So disable cqe support on Jaguar for now.
Fixes: d1b8b36a2c ("arm64: dts: rockchip: add Theobroma Jaguar SBC")
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250219093303.2320517-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the RK3588's standalone hardware random number generator node to its
device tree, and enable it.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250204-rk3588-trng-submission-v2-6-608172b6fd91@collabora.com
[changed reset-id to its numeric value while the constant makes its
way through the crypto tree]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As the name implies, it is built around the RK3576 SoC with 4x Cortex-A72
cores, four Cortex-A53 cores and Mali-G52 MC3 GPU.
Storage options are EMMC, SD-Card, a 2242 M.2 slot and the possibility to
use UFS 2.0 storage.
Video Output options are a HDMI port, a DSI connector as well as Display-
Port via the TypeC connector (all of them not yet supported).
Networking options are a Low-profile Gigabit Ethernet RJ45 port with
Motorcomm YT8531 PHY as well as WiFi via an AMPAK AP6256 module.
USB ports on the board are 1x USB 3.0 port, 1x USB 2.0 port, 1x USB Type-C
and it comes with 40-pin GPIO header
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250210205126.1173631-3-heiko@sntech.de
The Pre-ICT tester adapter connects to RK3588 Jaguar SBC through its
proprietary Mezzanine connector.
It exposes a PCIe Gen2 1x M.2 connector and two proprietary camera
connectors. Support for the latter will come once the rest of the camera
stack is supported.
Additionally, the adapter loops some GPIOs together as well as route
some GPIOs to power rails.
This adapter is used for manufacturing RK3588 Jaguar to be able to test
the Mezzanine connector is properly soldered.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org> # Makefile
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250211-pre-ict-jaguar-v6-4-4484b0f88cfc@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to commit 4065853475 ("arm64: dts: rockchip: Add rock5b
overlays for PCIe endpoint mode"), Rock 5B can operate in PCIe endpoint
mode. For that to work, the rk3588-rock-5b-pcie-ep.dtbo overlay needs to
be applied on Rock 5B base Device Tree. If that Rock 5B is connected to
another Rock 5B, the latter needs to apply the
rk3588-rock-5b-pcie-srns.dtbo overlay.
In order to make sure the overlays are still valid in the future, let's
add a validation test by applying the overlays on top of the main base
at build time.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250211-pre-ict-jaguar-v6-3-4484b0f88cfc@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Edgeble NCM6A/NCM6B can have WiFi modules connected and this is
handled via an overlay (commit 951d6aaa37 ("arm64: dts: rockchip: Add
Edgeble NCM6A WiFi6 Overlay")).
Despite the name of the overlay, it applies to both NCM6A and NCM6B[1].
In order to make sure the overlay is still valid in the future, let's
add a validation test by applying the overlay on top of the main bases
at build time.
[1] https://lore.kernel.org/linux-rockchip/CA+VMnFyom=2BmJ_nt-At6hTQP0v+Auaw-DkCVbT9mjndMmLKtQ@mail.gmail.com/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Jagan Teki <jagan@edgeble.ai>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250211-pre-ict-jaguar-v6-2-4484b0f88cfc@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The WolfVision PF5 can have a PF5 Visualizer display and PF5 IO Expander
board connected to it. Therefore, let's generate an overlay test so the
application of the two overlays are validated against the base DTB.
Suggested-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250211-pre-ict-jaguar-v6-1-4484b0f88cfc@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Going over the 80-column width limit, and using all 100 columns, is intended
for improving code readability. This wasn't the case in a few places in the
Quartz64 Model A/B board dts files, so let's reflow them a bit, to both obey
the 80-column limit and make them a bit more readable.
No intended functional changes are introduced by these changes.
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/7eea4ebdb19d5f43d24074a166e6c46bb5424d46.1739218324.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Remove Optee node from rk3588 devicetree. When Optee is present and
used the node will be added automatically by U-Boot when
CONFIG_OPTEE_LIB=y and CONFIG_SPL_ATF_NO_PLATFORM_PARAM is not set.
When Optee is not present or used, the node will trigger a probe
that generates a (harmless) message on the kernel log.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20250130181005.6319-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The SMMU architecture requires wired interrupts to be edge triggered,
which does not align with the DT description for the RK3588. This leads
to interrupt storms, as the SMMU continues to hold the pin high and only
pulls it down for a short amount when issuing an IRQ. Update the DT
description to be in line with the spec and perceived reality.
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Fixes: cd81d3a069 ("arm64: dts: rockchip: add rk3588 pcie and php IOMMUs")
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/Z6pxme2Chmf3d3uK@windev.fritz.box
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit da92d3dfc8 ("arm64: dts: rockchip: enable the mmu600_pcie IOMMU
on the rk3588 SoC") enabled the mmu600_pcie IOMMU, both in the normal case
(when all PCIe controllers are running in Root Complex mode) and in the
case when running the pcie3x4 PCIe controller in Endpoint mode.
There have been no issues detected when running the PCIe controllers in
Root Complex mode. During PCI probe time, we will add a SID to the IOMMU
for each PCI device enumerated on the bus, including the root port itself.
However, when running the pcie3x4 PCIe controller in Endpoint mode, we
will only add a single SID to the IOMMU (the SID specified in the iommus
DT property).
The enablement of IOMMU in endpoint mode was verified on setup with two
Rock 5b:s, where the BDF of the Root Complex has BDF (00:00.0).
A Root Complex sending a TLP to the Endpoint will have Requester ID set
to the BDF of the initiator. On the EP side, the Requester ID will then
be used as the SID. This works fine if the Root Complex has a BDF that
matches the iommus DT property, however, if the Root Complex has any other
BDF, we will see something like:
arm-smmu-v3 fc900000.iommu: event: C_BAD_STREAMID client: (unassigned sid) sid: 0x1600 ssid: 0x0
on the endpoint side.
For PCIe controllers running in endpoint mode that always uses the
incoming Requester ID as the SID, the iommus DT property simply isn't
a viable solution. (Neither is iommu-map a viable solution, as there is
no enumeration done on the endpoint side.)
Thus, partly revert commit da92d3dfc8 ("arm64: dts: rockchip: enable the
mmu600_pcie IOMMU on the rk3588 SoC") by disabling the PCI IOMMU when
running the pcie3x4 PCIe controller in Endpoint mode.
Since the PCI IOMMU is working as expected in the normal case, keep it
enabled when running all PCIe controllers in Root Complex mode.
Fixes: da92d3dfc8 ("arm64: dts: rockchip: enable the mmu600_pcie IOMMU on the rk3588 SoC")
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/20250207143900.2047949-2-cassel@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Edgeble-6TOPS modules configure HDMI1 for HDMI Out from RK3588.
Enable it on Edgeble-6TOPS IO Board dtsi.
Cc: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Link: https://lore.kernel.org/r/20241227132936.168100-1-jagan@edgeble.ai
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT changes to enable the second HDMI output port on
Radxa ROCK 5B.
While at it, switch the position of &vop_mmu and @vop to maintain the
alphabetical order.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Link: https://lore.kernel.org/r/20241211-rk3588-hdmi1-v2-4-02cdca22ff68@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for the second HDMI TX port found on RK3588 SoC.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Jagan Teki <jagan@edgeble.ai> # edgeble-6tops-modules
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Link: https://lore.kernel.org/r/20241211-rk3588-hdmi1-v2-3-02cdca22ff68@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In preparation to enable the second HDMI output port found on RK3588
SoC, add the related PHY node. This requires a GRF, hence add the
dependent node as well.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: Jagan Teki <jagan@edgeble.ai> # edgeble-6tops-modules
Tested-by: Alexandre ARNOUD <aarnoud@me.com>
Link: https://lore.kernel.org/r/20241211-rk3588-hdmi1-v2-2-02cdca22ff68@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
H96 Max V58 has its spdif_tx0 controller wired to a dedicated optical
Toslink SPDIF socket, enable it in the device tree
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20250120-rk3588-spdif-v1-3-1415f5871dc7@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add dts for Ariaboard Photonicat RK3568.
Partially based on downstream board dts. [1]
Working IO:
Debug UART
SDIO QCA9377 WiFi and Bluetooth
M.2 E-Key PCIe WiFi and Bluetooth
M.2 B-Key USB Modem WWAN
Ethernet WAN Port
MicroSD Card slot
eMMC
HDMI Output
Mali GPU
USB Type-A
Not working IO:
Ethernet LAN Port (Lack of SGMII support)
Power management MCU on UART4 (Driver pending)
Not working IO in MCU:
Battery voltage sensor
Board temperature sensor
Hardware Power-off
Hardware Watchdog
Network status LED
Real-time clock
USB Charger voltage sensor
About onboard power management MCU:
A heartbeat must be sent to the MCU within 60 seconds,
otherwise the MCU will restart the system.
When powering off, a shutdown command needs to be sent to the MCU.
When the power button is long pressed, the MCU will send a shutdown
command to the system. If system does not shutdown within 60 seconds,
the power will be turned off directly.
MCU only provides voltage for charger and battery.
Manufacturer removed RK8xx PMIC.
[1] https://github.com/photonicat/rockchip_rk3568_kernel/blob/novotech-5.10/arch/arm64/boot/dts/rockchip/rk3568-photonicat-base.dtsi
Signed-off-by: Junhao Xie <bigfoot@classfun.cn>
Link: https://lore.kernel.org/r/20250114001411.1848529-4-bigfoot@classfun.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa Rock 5C supports both CRU-based (default) and PMIC-based reset
upon thermal runaway conditions. The former resets the SoC by internally
poking the CRU from TSADC, while the latter power-cycles the whole board
by pulling the PMIC reset line low in case of uncontrolled overheating.
Switch to a PMIC-based reset, as the more 'thorough' of the two.
Tested by temporarily setting rockchip,hw-tshut-temp to 65C to simulate
overheating - this causes the board to reset when any of the on-chip
temperature sensors surpasses the tshut temperature.
Requires Alexander's patch [1] fixing TSADC pinctrl assignment
[1] https://lore.kernel.org/r/20250130053849.4902-1-eagle.alexander923@gmail.com
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250204-rock-5c-tshut-v1-1-33301e4eef64@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the recommended chassis-type root node property so userspace can
request the form factor and adjust their behavior accordingly.
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250207111157.297276-1-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The hdptxphy is a combo transmit-PHY for HDMI2.1 TMDS Link, FRL Link, DP
and eDP Link. Therefore, it is better to name it hdptxphy0 other than
hdptxphy_hdmi0, which will be referenced by both hdmi0 and edp0 nodes.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://lore.kernel.org/r/20250206030330.680424-3-damon.ding@rock-chips.com
[added armsom-sige7, where hdmi-support was added recently and also
the hdptxphy0-as-dclk source I just added]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
VOP2 on RK3588 is able to use the HDMI PHY PLL as an alternative and
more accurate pixel clock source to improve handling of display modes up
to 4K@60Hz on video ports 0, 1 and 2.
For now only HDMI0 output is supported, hence add the related PLL clock.
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20250204-vop2-hdmi0-disp-modes-v3-5-d71c6a196e58@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Since commit c4b09c5620 ("phy: phy-rockchip-samsung-hdptx: Add clock
provider support"), the HDMI PHY PLL can be used as an alternative and
more accurate pixel clock source for VOP2 to improve display modes
handling on RK3588 SoC.
Add the missing #clock-cells property to allow using the clock provider
functionality of HDMI0 PHY.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-by: FUKAUMI Naoki <naoki@radxa.com>
Link: https://lore.kernel.org/r/20250204-vop2-hdmi0-disp-modes-v3-4-d71c6a196e58@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to the schematic, the lcdpwr_en pin is GPIO0_C4,
not GPIO1_C4.
Fixes: 4a8c1161b8 ("arm64: dts: rockchip: Add support for rk3588 based Cool Pi CM5 GenBook")
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20250113104825.2390427-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
rk3399-gru chromebooks have a regulator chains where one named regulator
supplies multiple regulators pp900-usb pp900_pcie that supply
the named peripherals.
The dtsi used somewhat creative structure to describe that in creating
the base node 3 times with different phandles and describing the EC
dependency in a comment.
This didn't register in the recent regulator-node renaming, as the
additional nodes were empty, so adapt the missing node names for now.
Fixes: 5c96e63301 ("arm64: dts: rockchip: adapt regulator nodenames to preferred form")
Tested-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250116143631.3650469-1-heiko@sntech.de
UART controllers without flow control seem to behave unstable
in case DMA is enabled. The issues were indicated in the message:
https://lore.kernel.org/linux-arm-kernel/CAMdYzYpXtMocCtCpZLU_xuWmOp2Ja_v0Aj0e6YFNRA-yV7u14g@mail.gmail.com/
In case of PX30-uQ7 Ringneck SoM, it was noticed that after couple
of hours of UART communication, the CPU stall was occurring,
leading to the system becoming unresponsive.
After disabling the DMA, extensive UART communication tests for
up to two weeks were performed, and no issues were further
observed.
The flow control pins for uart5 are not available on PX30-uQ7
Ringneck, as configured by pinctrl-0, so the DMA nodes were
removed on SoM dtsi.
Cc: stable@vger.kernel.org
Fixes: c484cf93f6 ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Link: https://lore.kernel.org/r/20250121125604.3115235-3-lukasz.czechowski@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In the PX30-uQ7 (Ringneck) SoM, the hardware CTS and RTS pins for
uart5 cannot be used for the UART CTS/RTS, because they are already
allocated for different purposes. CTS pin is routed to SUS_S3#
signal, while RTS pin is used internally and is not available on
Q7 connector. Move definition of the pinctrl-0 property from
px30-ringneck-haikou.dts to px30-ringneck.dtsi.
This commit is a dependency to next commit in the patch series,
that disables DMA for uart5.
Cc: stable@vger.kernel.org
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Link: https://lore.kernel.org/r/20250121125604.3115235-2-lukasz.czechowski@thaumatec.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In general the delay should be added by the PHY instead of the MAC,
and this improves network stability on some boards which seem to
need different delay.
Fixes: 387b3bbac5 ("arm64: dts: rockchip: Add Xunlong OrangePi R1 Plus LTS")
Cc: stable@vger.kernel.org # 6.6+
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20250119091154.1110762-1-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The tsadc driver does not handle pinctrl "gpio" and "otpout".
Let's use the correct pinctrl names "default" and "sleep".
Additionally, Alexey Charkov's testing [1] has established that
it is necessary for pinctrl state to reference the &tsadc_shut_org
configuration rather than &tsadc_shut for the driver to function correctly.
[1] https://lkml.org/lkml/2025/1/24/966
Fixes: 32641b8ab1 ("arm64: dts: rockchip: add rk3588 thermal sensor")
Cc: stable@vger.kernel.org
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Link: https://lore.kernel.org/r/20250130053849.4902-1-eagle.alexander923@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The preferred way to denote hardware with non-coherent DMA is to use the
"dma-noncoherent" DT property, at both the GIC redistributor and the GIC ITS
levels, [1] instead of relying on the compatibles to handle hardware errata,
in this case the Rockchip 3588001 errata. [2]
Let's have the preferred way employed in the base Rockchip RK3588 SoC dtsi,
which also goes along with adding initial support for the Rockchip RK3582 SoC
variant, with its separate compatible. [2][3]
[1] Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
[2] https://lore.kernel.org/linux-rockchip/86msgoozqa.wl-maz@kernel.org/
[3] https://lore.kernel.org/linux-rockchip/20241222030355.2246-4-naoki@radxa.com/
Cc: Marc Zyngier <maz@kernel.org>
Cc: FUKAUMI Naoki <naoki@radxa.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/fa1a672dae3644bb3caa58f03216d0ca349db88b.1736279094.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary cooling map to enable the kernel's thermal subsystem
to manage the fan speed automatically depending on the overall SoC
package temperature on Radxa Rock 5C
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250120-rock-5c-fan-v1-2-5fb8446c981b@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa Heatsink 6540B, which is the official cooling accessory for the
Rock 5C board, includes a small 5V fan, which in my testing spins up
reliably at a PWM setting of 24 (out of 255). It is also quite loud
at the current minimum setting of 64, and noticeably less so at 24.
Introduce two intermediate PWM states at the lower end of the fan's
operating range to enable better balance between noise and cooling.
Note further that, in my testing, having the fan run at 44 is enough
to keep the system from thermal throttling with sustained 100% load
on its 8 CPU cores (in 22C ambient temperature and no case)
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Acked-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250120-rock-5c-fan-v1-1-5fb8446c981b@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
We see the addition of eleven new SoCs, including a total of sixx arm64
chips from Qualcomm alone. Overall, the Qualcomm platforms once again
make up the majority of all changes, after a couple of quieter releases.
The new SoCs in this branch are:
- Microchip sama7d65 is a new 32-bit embedded chip with a single
Cortex-A7 and the current high end of the old Atmel SoC line.
- Samsung Exynos 9810 is a mobile phone chip used in some older
phones like the Samsung Galaxy S9
- Renesas R-Car V4H ES3.0 (R8A779G3) is an updated version of
the V4H (R8A779G0) low-power automotive SoC
- Renesas RZ/G3E (R0A09G047) is a family of embedded chips
using Cortex-A55 cores
- Qualcomm Snapdragon 8 Elite (SM8750) is a new phone chip based on
Qualcomm's Oryon CPU cores.
- Qualcomm Snapdragon AR2 (SAR2130P) is a SoC for augmented reality
glasses.
- Qualcomm IQ6 (QCS610) and IQ8 (QCS8300) are two industrial
IOT platforms.
- Snapdragon 425 (MSM8917) is a mobile phone SoC from 2016
- Qualcomm IPQ5424 is a Wi-Fi 7 networking chip
All of the above are part of already supported SoC families that
only need new devicetree files. Two additional SoCs in new
families are part of a separate branch.
There are 48 new machines in total, including six arm32 ones based
on aspeed. broadcom, microchip and st SoCs all using Cortex-A7 cores,
and a single risc-v board, the Banana Pi R3.
The remaining ones use arm64 chips from Broadcom, Samsung, NXP, Mediatek,
Qualcomm, Renesas and Rockchips and cover development boards, phones,
laptops, industrial machines routers.
A lot of ongoing work is for cleaning up build time warnings and other
issues, in addition to the new machines and added features.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeSdLQACgkQYKtH/8kJ
UicovRAA0fABVQ8Fl45/NNaBGfXYagXptCSTGOFsdKJ49LVF4uLfWtL+0ENx5Ck5
PJjr0n9kMNWqeJDiaaQtW21HhYxGxcz3MJEj60/C+D0QNQExPVROUHNy1aggxjNI
qHf0DnTLAWzjtD0YdCmiI6JCDRdPIRQi2IJymAu7tlooc809PG15bbo6PpIYginC
1U6cYtuyBuE/9ku2FgWX6E4T0aRjPyaR8thg9VAIsKsugdH3v9EdtLC/MUqOBHMt
30PyghR9+r1LxQzOC/q7TFcPmnUb74fSPW85X7a5KXv53K6MeRXtRhnetts08R7Z
iZCJi2ORO100RX7plAzxtF+CWI8eO3bVzibTcZmgxP/Is6CmrlnTcPzOFvqfyx1E
AfeyEGA7XofjFwPJcc9bCQc3r2w90FpsKqtlaBAn2Od+1EUuuAAgUcjrNyNJqlkp
8Vos0FxNOOnYULjndYZqa6MslBuxNXYtNj0Ph1/fpzUWKwo+x8LWy8Xb9a5Sdz0H
OsPVWbumrXlG1rcNMFu8yPzKOBgO0t8on5MRwW+1Xmf1lcQNzJWeGqTzsFPObREV
Ar7evGEgSb8qladOtzbg645wIezWIXpSJUICQhilxV8DUO+IYuMz668QoZZP40V5
uHdWxFGdNe1cm5JAsjjwCeFNk/Pbro1+ojc4E6//MRp+WCgdPQ0=
=vdmR
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC devicetree updates from Arnd Bergmann:
"We see the addition of eleven new SoCs, including a total of sixx
arm64 chips from Qualcomm alone. Overall, the Qualcomm platforms once
again make up the majority of all changes, after a couple of quieter
releases.
The new SoCs in this branch are:
- Microchip sama7d65 is a new 32-bit embedded chip with a single
Cortex-A7 and the current high end of the old Atmel SoC line.
- Samsung Exynos 9810 is a mobile phone chip used in some older
phones like the Samsung Galaxy S9
- Renesas R-Car V4H ES3.0 (R8A779G3) is an updated version of the V4H
(R8A779G0) low-power automotive SoC
- Renesas RZ/G3E (R0A09G047) is a family of embedded chips using
Cortex-A55 cores
- Qualcomm Snapdragon 8 Elite (SM8750) is a new phone chip based on
Qualcomm's Oryon CPU cores.
- Qualcomm Snapdragon AR2 (SAR2130P) is a SoC for augmented reality
glasses.
- Qualcomm IQ6 (QCS610) and IQ8 (QCS8300) are two industrial IOT
platforms.
- Snapdragon 425 (MSM8917) is a mobile phone SoC from 2016
- Qualcomm IPQ5424 is a Wi-Fi 7 networking chip
All of the above are part of already supported SoC families that only
need new devicetree files. Two additional SoCs in new families are
part of a separate branch.
There are 48 new machines in total, including six arm32 ones based on
aspeed. broadcom, microchip and st SoCs all using Cortex-A7 cores, and
a single risc-v board, the Banana Pi R3.
The remaining ones use arm64 chips from Broadcom, Samsung, NXP,
Mediatek, Qualcomm, Renesas and Rockchips and cover development
boards, phones, laptops, industrial machines routers.
A lot of ongoing work is for cleaning up build time warnings and other
issues, in addition to the new machines and added features"
* tag 'soc-dt-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (619 commits)
arm64: tegra: Fix Tegra234 PCIe interrupt-map
arm64: dts: qcom: x1e80100-romulus: Update firmware nodes
arm64: dts: rockchip: add DTs for Firefly ITX-3588J and its Core-3588J SoM
dt-bindings: arm: rockchip: Add Firefly ITX-3588J board
arm64: dts: rockchip: Add Orange Pi 5 Max board
dt-bindings: arm: rockchip: Add Xunlong Orange Pi 5 Max
arm64: dts: rockchip: refactor common rk3588-orangepi-5.dtsi
arm64: dts: rockchip: add WLAN to rk3588-evb1 controller
arm64: dts: rockchip: increase gmac rx_delay on rk3399-puma
arm64: dts: rockchip: Delete redundant RK3328 GMAC stability fixes
arm64: tegra: Disable Tegra234 sce-fabric node
arm64: tegra: Fix typo in Tegra234 dce-fabric compatible
arm64: tegra: Fix DMA ID for SPI2
arm64: dts: qcom: msm8916-samsung-serranove: Add display panel
arm64: dts: qcom: sm8650: Add 'global' interrupt to the PCIe RC nodes
arm64: dts: qcom: sm8550: Add 'global' interrupt to the PCIe RC nodes
arm64: dts: qcom: Remove unused and undocumented properties
arm64: dts: qcom: sdm450-lenovo-tbx605f: add DSI panel nodes
arm64: dts: qcom: pmi8950: add LAB-IBB nodes
arm64: dts: qcom: ipq5424: enable the download mode support
...
The RK3588 Single Board Computer includes
- eMMC
- microSD
- UART
- 2 PWM LEDs
- RTC
- RTL8125 network controller on PCIe 2.0x1.
- M.2 M-key connector routed to PCIe 3.0x4
- PWM controlled heat sink fan.
- 2 USB2 ports
- lower USB3 port
- upper USB3 port with OTG capability
- Mali GPU
- SPI NOR flash
- Mask Rom button
- Analog audio using es8388 codec via the headset jack and onboard mic
- HDMI0
- HDMI1
the vcc5v0_usb30 regulator shares the same enable gpio pin as the
vcc5v0_usb20 regulator.
The Orange Pi 5 Max and Orange Pi 5 Ultra are both credit-card sized
boards with similar layout, so these boards will share a common dtsi.
The 5 Max has an extra HDMI0 while the 5 Ultra has a HDMI IN instead.
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250109051619.1825-4-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Orange Pi now has multiple SBCs using the RK3588.
Refactor the common parts of the Orange Pi 5 Plus DTS so it can be
shared with the 5 Max and the 5 Ultra.
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250109051619.1825-2-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 EVB1 has an onboard AP6275P WLAN/BT module. This adds
support for the WLAN side, which is connected to the second
PCIe bus. The Bluetooth side is connected to UART and handled
separately.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20241210162452.116767-1-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
During mass manufacturing, we noticed the mmc_rx_crc_error counter,
as reported by "ethtool -S eth0 | grep mmc_rx_crc_error", to increase
above zero during nuttcp speedtests. Most of the time, this did not
affect the achieved speed, but it prompted this investigation.
Cycling through the rx_delay range on six boards (see table below) of
various ages shows that there is a large good region from 0x12 to 0x35
where we see zero crc errors on all tested boards.
The old rx_delay value (0x10) seems to have always been on the edge for
the KSZ9031RNX that is usually placed on Puma.
Choose "rx_delay = 0x23" to put us smack in the middle of the good
region. This works fine as well with the KSZ9131RNX PHY that was used
for a small number of boards during the COVID chip shortages.
Board S/N PHY rx_delay good region
--------- --- --------------------
Puma TT0069903 KSZ9031RNX 0x11 0x35
Puma TT0157733 KSZ9031RNX 0x11 0x35
Puma TT0681551 KSZ9031RNX 0x12 0x37
Puma TT0681156 KSZ9031RNX 0x10 0x38
Puma 17496030079 KSZ9031RNX 0x10 0x37 (Puma v1.2 from 2017)
Puma TT0681720 KSZ9131RNX 0x02 0x39 (alternative PHY used in very few boards)
Intersection of good regions = 0x12 0x35
Middle of good region = 0x23
Fixes: 2c66fc34e9 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM")
Cc: stable@vger.kernel.org
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # Puma v2.1 and v2.3 with KSZ9031
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Link: https://lore.kernel.org/r/20241213-puma_rx_delay-v4-1-8e8e11cc6ed7@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3568 PDM block always considers stereo inputs. Therefore,
the number of channels must be always an even number, even if a single
mono microphone is attached.
Fixes: 0be29f7663 ("arm64: dts: rockchip: add wolfvision pf5 mainboard")
Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net>
Link: https://lore.kernel.org/r/20241218-b4-wolfvision-pf5-update-v1-1-1d1959858708@wolfvision.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board features a Fujitsu MB85RS128TY FRAM chip connected to spi0 CS
0. Add support for the MB85RS128TY to the device tree.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
Link: https://lore.kernel.org/r/20241219-mb85rs128ty-mecsbc-v1-2-77a0e851ef19@pengutronix.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
One of the pins of i2c2 is actually in use as chip select 0 for spi0.
The chip select 0 is used for an FRAM chip, which will be added in the
next patch.
Remove the i2c2 node from the rk3568-mecsbc device tree.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Jonas Rebmann <jre@pengutronix.de>
Link: https://lore.kernel.org/r/20241219-mb85rs128ty-mecsbc-v1-1-77a0e851ef19@pengutronix.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Edgeble 6TOPS modules has configured the PCIe3.0 with
- 2 lanes on Port1 of pcie3x2 controller for M.2 M-Key
- 2 lanes on Port0 of pcie3x4 controller for B and E-Key
The, current DT uses opposite controller nodes that indeed uses
incorrect reset, regulator nodes.
The configuration also uses refclk oscillator that need to enable
explicitly in DT to avoid the probe hang on while reading DBI.
So, this patch fixes all these essential issues and make this PCIe work
properly.
Issues fixed are,
- Fix the associate controller nodes for M and B, E-Key
- Fix the reset gpio handlings
- Fix the regulator handlings and naming convensions
- Support pcie_refclk oscillator
Fixes: 92eaee21ab ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 B-Key, E-Key")
Fixes: 5d85d4c7e0 ("arm64: dts: rockchip: Add Edgeble NCM6A-IO M.2 M-Key")
Reported-by: Mitchell Ma <machuang@radxa.com>
Co-developed-by: Mitchell Ma <machuang@radxa.com>
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Link: https://lore.kernel.org/r/20241221151758.345257-1-jagan@edgeble.ai
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E52C[1] is a compact network computer based on the Rockchip
RK3582 SoC:
- Dual Cortex-A76 and quad Cortex-A55 CPU
- 5TOPS NPU
- 2GB/4GB/8GB LPDDR4 RAM
- 16GB/32GB/64GB on-board eMMC
- microSD card slot
- USB 3.0 Type-A HOST port
- USB Type-C debug port
- USB Type-C power port (5V only)
- 2x 2.5GbE ports
[1] https://radxa.com/products/network-computer/e52c
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Link: https://lore.kernel.org/r/20241226024630.13702-3-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
BigTreeTech CB2 and Pi2 share a lot of hardware configuration, so a
common dtsi file was used to define common nodes and properties. This is
similar to how BigTreeTech CB1 and Pi are implemented.
Signed-off-by: Ivan Sergeev <ivan8215145640@gmail.com>
Link: https://lore.kernel.org/r/20250106-bigtreetech-cb2-v7-2-565567e2c0a4@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Orange Pi 5 Plus has its first USB 3.0 interface on the SoC wired
directly to the USB type C port next to the MASKROM button, and the
second interface wired to a USB 3.0 hub which in turn is connected to
the USB 3.0 host ports on the board, as well as the USB 2.0 connection
on the M.2 E-key slot.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20241220161240.109253-1-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
H96 Max V58 is a compact Rockchip RK3588 based device that ships
with Android and is meant for use as a TV connected media box.
Its hardware includes:
- Rockchip RK3588 SoC with a small aluminium heatsink
- 4GB or 8GB LPDDR4 RAM
- 32GB or 64GB eMMC 5.1 storage (HS400)
- Onboard AP6275P wireless module providing 802.11ax 2x2 MIMO WiFi
over PCIe connection and Bluetooth 5.3 over UART with two external
detachable antennas
- 1x GbE using the onboard GMAC and an RTL8211F PHY
- 1x USB 2.0 Type-A (also serves as the Maskrom port)
- 1x USB 3.0 Type-A
- 1x HDMI 2.1 output
- 1x optical SPDIF output
- LED line display ("88:88" digits plus icons) driven by an FD6551
IC connected over bitbanged I2C (not yet enabled here)
- GPIO connected CIR receiver
- Single Rockchip RK806-1 PMIC
- 12x onboard ambient LEDs lighting up the bottom of the device
- 5v DCIN using a standard round 5.5mm connector
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20250108-rk3588-h96-max-v58-v2-3-522301b905d6@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
rk3576 has two naneng combo phys:
- combophy0 is used for one of pcie and sata;
- combophy1 is used for one of pcie, sata and usb3;
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Link: https://lore.kernel.org/r/20250107074911.550057-2-kever.yang@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The automatically generated names for the LEDs from color and function
do not match nicely for the 4 hdds, so set them manually per the label
property to also match the LEDs generated from the MCU.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241107114712.538976-10-heiko@sntech.de
The MCU is an important part of the device functionality. It provides
functionality like fan-control, more leds, etc and even more important
without it, the NAS-device cannot even fully turned off.
Hook up the serial device to its uart and hook into the thermal
management to control the fan according to the cpu temperature.
While the MCU also provides a temperature sensor for the case, this one
is just polled and does not provide functionality for handling trip
points in hardware, so a lot of polling would be involved.
As the cpu is only cooled passively in these devices, it's temperature
rising will indicate the temperature level of the system just earlier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241107114712.538976-9-heiko@sntech.de
BootROM leave GPIO4_D6 configured as SDMMC_PWREN function and DW MCI
driver set PRWEN high on MMC_POWER_UP and low on MMC_POWER_OFF.
Similarly U-Boot also set PRWEN high before accessing mmc.
However, HW revision prior to v1.2 must pull GPIO4_D6 low to access
sdmmc. For HW revision v1.2 the state of GPIO4_D6 has no impact.
Model an always-on active low fixed regulator using GPIO4_D6 to fix
use of sdmmc on older HW revisions of the board.
Fixes: adeb5d2a4b ("arm64: dts: rockchip: Add Radxa ROCK S0")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20241119230838.4137130-1-jonas@kwiboo.se
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
on ROCK 5B, there is no PCIe slot, instead there is a M.2 slot.
rfkill pin is not exclusive to PCIe devices, there is SDIO Wi-Fi
devices.
rename rfkill label from "rfkill-pcie-wlan" to "rfkill-m2-wlan", it
matches with rfkill-bt.
Fixes: 82d40b141a ("arm64: dts: rockchip: add rfkill node for M.2 Key E WiFi on rock-5b")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Fixes: 82d40b141a ("arm64: dts: rockchip: add rfkill node for M.2 Key E WiFi on rock-5b")
Link: https://lore.kernel.org/r/20241128120631.37458-1-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit cd81d3a069 ("arm64: dts: rockchip: add rk3588 pcie and php
IOMMUs") added the rk3588 SoC's pcie IOMMU and php IOMMU as disabled.
The mmu600_pcie is connected with the five PCIe controllers.
See 8.2 Block Diagram, in rk3588 TRM (Technical Reference Manual).
The five PCIe controllers are:
pcie3x4, pcie3x2, pcie2x1l0, pcie2x1l1, pcie2x1l2.
pcie3x4 can run in either Root Complex mode or Endpoint mode, the other
four PCIe controllers can only run in Root Complex mode. To describe this
we thus have six different device nodes in the device tree.
A PCIe controller in Root Complex mode needs to specify an iommu-map, such
that the device knows how to convert a Requester ID (PCI BDF) to an IOMMU
master ID (stream ID). (A PCIe controller in Endpoint mode should use the
iommus property, just like a regular device.)
If you look at the device tree bindings for msi-map and iommu-map, you can
see that the conversion from Requester ID to MSI-specifier data is the same
as the conversion from Requester ID to IOMMU specifier data. Thus it is
sensible to define the iommu-map property value similar to the msi-map,
such that the conversion will be identical.
Add the proper iommu device tree properties for these six device nodes
connected to the mmu600_pcie, so that we can enable the mmu600_pcie IOMMU.
(The mmu600_php IOMMU is not touched, so it is still disabled.)
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Link: https://lore.kernel.org/r/20241107123732.1160063-2-cassel@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This release adds the devicetree files for an impressive number of new
SoC variants, though as expected these are all related to others we
already support:
- The microchip sam9x7 devicetree is now added, after the device driver
and platform code has already made it in. This is likely the last ARMv5
(!) platform to ever get added, updating the 20+ year old at91/sam9
platform wtih DDR3 memory and gigabit ethernet.
- On the Apple platform, there are now devicetree files for a number of
A-series SoCs in addition to the M-series ones, these are used
primarily in phones and tablets, but are closely related to the
already supported chips.
- Samsung Exynos 8895 and Exynos 990 are more phone SoCs used in older
Samsung Galaxy phones.
- Qualcomm Snapdragon 778G (SM7325) is another phone SoC, closely related
to the Snapdragon 7c+ Gen 3 (SC7280) used in low-end laptops.
- Rockchip RK3528 and RK3576 are new variants of their TV box and Tablet
chips, still using the older ARMv8.0 cores from RK3328/RK3399 but
with a newer process and other improvements from the RK35xx (otherwise
ARMv8.2) chips. RK3566T and RK3399-S are also added, these are just
lower-cost versions of their normal counterparts.
- TI J742S2 is a feature-reduced version of the J784s4
industrial/automotive SoC, with fewer CPU cores.
- Sophgo SG2002 is an embedded SoC with one RISC-V (C906) and one ARM
(Cortex-A53) core, at this point support is only added for running
on the RISC-V side on the LicheeRV Nano board.
A total of 92 new .dts files describing individual machines is added,
which must be a new record. The majority of these is for the newly added
chips above, notably all the Apple phones and tablets. The other new
machines include nine industrial/embedded boards with NXP i.MX6 or i.MX8
SoCs, eight for Rockchips RK35XX and one or two each for Rockchips RV1109,
RK3308, Allwinner A33, Tegra 234, Qualcomm qcs9100/sc8280xp/x1e80100,
TI AM625 and Starfive JH7110.
As usual there are also many newlyad added features in existing boards
as well as cleanups and minor bugfixes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmc92V4ACgkQYKtH/8kJ
Uie7+xAA5BIu2fSl+cCCOLdWvNulgYJBZfgOC+1vay3A3zykTR5Hd/X4/GOetqb6
uhCJ7MER0md2PBCdffN0JDuDnvBGdOEbHghsY3iqqwP4ad+bk4+Ib/dxgM0uid3t
W2NykLvmXmjFJiwjvMKE4aSPi+lCskLehPC05IIJvM/DplGflIoq7Rf+q5WIvStT
K5kpluJBD81oQkfBn7FwVJWeM6OZ1CZg413m0PNMoojd6SzyPVNGnd004qEHfwkv
Ra1w9cHM2+zagPrkTrFp0bpxfUYwoXiP8uPq9crXrhgeq4JmQBHuTR0ek+mMC2nI
aRgi91za8YPgC8APXks64BBqXCxHVse9n228MpldMAabURez5wMkufNFfQc6yLks
AhQxD2joVFS+i/pE8WyFlS3/aopNUzIbqVyIhpYiYBLz8xQBSv7KjqySRufrBEhP
lMA548uDQK5p1TRnl8L6cDXdHTN9MbqtREIozBeO20iolHJtqLBcw4erZFhwnJsP
2QQVN9P8AXOE/U/RZcV8Wfm7kUoU4FI29G3XlmUnpBmCHQd3Ql2Xv56gaDaAtb3s
hF83uTA8bKjby9Xu0c9JQREeNsLEmI/WwuUWlSEcn1cGBZ5ahg8FMta55H8tpX8O
OizWoPviwUar7HFASA/ZvN0KoPgq/a8HWRXT+Q+/xBBqnHshtLk=
=Ha1w
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC devicetree updates from Arnd Bergmann:
"This release adds the devicetree files for an impressive number of new
SoC variants, though as expected these are all related to others we
already support:
- The microchip sam9x7 devicetree is now added, after the device
driver and platform code has already made it in. This is likely the
last ARMv5 (!) platform to ever get added, updating the 20+ year
old at91/sam9 platform with DDR3 memory and gigabit ethernet.
- On the Apple platform, there are now devicetree files for a number
of A-series SoCs in addition to the M-series ones, these are used
primarily in phones and tablets, but are closely related to the
already supported chips.
- Samsung Exynos 8895 and Exynos 990 are more phone SoCs used in
older Samsung Galaxy phones.
- Qualcomm Snapdragon 778G (SM7325) is another phone SoC, closely
related to the Snapdragon 7c+ Gen 3 (SC7280) used in low-end
laptops.
- Rockchip RK3528 and RK3576 are new variants of their TV box and
Tablet chips, still using the older ARMv8.0 cores from
RK3328/RK3399 but with a newer process and other improvements from
the RK35xx (otherwise ARMv8.2) chips. RK3566T and RK3399-S are also
added, these are just lower-cost versions of their normal
counterparts.
- TI J742S2 is a feature-reduced version of the J784s4
industrial/automotive SoC, with fewer CPU cores.
- Sophgo SG2002 is an embedded SoC with one RISC-V (C906) and one ARM
(Cortex-A53) core, at this point support is only added for running
on the RISC-V side on the LicheeRV Nano board.
A total of 92 new .dts files describing individual machines is added,
which must be a new record. The majority of these is for the newly
added chips above, notably all the Apple phones and tablets. The other
new machines include nine industrial/embedded boards with NXP i.MX6 or
i.MX8 SoCs, eight for Rockchips RK35XX and one or two each for
Rockchips RV1109, RK3308, Allwinner A33, Tegra 234, Qualcomm
qcs9100/sc8280xp/x1e80100, TI AM625 and Starfive JH7110.
As usual there are also many newly added features in existing boards
as well as cleanups and minor bugfixes"
* tag 'soc-dt-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (718 commits)
arm64: dts: apm: Remove unused and undocumented "bus_num" property
arm: dts: spear13xx: Remove unused and undocumented "pl022,slave-tx-disable" property
arm64: dts: amd: Remove unused and undocumented "amd,zlib-support" property
arm64: dts: lg131x: Update spi clock properties
arm64: dts: seattle: Update spi clock properties
arm64: dts: rockchip: use less broad pinctrl for pcie3x1 on Radxa E25
arm64: dts: rockchip: add Radxa ROCK 5C
dt-bindings: arm: rockchip: add Radxa ROCK 5C
arm64: dts: rockchip: orangepi-5-plus: Enable GPU
arm64: dts: rockchip: enable USB3 on NanoPC-T6
arm64: dts: rockchip: adapt regulator nodenames to preferred form
arm64: dts: rockchip: Enable HDMI display for rk3588 Cool Pi GenBook
arm64: dts: rockchip: Enable HDMI display for rk3588 Cool Pi 4B
arm64: dts: rockchip: Enable HDMI0 for rk3588 Cool Pi CM5 EVB
arm64: dts: rockchip: Enable HDMI on NanoPi R6C/R6S
arm64: dts: rockchip: Enable GPU on NanoPi R6C/R6S
arm64: dts: rockchip: Enable HDMI on Hardkernel ODROID-M2
arm64: dts: rockchip: Remove non-removable flag from sdmmc on rk3576-sige5
arm64: dts: allwinner: a100: perf1: Add eMMC and MMC node
arm64: dts: allwinner: pinephone: Add mount matrix to accelerometer
...
To avoid conflict with sdmmc_det, change pci3x1 pinctrl-0 name.
Only the reset-pin is actually needed.
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Link: https://lore.kernel.org/r/20240918073236.648-1-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa ROCK 5C is a 8K computer for everything[1] using the Rockchip
RK3588S2 chip:
- Rockchip RK3588S2
- Quad A76 and Quad A55 CPU
- 6 TOPS NPU
- up to 32GB LPDDR4x RAM
- eMMC / SPI flash connector
- Micro SD Card slot
- Gigabit ethernet port (supports PoE with add-on PoE HAT)
- WiFi6 / BT5.4
- 1x USB 3.0 Type-A HOST port
- 1x USB 3.0 Type-A OTG port
- 2x USB 2.0 Type-A HOST port
- 1x USB Type-C 5V power port
[1] https://radxa.com/products/rock5/5c
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Link: https://lore.kernel.org/r/20241021090548.1052-2-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The preferred nodename for fixed-regulators has changed to
pattern: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$'
Fix all Rockchip DT regulator nodenames.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/0ae40493-93e9-40cd-9ca9-990ae064f21a@gmail.com
[adapted rebased on top of a number of other changes and included
neu6a-wifi + wolfvision-pf5-io-expander overlays]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The sdmmc node represents a removable SD card host. Make sure it is
considered removable so that SD cards are detected when inserted.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://lore.kernel.org/r/20241108213357.268002-1-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Banana Pi P2 Pro is the SBC made by Shenzhen SINOVOIP based on
Rockchip RK3308.
Banana Pi P2 Pro features:
- Rockchip RK3308B-S
- DDR3 512 MB
- eMMC 8 GB
- 100M lan + onboard PoE
- 40 pin and 12 pin headers
- AP6256 BT + WIFI
- TF card slot
- 2x USB 2.0 (Type-C OTG and Type-A)
- Headphone jack
Add support for Banana Pi P2 Pro.
Signed-off-by: Dmitry Yashin <dmt.yashin@gmail.com>
Link: https://lore.kernel.org/r/20241030202144.629956-3-dmt.yashin@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add new SoC dtsi file for the RK3566T variant of the Rockchip RK3566 SoC.
The difference between the RK3566T variant and the "full-fat" RK3566 variant
is in fewer supported CPU and GPU OPPs on the RK3566T, and in the absence of
a functional NPU, which we currently don't have to worry about.
Examples of the boards based on the RK3566T include the Pine64 Quartz64 Zero
SBC, [1] which is yet to be supported, the Radxa ROCK 3C, and the Radxa ZERO
3E/3W SBCs, which are both already supported. Though, Radxa doesn't mention
the use of RK3566T officially, but its official SBC specifications do state
that the maximum frequency for the Cortex-A55 cores on those SBCs is lower
than the "full-fat" RK3566's 1.8 GHz, which makes spotting the presence of
the RK3566T SoC variant rather easy. [2][3][4] An additional, helpful cue
is that Radxa handles the CPU and GPU OPPs for the RK3566T variant separately
in its downstream kernel source. [5]
The CPU and GPU OPPs supported on the RK3566T SoC variant are taken from the
vendor kernel source, [6] which uses the values of the "opp-supported-hw" OPP
properties to determine which ones are supported on a particular SoC variant.
The actual values of the "opp-supported-hw" properties make it rather easy
to see what OPPs are supported on the RK3566T SoC variant, but that, rather
unfortunately, clashes with the maximum frequencies advertised officially
for the Cortex-A55 CPU cores on the above-mentioned SBCs. [1][2][3][4] The
vendor kernel source indicates that the maximum frequency for the CPU cores
is 1.4 GHz, while the SBC specifications state that to be 1.6 GHz. Until
that discrepancy is resolved somehow, let's take the safe approach and use
the lower maximum frequency for the CPU cores.
Update the dts files of the currently supported RK3566T-based boards to use
the new SoC dtsi for the RK3566T variant. This actually takes the CPU cores
and the GPUs found on these boards out of their earlier overclocks, but it
also means that the officially advertised specifications [1][2][3][4] of the
highest supported frequencies for the Cortex-A55 CPU cores on these boards
may actually be wrong, as already explained above.
The correctness of the introduced changes was validated by decompiling and
comparing all affected board dtb files before and after these changes.
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
[5] 2dfd51da47
[6] https://raw.githubusercontent.com/rockchip-linux/kernel/f8b9431ee38ed561650be7092ab93f564598daa9/arch/arm64/boot/dts/rockchip/rk3568.dtsi
Cc: TL Lim <tllim@pine64.org>
Cc: Marek Kraus <gamiee@pine64.org>
Cc: Tom Cubie <tom@radxa.com>
Cc: FUKAUMI Naoki <naoki@radxa.com>
Helped-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Helped-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/a85b9bdc176c542fea261fe7ef37697aebb42e8b.1730516702.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Rename the Rockchip RK356x SoC dtsi files and, consequently, adjust their
contents appropriately, to prepare them for the ability to specify different
CPU and GPU OPPs for each of the supported RK356x SoC variants.
The first new RK356x SoC variant to be introduced is the RK3566T, which the
Pine64 Quartz64 Zero SBC is officially based on. [1] Some other SBCs are
also based on the RK3566T variant, including Radxa ROCK 3C and ZERO 3E/3W,
but the slight trouble is that Radxa doesn't state that officially. Though,
it's rather easy to spot the RK3566T on such boards, because their official
specifications state that the maximum frequency for the Cortex-A55 cores is
lower than the "full-fat" RK3566's 1.8 GHz. [2][3][4]
These changes follow the approach used for the Rockchip RK3588 SoC variants,
which was introduced and described further in commit def88eb4d8 ("arm64:
dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please
see that commit for a more detailed explanation.
No functional changes are introduced, which was validated by decompiling and
comparing all affected board dtb files before and after these changes. In
more detail, the affected dtb files have some of their blocks shuffled around
a bit and some of their phandles have different values, as a result of the
changes to the order in which the building blocks from the parent dtsi files
are included, but they effectively remain the same as the originals.
As a side note, due to the nature of introduced changes, this commit is a bit
more readable when viewed using the --break-rewrites option for git-log(1).
[1] https://wiki.pine64.org/wiki/Quartz64
[2] https://dl.radxa.com/rock3/docs/hw/3c/radxa_rock3c_product_brief.pdf
[3] https://dl.radxa.com/zero3/docs/hw/3e/radxa_zero_3e_product_brief.pdf
[4] https://dl.radxa.com/zero3/docs/hw/3w/radxa_zero_3w_product_brief.pdf
Related-to: def88eb4d8 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs")
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/77e7450b8280bbdf4e2dc47366c9da85d4d8d1de.1730516702.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for voltage ranges to the CPU, GPU and DMC OPPs defined in the
SoC dtsi for Rockchip OP1, as a variant of the Rockchip RK3399. This may be
useful if there are any OP1-based boards whose associated voltage regulators
are unable to deliver the exact voltages; otherwise, it causes no functional
changes to the resulting OPP voltages at runtime.
These changes cannot cause stability issues or any kind of damage, because
it's perfectly safe to use the highest voltage from an OPP group for each OPP
in the same group. The only possible negative effect of using higher voltages
is wasted energy in form of some additionally generated heat.
Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/dbee35c002bda99e44f8533623d94f202a60da95.1730881777.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Correct the audio name for the Indiedroid Nova from
rockchip,es8388-codec to rockchip,es8388. This name change corrects a
kernel log error of "ASoC: driver name too long 'rockchip,es8388-codec'
-> 'rockchip_es8388'".
Fixes: 3900160e16 ("arm64: dts: rockchip: Add Indiedroid Nova board")
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20241031150505.967909-2-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Implements a slightly modified rk3588s-orangepi-5b.dts from the vendor.
Unfortunately the &wireless_bluetooth and &wireless_wlan are not
implemented yet.
Therefore add the sdhci alias to be mmc0 on the rk3588s-orangepi-5b.dts.
How is the Orange Pi 5B unique?
- the Orange Pi 5b uses combphy0_ps for the WiFi.
- the Orange Pi 5B has GPIO0_C5 hooked to BT_WAKE_HOST.
- builtin eMMC storage
- ap6275p Wifi module (like the Orange Pi 5 Plus)
- builtin BlueTooth module
Signed-off-by: Cenk Uluisik <cenk.uluisik@googlemail.com>
Link: https://lore.kernel.org/r/20241024095038.42079-3-cenk.uluisik@googlemail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Unique to the Orange Pi 5 board:
- M.2 NVMe M-Key PCIe 2.0x1 on combphy0_ps
- SPI NOR flash
Co-Developed-by: Jimmy Hon <honyuenkwun@gmail.com>
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Signed-off-by: Cenk Uluisik <cenk.uluisik@googlemail.com>
Link: https://lore.kernel.org/r/20241024095038.42079-1-cenk.uluisik@googlemail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Paragraph "3.4 Power up Timing Sequence" of the AzureWave-CM256SM
datasheet mentions the following about the BT_REG_ON pin, which is
connected to GPIO0_C4_d:
When this pin is low and WL_REG_ON is high,
the BT section is in reset.
Therefor set that pin to GPIO_ACTIVE_HIGH so that it can be pulled low
for a reset.
If set to GPIO_ACTIVE_LOW, the following errors are observed:
Bluetooth: hci0: command 0x0c03 tx timeout
Bluetooth: hci0: BCM: Reset failed (-110)
So fix the GPIO polarity by setting it to ACTIVE_HIGH.
This also matches what other devices with the same BT device have.
Fixes: 2b6a3f8575 ("arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes")
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20241018145053.11928-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The binding for Everest ES8328/ES8388 audio CODEC doesn't support the
'clock-names' property:
rk3588-orangepi-5-plus.dtb: audio-codec@11: 'clock-names' does not match any of the regexes: 'pinctrl-[0-9]+'
from schema $id: http://devicetree.org/schemas/sound/everest,es8328.yaml#
Since the related audio driver is also not making use of it, drop the
invalid property from all es8388 codec nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20241019-es8328-dt-fixes-v1-1-ca77d5ce21ad@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The patch adding display support for the pinephone pro introduced two
regulators that contain pinctrl-names props but no pinctrl-assignments.
Looks like someone forgot the pinctrl settings, so remove the orphans
for now, until that changes.
Fixes: 3e987e1f22 ("arm64: dts: rockchip: Add internal display support to rk3399-pinephone-pro")
Cc: Martijn Braam <martijn@brixit.nl>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Ondrej Jirman <megi@xff.cz>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-11-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The 'enable-active-low' property is not a valid, because it is the
default behaviour of the fixed regulator.
Only 'enable-active-high' is valid, and when this property is absent
the fixed regulator will act as active low by default.
Both the rk3588-orange-pi-5 and the Wolfvision pf5 io expander overlay
smuggled those enable-active-low properties in, so remove them to
make dtbscheck happier.
Fixes: 28799a7734 ("arm64: dts: rockchip: add wolfvision pf5 io expander board")
Cc: Michael Riesch <michael.riesch@wolfvision.net>
Fixes: b6bc755d80 ("arm64: dts: rockchip: Add Orange Pi 5")
Cc: Muhammed Efe Cetin <efectn@6tel.net>
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20241008203940.2573684-10-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The jaguar has an hdmi output port, which is connected
to the hdmi0 controller of the rk3588.
Add the necessary plumbing to enable it using the recently merged
hdmi-qp controller.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20241024151403.1748554-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Haikou baseboard has an hdmi output port, which is connected
via the Q7 connector to the hdmi0 controller of the rk3588.
Add the necessary plumbing to enable it using the recently merged
hdmi-qp controller.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20241024151403.1748554-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Tiger SoM routes all relevant HDMI pins to its Q7 connector.
Some from the M0 and some from the M1 set of pins.
Add the necessary pinctrl entry to the hdmi controller for the SoM.
Not all baseboards may use all pins, but even for them it'll serve
documentation purposes.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20241024151403.1748554-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Typically any non-removable storage (emmc) is listed before removable
storage (sd-card) options. Also U-Boot will try to override and use
mmc0=sdhci and mmc1=sdmmc0 for all rk356x boards.
Fixes: 50decd493c ("arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20241022193537.1117919-6-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The status prop is typically the last prop.
Fixes: 50decd493c ("arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20241022193537.1117919-4-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Use the marketing name for model name, this matches the dt-binding.
Also update the website url in copyright.
Fixes: 50decd493c ("arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tianling Shen <cnsztl@gmail.com>
Link: https://lore.kernel.org/r/20241022193537.1117919-2-cnsztl@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT changes to enable HDMI0 on FriendlyELEC NanoPC-T6.
Tested on LTS variant of the board but this part is the same on both.
Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Link: https://lore.kernel.org/r/20241023080605.623125-1-marcin.juszkiewicz@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fix the node order so analog-audio is before hdmi0-con
Audio was submitted first, and it wanted to live above the leds node.
Next, the HDMI was submitted, but it wanted to live above the leds node.
However, HDMI was approved first, so the Audio node ended up living above
the leds node.
Fixes: ae46756faf ("arm64: dts: rockchip: analog audio on Orange Pi 5")
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20241024041851.5600-1-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Following the hierarchical representation of the SoC data that's been already
established in the commit 296602b8e5 ("arm64: dts: rockchip: Move RK3399
OPPs to dtsi files for SoC variants"), add new SoC dtsi file for the Rockchip
RK3399S SoC, which is yet another variant of the Rockchip RK3399 SoC.
The only perceivable differences between the RK3399S and the RK3399 are in
the supported CPU DVFS OPPs, which result from the RK3399S being binned for
lower maximum CPU frequencies than the regular RK3399 variant.
The RK3399S variant is used in the Pine64 PinePhone Pro only, [1] whose board
dts file included the necessary adjustments to the CPU DVFS OPPs. This commit
effectively moves those adjustments into the separate RK3399S SoC dtsi file,
following the above-mentioned "encapsulation" approach.
No functional changes are introduced, which was validated by decompiling and
comparing the affected dtb file before and after these changes.
[1] https://wiki.pine64.org/index.php/PinePhone_Pro
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/c32622e4a6897378d9df81c8c3eda1bdb9211e0b.1728632052.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
