The vcc_sdio regulator supports 1.8V to 3.4V output range according to
its datasheet.
The current DT incorrectly limits the max voltage to 3.0V. This limit
causes issues issues downstream with u-boot, which refuses to apply the
out-of range value, and falls back to the minimum in that range: 1.8V.
This is insufficient to power the SD card, so driver initialisation
fails and booting from it does not work.
Set regulator-max-microvolt to 3400000 µV to match hardware capability.
This matches the rk3399-orangepi for the same regulator.
Signed-off-by: Hugo Osvaldo Barrera <hugo@whynothugo.nl>
Reviewed-by: Dang Huynh <dang.huynh@mainlining.org>
Link: https://patch.msgid.link/20260519094439.7918-1-hugo@whynothugo.nl
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The NanoPi Zero2 has one USB 2.0 Type-A HOST port and one USB 2.0 Type-C
OTG port.
Add support for using the USB 2.0 ports on NanoPi Zero2.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260529190355.4148175-6-heiko@sntech.de
The ArmSoM Sige1 has two USB 2.0 Type-A HOST ports behind an onboard
USB hub, and one USB 2.0 Type-C OTG port.
Add support for using the USB 2.0 ports on ArmSoM Sige1.
The onboard USB hub handles OHCI so only the EHCI controller is enabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
[added phy-supply for otg port]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260529190355.4148175-5-heiko@sntech.de
The ROCK 2A has three USB 2.0 Type-A HOST ports behind an onboard
USB hub, and one USB 3.0 Type-A port.
And the ROCK 2F has two USB 2.0 Type-A HOST ports behind an onboard
USB hub, and one USB 2.0 Type-C OTG port.
Add support for using the USB ports on Radxa ROCK 2A/2F.
The onboard USB hub handles OHCI so only the EHCI controller is enabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260529190355.4148175-4-heiko@sntech.de
The Radxa E20C has one USB2.0 Type-A HOST port and one USB2.0 Type-C port.
The Type-C port is conneced to a FE1.1s_QFN USB hub on the board, with its
ports being connected to the XHCI usb controller and an usb-uart bridge.
This also means, the XHCI controller can only be used in device-mode.
Add support for using the USB 2.0 ports on Radxa E20C.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
[set xhci to peripheral and add comment about the outward-facing hub]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260529190355.4148175-3-heiko@sntech.de
Rockchip RK3528 has one USB 3.0 DWC3 controller and oneUSB 2.0 EHCI/OHCI
controller and uses an Innosilicon-USB2PHY for USB 2.0. The DWC3
controller additionally uses the Naneng Combo PHY for USB3.
Add device tree nodes to describe these USB controllers along with the
USB 2.0 PHYs.
[moved snps,dis_u2_susphy_quirk here from individual boards,
describe both usb2+3 default phy connections, usb2 boards can override]
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260529190355.4148175-2-heiko@sntech.de
Enable Bluetooth support for the Ampak AP6275P module on the
Khadas Edge 2L. This involves enabling the UART5 interface for
HCI communication and defining the required regulators and
power-sequence pins.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260507033541.2576335-3-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Khadas Edge 2L board provides one USB 3.0 Host port and
one USB 2.0 port (connected via an internal hub). Enable the
corresponding DWC3 controllers and PHYs.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260507033541.2576335-2-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
While the design of the NanoPi R4S is based on the common NanoPi 4
family, it is trimmed down a lot.
Disable all the peripherals on the SoC that are not used, and delete
all the external components that are not present.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
[feels like the cleaner option, than to move those peripherals into a new
rk3399-nanopi-allothers.dtsi, as the r4s variants are not as many ]
Link: https://patch.msgid.link/20260505172903.33271-1-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The EEPROM used on the R4S (enterprise) is the 24AA025E48T-I/OT from
MicroChip. This is a 2-Kbit EEPROM with 16-byte page size. The latter
half of the EEPROM is read-only, and the last 48 bits contain a globally
unique MAC address. That is to say this is not an ordinary EEPROM.
The compatible for this type of EEPROM was introduced later that the
board. Switch over to the correct compatible now that it is available.
Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Link: https://patch.msgid.link/20260505165244.1902-1-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree overlay for the Radxa Camera 4K (featuring the Sony IMX415
image sensor) to applied on the Radxa ROCK 5B+ CAM1 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://patch.msgid.link/20260522-rk3588-vicap-v5-7-d1d1f5265c56@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree overlay for the Radxa Camera 4K (featuring the Sony IMX415
image sensor) to applied on the Radxa ROCK 5B+ CAM0 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://patch.msgid.link/20260522-rk3588-vicap-v5-6-d1d1f5265c56@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the device tree node for the RK3588 Video Capture (VICAP) unit.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
[converted reg values in vicap ports to hexadecimal, to have them align
with the port@X values, and be less confusing]
Link: https://patch.msgid.link/20260522-rk3588-vicap-v5-5-d1d1f5265c56@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The ARMv8.2 based CPUs used in a number of Rockchip SoCs are missing
the EL2 virtual timer interrupt. Add it.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260523140242.586031-16-maz@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add devicetree nodes for the RGA3 (Raster Graphics Acceleration 3)
peripheral in the RK3588.
The existing rga node refers to the RGA2-Enhanced peripheral. The RK3588
contains one RGA2-Enhanced core and two RGA3 cores. Both feature a similar
functionality of scaling, cropping and rotating of up to two input
images into one output image. Key differences of the RGA3 are:
- supports 10bit YUV output formats
- supports 8x8 tiles and FBCD as inputs and outputs
- supports BT2020 color space conversion
- max output resolution of (8192-64)x(8192-64)
- MMU can map up to 32G DDR RAM
- fully planar formats (3 planes) are not supported
- max scale up/down factor of 8 (RGA2 allows up to 16)
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
Link: https://patch.msgid.link/20260521-spu-rga3-v7-28-3f33e8c7145f@pengutronix.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0 (not supported)
- MIPI1: connected to MIPI DCPHY1 (not supported)
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (not supported)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (not supported)
As the MIPI DCPHYs as well as the split DPHY mode of the DPHYs are not yet
supported, add only the device tree nodes for the MIPI2 and MIPI4 units.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
Link: https://patch.msgid.link/20260305-rk3588-csi2rx-v5-2-3b7061d043ea@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK809 PMIC interrupt pin on the Firefly ROC-RK3566-PC (Station M2)
is physically connected to GPIO0_A3 (RK_PA3) according to the board's
schematic.
Currently, the PMIC node incorrectly specifies RK_PA7 for the interrupt,
which prevents the PMIC from correctly signaling interrupts. (Note that
the pinctrl node 'pmic_int' correctly configures RK_PA3).
Fix this by updating the interrupts property to use RK_PA3.
Fixes: 30ac9b4e25 ("arm64: dts: rockchip: add dts for Firefly Station M2 rk3566")
Signed-off-by: Weixin Guo <2298701336@qq.com>
Link: https://patch.msgid.link/tencent_5035EEE630C845B1B51DEA4284DE23DCCE06@qq.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Several rk3588s board DTS files override pinctrl-0 for i2c, i2s, pwm,
spi, tsadc and uart nodes without re-specifying pinctrl-names. While
the property is inherited from the base rk3588s.dtsi, add it explicitly
to the board-level overrides for consistency with other nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-13-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Several rk3588 board DTS files override pinctrl-0 for i2c, i2s, pcie,
pwm, sdmmc, spdif, spi and uart nodes without re-specifying
pinctrl-names. While the property is inherited from the base SoC DTSI,
add it explicitly to the board-level overrides for consistency with
other nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-12-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Several rk3576 board DTS files override pinctrl-0 for uart0 without
re-specifying pinctrl-names. While the property is inherited from the
base rk3576.dtsi, add it explicitly to the board-level overrides for
consistency with other nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-11-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Remove the unnecessary #address-cells and #size-cells properties from
the usb_host0_xhci and usb_host1_xhci port nodes, as they each contain
a single endpoint child with no reg property.
This fixes the following dtc warnings:
rk3588-jaguar.dts: Warning (avoid_unnecessary_addr_size):
/usb@fc000000/port: unnecessary #address-cells/#size-cells [...]
/usb@fc400000/port: unnecessary #address-cells/#size-cells [...]
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-10-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_B2 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, move hym8563 down to fix the ordering of &pinctrl entries.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-9-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_B5 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, rename the hdmi_frl_pin pinmux to hdmi0_tx_on_h, in line
with the naming commonly used in RK3588s-bassed board schematics.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-8-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_B1 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, remove the duplicated &hdmi0_sound node.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-7-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_B3 pin to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, drop the now unnecessary ddc-en-gpios property and the
associated pinctrl-* entries from hdmi0-con, and rename the hdmi0_en
pinmux to hdmi0_tx_on_h, in line with the naming commonly used in
RK3588s-based board schematics.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-6-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The following RK3588s boards expose a GPIO pin to control the voltage
bias on the HDMI0 data lines:
- rk3588s-coolpi-4b
- rk3588s-indiedroid-nova
- rk3588s-nanopi-r6
- rk3588s-odroid-m2
- rk3588s-orangepi-5
- rk3588s-radxa-cm5-io
- rk3588s-rock-5a
- rk3588s-rock-5c
The pin must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
While at it, also ensure that pinctrl-names is present and ordered
alphabetically within the hdmi nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-5-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The following RK3588 boards expose one or two GPIO pins to control the
voltage bias on the HDMI0 and/or HDMI1 data lines:
- rk3588-armsom-sige7
- rk3588-armsom-w3
- rk3588-coolpi-cm5-evb
- rk3588-coolpi-cm5-genbook
- rk3588-evb1-v10
- rk3588-evb2-v10
- rk3588-firefly-itx-3588j
- rk3588-friendlyelec-cm3588-nas
- rk3588-h96-max-v58
- rk3588-jaguar
- rk3588-mnt-reform2
- rk3588-nanopc-t6
- rk3588-orangepi-5-max
- rk3588-orangepi-5-plus
- rk3588-orangepi-5-ultra
- rk3588-roc-rt
- rk3588-rock-5-itx
- rk3588-rock-5b-5bp-5t
- rk3588-tiger
The pins must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi0 and/or hdmi1 nodes to their dedicated GPIO pin(s) via
frl-enable-gpios to allow adjusting the bias when transitioning between
TMDS and FRL modes.
While at it, also ensure that pinctrl-names is present and ordered
alphabetically within the hdmi nodes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-4-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, drop the now unnecessary workaround of using vcc5v_hdmi_tx
as hdmi-pwr-supply solely to drive the GPIO into its default state.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-3-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, remove the now unnecessary workaround of using
vcc_5v0_hdmi as hdmi-pwr-supply solely to drive the GPIO into its
default state.
Also rename the hdmi_con_en pinctrl to hdmi_tx_on_h to match the
schematic naming.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-2-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The following RK3576 boards expose a GPIO pin to control the voltage
bias on the HDMI data lines:
- rk3576-100ask-dshanpi-a1
- rk3576-armsom-sige5
- rk3576-evb1-v10
- rk3576-evb2-v10
- rk3576-nanopi-m5
- rk3576-roc-pc
- rk3576-rock-4d
The pin must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-1-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Khadas Edge 2L uses an Ampak AP6275P (BCM43752) PCIe
Wi-Fi 6 module.
Enable combphy0 and pcie0, add the Wi-Fi regulator and reset
pinctrl, and describe the PCIe Wi-Fi function so it can consume
the 32.768kHz LPO clock provided by the HYM8563 RTC.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260429063712.2150938-4-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Khadas Edge 2L uses an on-board HYM8563 RTC connected to
I2C2. Enable it and expose its 32.768kHz clock output so later
board-level patches can reference it as the LPO clock source for
the AP6275P wireless module.
Mark the RTC as a wakeup source as well.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260429063712.2150938-3-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
## From a RK3399 Gru/Kevin Chromebook:
# find /sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware/coreboot
/sys/firmware/devicetree/base/firmware/coreboot/ram-code
/sys/firmware/devicetree/base/firmware/coreboot/compatible
/sys/firmware/devicetree/base/firmware/coreboot/board-id
/sys/firmware/devicetree/base/firmware/coreboot/reg
/sys/firmware/devicetree/base/firmware/coreboot/name
/sys/firmware/devicetree/base/firmware/chromeos
/sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/active-ec-firmware
/sys/firmware/devicetree/base/firmware/chromeos/firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage
/sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset
/sys/firmware/devicetree/base/firmware/chromeos/hardware-id
/sys/firmware/devicetree/base/firmware/chromeos/compatible
/sys/firmware/devicetree/base/firmware/chromeos/firmware-type
/sys/firmware/devicetree/base/firmware/chromeos/fmap-offset
/sys/firmware/devicetree/base/firmware/chromeos/name
/sys/firmware/devicetree/base/firmware/ranges
/sys/firmware/devicetree/base/firmware/name
The /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
[On RK3399-based Chromebooks there is no real other way than to load the
DTB together with its kernel when running a mainline kernel and as the
whole line is EOL, there also won't be any updates to the bootloader that
could fix that issue there.]
Link: https://patch.msgid.link/20260428200712.2660635-2-briannorris@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the Video Output Processor (VOP) and the HDMI TX controller
to support HDMI display output on the Khadas Edge 2L. Also, enable
the associated HDMI PHY.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260325054614.1497147-5-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the Mali GPU node on the Khadas Edge 2L board. Assign the
corresponding regulator to the mali-supply property to ensure
proper power management and dynamic voltage scaling (DVFS).
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260325054614.1497147-4-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add RK806 PMIC support for the Khadas Edge 2L board. Assign the
corresponding PMIC regulators (vdd_cpu_lit_s0 and vdd_cpu_big_s0)
to the little and big CPU clusters to enable proper power
management and CPU frequency scaling.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260325054614.1497147-2-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add keyword based matching for 'ARM/Rockchip SoC support'. This will
match rockchip, Rockchip, RockChip and ROCKCHIP separated by any
whitespace character or underscores.
The goal is to match arm64 defconfig patches, which should go through
the Rockchip tree as they right now only match the LKML and thus are
easily lost. The keyword matching is quite good for this, since it
also applies to the commit message and the config options itself might
not give any hint about being relevant for Rockchip.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260327-maintainers-rockchip-keyword-v1-1-7f4634f761a6@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
This chip is currently modeled only as a fixed regulator
(vcc3v3_pi6c_03), with no clock output representation.
The PI6C20100 is a clock generator, not a power supply. Model it
properly as a gated-fixed-clock, following the pattern established
for the Rock 5 ITX and other boards with similar PCIe clock buffer
chips.
The gated-fixed-clock node references the regulator as its vdd-supply,
allowing the regulator to be enabled on demand. Remove the
regulator-always-on and regulator-boot-on properties from vcc3v3_pi6c_03
since the clock framework will manage the regulator lifecycle via
vdd-supply. The pcie3x2 node is updated to include the pipe and
reference clocks, matching the approach used in rk3588-rock-5-itx.dts.
Assisted-by: Claude:claude-3-opus
Signed-off-by: Midgy BALON <midgy971@gmail.com>
Link: https://patch.msgid.link/20260327091128.2458-1-midgy971@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
Signed-off-by: Sten-Silver Ots <stensilver@gmail.com>
Link: https://patch.msgid.link/20260413215301.4656-1-stensilver@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to the NanoPi R5S 2204 schematic on page 6, GPIO0_C4 is for
GMAC0_INT/PMEB_GPIO0_C4, while GPIO0_C5 is for GMAC0_RSTn_GPIO0_C5.
While the 'reset-gpios' property was set correctly, the corresponding
pinctrl didn't match that.
Next to fixing the pinctrl definition, also change the node name and
phandle to match what is used in the schematic.
Fixes: c6629b9a67 ("arm64: dts: rockchip: Add FriendlyElec Nanopi R5S")
Signed-off-by: Diederik de Haas <diederik@cknow-tech.com>
Link: https://patch.msgid.link/20260401131551.734456-2-diederik@cknow-tech.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
When not passing the PHY ID with an ethernet-phy-idX.Y compatible
property, the MDIO bus will attempt to auto-detect the PHY by reading
its registers and then probing the appropriate driver. For this to work,
the PHY needs to be in a working state.
Unfortunately, the net subsystem doesn't control the PHY reset GPIO when
attempting to auto-detect the PHY. This means the PHY needs to be in a
working state when entering the Linux kernel. This historically has been
the case for this device, but only because the bootloader was taking
care of initializing the Ethernet controller even when not using it.
We're attempting to support the removal of the network stack in the
bootloader, which means the Linux kernel will be entered with the PHY
still in reset and now Ethernet doesn't work anymore.
The devices in the field only ever had a TI DP83825, so let's simply
bypass the auto-detection mechanism entirely by passing the appropriate
PHY IDs via the compatible.
Note that this is only an issue since commit e463625af7 ("arm64: dts:
rockchip: move reset to dedicated eth-phy node on ringneck") as before
that commit the reset was done by the MAC controller before starting the
MDIO auto-detection mechanism, via the snps,reset-* properties.
Cc: stable@vger.kernel.org
Fixes: e463625af7 ("arm64: dts: rockchip: move reset to dedicated eth-phy node on ringneck")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260421-px30-eth-phy-v2-2-68c375b120fd@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
When not passing the PHY ID with an ethernet-phy-idX.Y compatible
property, the MDIO bus will attempt to auto-detect the PHY by reading
its registers and then probing the appropriate driver. For this to work,
the PHY needs to be in a working state.
Unfortunately, the net subsystem doesn't control the PHY reset GPIO when
attempting to auto-detect the PHY. This means the PHY needs to be in a
working state when entering the Linux kernel. This historically has been
the case for this device, but only because the bootloader was taking
care of initializing the Ethernet controller even when not using it.
We're attempting to support the removal of the network stack in the
bootloader, which means the Linux kernel will be entered with the PHY
still in reset and now Ethernet doesn't work anymore.
The devices in the field only ever had a TI DP83825, so let's simply
bypass the auto-detection mechanism entirely by passing the appropriate
PHY IDs via the compatible.
Fixes: bb510ddc9d ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260421-px30-eth-phy-v2-1-68c375b120fd@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
With the introduction of the RK3588 SoC, three register blocks have been
provided for the video decoder unit instead of just one, which are
further referenced in the vendor's datasheet by 'link table', 'function'
and 'cache'. The former is present at the top of the listing, starting
at video decoder unit base address, but the binding got this wrong
initially, i.e. the 'function' block got listed before the 'link' one.
Since the video decoder support for the aforementioned SoC in mainline
driver and devicetrees hasn't been released yet (just landed in
v7.0-rc1), address the problem by providing the register blocks for
vdec0 & vdec1 nodes using the 'link,function,cache' listing, which
ensures the unit address points to the primary register range.
This aligns with a similar fix for RK3576, where DTC also complained
about the bus address format.
Fixes: f61731bd60 ("arm64: dts: rockchip: Add the vdpu381 Video Decoders on RK3588")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260304-vdec-reg-order-rk3576-v5-4-7006fad42c3a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
When building device trees for the RK3576 based boards, DTC shows the
following complaint:
rk3576.dtsi:1282.30-1304.5: Warning (simple_bus_reg): /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
Since the video decoder support for the aforementioned SoC in mainline
driver and devicetrees hasn't been released yet (just landed in
v7.0-rc1), fix the issue by providing the register blocks using the
'link,function,cache' listing, which follows the address-based order as
shown in the vendor's datasheet and, implicitly, ensures the unit
address points to the primary register range.
Fixes: da0de806d8 ("arm64: dts: rockchip: Add the vdpu383 Video Decoder on rk3576")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260304-vdec-reg-order-rk3576-v5-3-7006fad42c3a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Raspberry Pi 3B by marking the VEC clk critical so it doesn't get
turned off and hang the bus.
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmnuTSsUHHN3Ym95ZEBj
aHJvbWl1bS5vcmcACgkQrQKIl8bklSUtpw//UbUCefvtSuj7UJLqgZXZgZvos9hU
kQO0kt+wsZCx0w3vKjJojW7E8IiITJDWzVDq6Ib6dVvpoLy0sOvSCbmKrcYLOjaf
kBXAvPHrpBNDDgRD+z3Ci9Sz8Dk9N+x7vQYvXGpUDbGY+dYAx8NGjdbSMqmQofC1
CWYgneh16hUYN8dgZOXC3fZmj4wHt4DGAS3f+uVWML1cLIDv5JR31SAu5i3htgxr
8JUDsBiM2quAjgV81Qp9B102hQGdKBW8AquUnknwtegja6+Go59x2/5jlvE0wjQJ
6Hf7eyUL6PgiAUEGiebLPMKgY6FWT9FtYCuuSqC84EiB5iiLr1MZBX5JsdJ15QRq
fogaABOJxvzy7XnVk0ELqNzn5/uJ/UDPFJkm2RUOUENswi4QuW3O9vJANKTFdUq4
CSz4JO5nqAe+gIbrURl+H8G50nWDHdId69uimbrhZst1E3sue9xDI9G7VwBTTf/8
o+8ylQkfWhGlSMq8yOMTTqUqk5O+uzfEYUYQ7EdzDknuoEsFh1Fy7UpzBLIqVdjd
WylzH9zOdVEI/OUuGmKOJHXy1amGBEV5EISvMRplLyB3R/mFWvIe5kZ4NhtrL9b0
zMjVShkrOP4X4ydOkz6l6oNwgBG+pnosewbwsSYKzSiF5czaXfv96UrQ1J/JNj27
X1Qr/BuY1E2dz0k=
=JtUn
-----END PGP SIGNATURE-----
Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fix from Stephen Boyd:
"One more fix for the merge window to avoid a boot hang on
Raspberry Pi 3B by marking the VEC clk critical so that it
doesn't get turned off and hang the bus"
* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: bcm: rpi: Mark VEC clock as CLK_IGNORE_UNUSED
- Drop class_create() for the "tsm" class
-----BEGIN PGP SIGNATURE-----
iIYEABYKAC4WIQSbo+XnGs+rwLz9XGXfioYZHlFsZwUCae40aBAcZGpid0BrZXJu
ZWwub3JnAAoJEN+KhhkeUWxn/F0BAIpdhnq3TbPMC6Pj0q3DfcXpP+LPD0pqqIom
TwsQVZJCAP4rYVEbIbgeXvkilr7Fpcs2AXbidR/ggBsR3lyVBSNhAA==
=ZK/r
-----END PGP SIGNATURE-----
Merge tag 'tsm-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm
Pull PCIe TSP update from Dan Williams:
"A small update for the TSM core. It is arguably a fix and coming in
late as I have been offline the past few weeks:
- Drop class_create() for the 'tsm' class"
* tag 'tsm-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/devsec/tsm:
virt: coco: change tsm_class to a const struct
- kbuild: builddeb - avoid recompiles for non-cross-compiles
Avoid triggering complete rebuilds for non-cross-compile Debian
package builds by only triggering the rebuild of host tools for
actual cross-compile builds.
- kbuild: Never respect CONFIG_WERROR / W=e to fixdep
Avoid spurious rebuilds of fixdep w/ and w/o -Werror during a single
kbuild invocation by never respecting CONFIG_WERROR for fixdep.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Mathias Krause <minipli@grsecurity.net>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Thomas Weißschuh <linux@weissschuh.net>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEh0E3p4c3JKeBvsLGB1IKcBYmEmkFAmntFCcACgkQB1IKcBYm
Emk/XA//Qzg66EHUmdBncFmN9cT+44QYp2N4cs7pYWiZbeYJ4vPmEVJJNQ0NKHLR
PX+7nvNb0AExnQuCbphoCuhwHwXQdRBE2TogGqDlUjDnRZzgDUtIjeHx96c+G6aV
RiMRWI84qctYj8P2O4zwJclwtojMktL9Ar6epMXScWVEYeYN5hnMcHYOeHqYJ8y1
wzRf+fLdtnRuw+wofph1875udripjrKuIPWMp9QoRaqJXax5qGgasI2m3IQP1klr
1KsqEo7dNtmliviTDMzqrs4ZkA63f9CPgw1qctO3YvEEXXgi137IDnbfTXlVH643
bIvy4d5Y2iu4FvcepAH0vuKQdbHB9CL8FLMBZEZdQEMz1fivVeu5hPMTCxC3pTq0
YrKs7bE49qFyVlHjcawXU/Nm97mtsEpKOEOG4C19vwVtoS46Iv1avCkVrHQLWzIi
nVJ01uPyQYRLngAJ/RKxI2NHP52/Kvtzz/z+SQoqJb5F4Dz1vp67cFKRkKVcH7cm
cCYfmJ8AxcBeT45GrfX9a9T7LtuyUx0lDNZbm2DEFYa4uqweg0QgAlWc4Z9WtbQ7
Ye9WJI6yyLr0e5xDCbcnhMNVQL8hGMbxleVvNYG8sRp5T9otpnp2WVvouRyjjvzm
f6GuKxNdM/eA68pjnBvGfp1sHwp/IVi3yrSbM88T3Jf91JedBEE=
=yCeR
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux
Pull Kbuild fixes from Nicolas Schier:
- builddeb - avoid recompiles for non-cross-compiles
Avoid triggering complete rebuilds for non-cross-compile Debian
package builds by only triggering the rebuild of host tools for
actual cross-compile builds
- Never respect CONFIG_WERROR / W=e to fixdep
Avoid spurious rebuilds of fixdep w/ and w/o -Werror during a single
kbuild invocation by never respecting CONFIG_WERROR for fixdep
* tag 'kbuild-fixes-7.1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux:
kbuild: Never respect CONFIG_WERROR / W=e to fixdep
kbuild: builddeb - avoid recompiles for non-cross-compiles
