The RK3576 SoC now has upstream support for HDMI.
Add an HDMI audio node, which uses SAI6 as its audio controller
according to downstream.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-2-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3576 SoC has 10 SAI controllers in total. Five of them are in the
video output power domains, and are used for digital audio output along
with the video signal of those, e.g. HDMI audio.
The other five, SAI0 through SAI4, are exposed externally. SAI0 and SAI1
are capable of 8-channel audio, whereas SAI2, SAI3 and SAI4 are limited
to two channels. These five are in the audio power domain.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250506-rk3576-sai-v4-1-a8b5f5733ceb@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
RK3528 features two SDIO controllers and one SD/MMC controller, describe
them in devicetree. Since their sample and drive clocks are located in
the VO and VPU GRFs, corresponding syscons are added to make these
clocks available.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250508234829.27111-3-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Following commit b956c9de91 ("arm64: dts: rockchip: rk356x: Move
PCIe MSI to use GIC ITS instead of MBI"), change the PCIe3 controller's
MSI on rk3568 to use ITS, so that all MSI-X can work properly.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250308093008.568437-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the 3.3v and 1.8v regulators that are connected to
the eMMC on the R5 series devices, as well as adding the
eMMC data strobe, and enable eMMC HS200 mode as the
Foresee FEMDNN0xxG-A3A55 modules support it.
Fixes: c8ec73b05a ("arm64: dts: rockchip: create common dtsi for NanoPi R5 series")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250506222531.625157-1-pbrobinson@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As described in the radxa_rock_3c_v1400_schematic.pdf, the SPI Flash's
VCC connector is connected to VCCIO_FLASH and according to the
that same schematic, that belongs to the VCC_1V8 power source.
This fixes the following warning:
spi-nor spi4.0: supply vcc not found, using dummy regulator
Fixes: ee219017dd ("arm64: dts: rockchip: Add Radxa ROCK 3C")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Link: https://lore.kernel.org/r/20250506195702.593044-1-pbrobinson@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable pwm and fixed regulators for Radxa E20C. The pwm regulator is
used to power the CPU and GPU. Note that the LPDDR4 voltage is 1.1V.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250401120020.976343-3-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add pwm nodes for RK3528. The PWM core on RK3528 is the same as
RK3328, but the driver does not support interrupts yet.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250401120020.976343-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Radxa E20C ships an onboard I2C EEPROM for storing production
information. Enable it in devicetree.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250417120118.17610-6-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Describe I2C controllers shipped by RK3528 in devicetree. For I2C-2,
I2C-4 and I2C-7 which come with only a set of possible pins, a default
pin configuration is included.
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250417120118.17610-5-ziyao@disroot.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3576 has a hardware random number generator IP built into the SoC.
Add it to the SoC's .dtsi, now that there's a binding and driver for it.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250430-rk3576-hwrng-v1-3-480c15b5843e@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The property qcom,ath10k-calibration-variant was deprecated in favor of
recently introduced generic qcom,calibration-variant, common to all
Qualcomm Atheros WiFi bindings.
Change will affect out of tree users, like other projects, of this DTS.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250501160208.96451-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Quartz64 Model B has a Winbound 25Q64DWZPIG SPI flash chip,
identified as 'U13' on the component placement schematic.
In the Quartz 64 Model-B Schematic from 20220124 on page 17, we can see
that the VCC connector is connected to VCCIO_FLASH and page 4 shows that
that in turn is connected to the VCCIO2 domain.
That domain uses vcc_1v8 as its power source.
This fixes the following warning:
spi-nor spi4.0: supply vcc not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250503152917.138648-3-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to paragraph "7.16. Power" of the RTL8211F-CG datasheet, gmac0
needs to have a 3.3V power supply.
On page 22 of the NanoPi R5S version 2204, that is identified as
VCC_GEPHY_3V3 which is connected to the VCC_3V3 power source.
This fixes the following warning:
rk_gmac-dwmac fe2a0000.ethernet: supply phy not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250503152917.138648-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The USB-C port on the NanoPC-T6 was not providing VBUS (vbus5v0_typec
regulator disabled, gpio-58 out lo) due to misconfiguration. The
original setup with regulator-always-on and regulator-boot-on forced
the port on, masking the issue, but removing these properties revealed
that the fusb302 driver was not enabling the regulator dynamically.
Changes:
- Removed regulator-always-on and regulator-boot-on from vbus5v0_typec
and vbus5v0_usb to allow driver control.
- Changed power-role from "source" to "dual" in the usb-c-connector to
support OTG functionality.
- Added pd-revision = /bits/ 8 <0x2 0x0 0x1 0x2> to the FUSB302MPX
node to specify USB Power Delivery (PD) Revision 2.0, Version 1.2,
ensuring the driver correctly advertises PD capabilities and
negotiates power roles (source/sink).
- Added op-sink-microwatt and sink-pdos for proper sink mode
configuration (1W min, 15W max).
- Added typec-power-opmode = "1.5A" to enable 1.5A fallback for non-PD
USB-C devices, aligning with the 5V/2A hardware limit.
- Set try-power-role to "source" to prioritize VBUS enablement.
- Adjusted usb_host0_xhci dr_mode from "host" to "otg" and added
usb-role-switch for dual-role support.
Testing:
- Verified VBUS (5V) delivery to a sink device (USB thumb drive).
- Confirmed USB host mode with lsusb detecting connected devices.
- Validated USB device mode with adb devices when connected to a PC.
- Tested dual-role (OTG) functionality with try-power-role set to
"source" and "sink"; "source" prioritizes faster VBUS activation.
- Validated functionality with a mobile device, including USB Power
Delivery, file transfer, USB tethering, MIDI, and image transfer.
- Tested USB-C Ethernet adapter compatibility in host mode.
- Tested USB-C hub compatibility in host mode.
Signed-off-by: John Clark <inindev@gmail.com>
Link: https://lore.kernel.org/r/20250422210345.196050-1-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Orange Pi 5 Max and Ultra has onboard AP6611s with Bluetooth 5.3
connected via UART7.
The chip reports as:
[ 3.747864] Bluetooth: hci0: BCM: chip id 3
[ 3.750021] Bluetooth: hci0: BCM: features 0x0f
[ 3.775923] Bluetooth: hci0: SYN43711A0
[ 3.775930] Bluetooth: hci0: BCM (001.001.030) build 0000
Signed-off-by: Jimmy Hon <honyuenkwun@gmail.com>
Link: https://lore.kernel.org/r/20250427182019.1862-1-honyuenkwun@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3576 features two SATA nodes. The first, sata0, is behind
combphy0, which muxes between pcie0 and sata0.
The second, sata1, is behind combphy1, which muxes between pcie1, sata1
and usb_drd1_dwc3.
I've only been able to test sata0 on my board, but it appears to work
just fine.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250424-rk3576-sata-v1-2-23ee89c939fe@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Someone made a typo when they added the RTC to the Sige5 DTS, which
resulted in it using interrupts from GPIO0 B0 instead of GPIO0 A0. The
pinctrl entry for it wasn't typoed though, curiously enough.
The Sige5 v1.1 schematic was used to verify that GPIO0 A0 is the correct
pin for the RTC wakeup interrupt, so let's change it to that.
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/20250429-sige5-rtc-oopsie-v1-1-8686767d0f1f@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Radxa Rock 5B component placement document identifies the SPI Nor
Flash chip as 'U4300' which is described on page 25 of the Schematic
v1.45. There we can see that the VCC connector is connected to the
VCC_3V3_S3 power source.
This fixes the following warning:
spi-nor spi5.0: supply vcc not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250425092601.56549-5-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As described on page 37 of PineTab2 Schematic-20230417, the SPI Flash's
VCC connector is connected to VCCIO_FLASH and according to page 6 of
that same schematic, that belongs to the VCC_1V8 power source.
This fixes the following warning:
spi-nor spi4.0: supply vcc not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250425092601.56549-4-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As described on page 16 of the RockPro64 schematics for both v2.0 and
v2.1, the SPI Flash's VCC connector is connected to the VCC_3V0 power
source.
This fixes the following warning:
spi-nor spi1.0: supply vcc not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250425092601.56549-3-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As described on page 6 of the Rock64 schematics for both v2.0 and v3.0
the SPI Flash's VCC connector is connected to the VCC_IO power source.
This fixes the following warning:
spi-nor spi0.0: supply vcc not found, using dummy regulator
Signed-off-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250425092601.56549-2-didi.debian@cknow.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add vcc supply to the spi-nor flash chip on rk3399-roc-pc boards
according to the board schematics ROC-3399-PC-V10-A-20180804 to avoid
warnings in dmesg output.
Signed-off-by: Markus Reichl <m.reichl@fivetechno.de>
Link: https://lore.kernel.org/r/20250411140223.1069-1-m.reichl@fivetechno.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The ArmSoM Sige5 board exposes PCIe controller 0 on its M.2 slot on the
bottom of the board. Enable the necessary nodes for it, and also add the
correct pins for both the power enable GPIO and the PCIe reset GPIO.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250414-rk3576-sige5-pcie-v1-1-0e950a96f392@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
PCIe1 and usb_drd1_dwc3 is sharing the same PHY on RK3576 platform.
For pcie1 slot and USB interface, there is a swich IC labelled as
Dial_Switch_1 on evb1 board. If we need to make pcie1 slot work for this
board, we should first disable usb_drd1_dwc3 and then set Dial_Switch_1
to low state.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Link: https://lore.kernel.org/r/1745371359-30443-1-git-send-email-shawn.lin@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Cool Pi CM5 GenBook equipped with a 1080P eDP panel, the panel
connected on board with 30/40 pin connector.
There is no hpd hooked up on the board, so we need to set
hpd-absent-delay-ms in dts.
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20250426071554.1305042-2-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This commit adds the RTS signal, specifies the compatible Broadcom chip,
its clock source, interrupts, GPIOs for wakeup and shutdown, maximum speed,
pinctrl settings, and power supplies.
Signed-off-by: Muhammed Efe Cetin <efectn@protonmail.com>
Signed-off-by: Jacobe Zang <jacobe.zang@wesion.com>
Link: https://lore.kernel.org/r/20250424-edge-v1-1-314aad01d9ab@wesion.com
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 Tiger RK3588 SoM.
The Video Demo adapter is an adapter connected to the fake PCIe slot
labeled "Video Connector" on the Haikou devkit.
It's main feature is a Leadtek DSI-display with touchscreen and a camera
(that is not supported yet). 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: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Dragan Simic <dsimic@manjaro.org> # Makefile
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250226140942.3825223-4-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Realtek RT5616 audio codec on the FriendlyElec CM3588 module fails
to probe correctly due to the missing clock properties. This results
in distorted analogue audio output.
Assign MCLK to 12.288 MHz, which allows the codec to advertise most of
the standard sample rates per other RK3588 devices.
Fixes: e23819cf27 ("arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board")
Signed-off-by: Tom Vincent <linux@tlvince.com>
Link: https://lore.kernel.org/r/20250417081753.644950-1-linux@tlvince.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Since commit 3c3606793f ("dt-bindings: wireless: bcm4329-fmac: Use
wireless-controller.yaml schema"), bindings expect 'wifi' as node name:
rk3566-bigtreetech-cb2-manta.dtb: sdio-wifi@1: $nodename:0: 'sdio-wifi@1' does not match '^wifi(@.*)?$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250424084729.105182-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 comes with two DSI2 controllers based on a new Synopsis IP.
Add the necessary nodes for them.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # RK3588 EVB1
Link: https://lore.kernel.org/r/20250226140942.3825223-3-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the two MIPI-DC-phy nodes to the RK3588, that will be used by the
DSI2 controllers and hopefully in some future also for camera input.
Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> # RK3588 EVB1
Link: https://lore.kernel.org/r/20250226140942.3825223-2-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
rk3576 has two pcie controllers, both are pcie2x1 work with
naneng-combphy.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Shawn Lin <Shawn.lin@rock-chips.com>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250414145110.11275-3-kever.yang@rock-chips.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
There are two hdmi connector on Cool Pi CM5 EVB, the current supported
is hdmi0, assign corresponding index to it. It will be convenient for
us to add support for another one.
Signed-off-by: Andy Yan <andyshrk@163.com>
Link: https://lore.kernel.org/r/20250419121326.388298-1-andyshrk@163.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the necessary DT changes to enable eDP0 on RK3588S EVB1 board:
- Set pinctrl of pwm12 for backlight
- Enable edp0/hdptxphy0/vp2
- Assign the parent of DCLK_VOP2_SRC to PLL_V0PLL
- Add aux-bus/panel nodes
For RK3588, the PLL_V0PLL is specifically designed for the VOP2. This
means the clock rate of PLL_V0PLL can be adjusted according to the dclk
rate of relevant VP. It is typically assigned as the dclk source of a
specific VP when the clock of relevant display mode is unusual, such as
the eDP panel 'lg,lp079qx1-sp0v' paired with RK3588S EVB1, which has a
clock rate of 202.02MHz.
Additionally, the 'force-hpd' is set for edp0 because the HPD pin on the
panel side is not connected to the eDP HPD pin on the SoC side according
to the RK3588S EVB1 hardware design.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Link: https://lore.kernel.org/r/20250310104114.2608063-14-damon.ding@rock-chips.com
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: c9211fa260 ("arm64: dts: rockchip: Add base DT for rk3588 SoC")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250401090009.733771-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The UART ports on RK3528 have DMA capability, describe it.
Flow control is optional, so dma-names are not added.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250401100020.944658-4-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The interrupt of uart3 node on rk3528 is missing, fix it.
Fixes: 7983e6c379 ("arm64: dts: rockchip: Add base DT for rk3528 SoC")
Reviewed-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Link: https://lore.kernel.org/r/20250401100020.944658-2-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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>
