Since commit c871a311ed ("phy: rockchip: samsung-hdptx: Setup TMDS
char rate via phy_configure_opts_hdmi"), the workaround of passing the
rate from DW HDMI QP bridge driver via phy_set_bus_width() became
partially broken, as it cannot reliably handle mode switches anymore.
Attempting to fix this up at PHY level would not only introduce
additional hacks, but it would also fail to adequately resolve the
display issues that are a consequence of the system CRU limitations.
Instead, proceed with the solution already implemented for RK3588: make
use of the HDMI PHY PLL as a better suited DCLK source for VOP2. This
will not only address the aforementioned problem, but it should also
facilitate the proper operation of display modes up to 4K@60Hz.
It's worth noting that anything above 4K@30Hz still requires high TMDS
clock ratio and scrambling support, which hasn't been mainlined yet.
Fixes: d74b842cab ("arm64: dts: rockchip: Add vop for rk3576")
Cc: stable@vger.kernel.org
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Tested-By: Detlev Casanova <detlev.casanova@collabora.com>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250612-rk3576-hdmitx-fix-v1-3-4b11007d8675@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
dtc complains with the following message for DTSes which use the ISP:
arch/arm64/boot/dts/rockchip/px30.dtsi:1272.19-1276.6: Warning (graph_child_address): /isp@ff4a0000/ports/port@0: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary
Typically, it is expected from the device DTS(I) to update the SoC DTSI
nodes if they have more than one endpoint, so let's assume there's only
one endpoint in port@0 by default, instead of forcing board DTS(I)s to
/delete-property/ address-cells and size-cells to make dtc happy.
Because PX30 PP1516/EVB's endpoint@0 is the only endpoint and
considering its parent node now has no address-cells property, dtc
complains (same messages for PX30 EVB):
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #address-cells value
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (avoid_default_addr_size): /isp@ff4a0000/ports/port@0/endpoint@0: Relying on default #size-cells value
arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite 'avoid_default_addr_size'
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#address-cells' is -1, must be 1
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-451.6: Warning (graph_endpoint): /isp@ff4a0000/ports/port@0/endpoint@0: graph node '#size-cells' is -1, must be 0
arch/arm64/boot/dts/rockchip/px30-pp1516-ltk050h3146w-a2.dtb: Warning (graph_child_address): Failed prerequisite 'graph_endpoint'
so we fix that by removing the reg property. dtc still complains (same
messages for PX30 EVB):
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi:447.29-450.6: Warning (unit_address_vs_reg): /isp@ff4a0000/ports/port@0/endpoint@0: node has a unit name, but no reg or ranges property
so we also remove the @0 suffix off the node name.
Fixes: 8df7b4537d ("arm64: dts: rockchip: add isp node for px30")
Fixes: 474a77395b ("arm64: dts: rockchip: hook up camera on px30-evb")
Fixes: 56198acdbf ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250610-ringneck-haikou-video-demo-cam-v2-1-de1bf87e0732@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add power-domain nodes for the power controller on RK3528.
Only PD_GPU can fully be powered down. PD_RKVDEC, PD_RKVENC, PD_VO and
PD_VPU are idle only power domains used by miscellaneous devices.
Because multiple of the miscellaneous device types currently complain
about the use of a power-domains prop, only PD_GPU is enabled.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Link: https://lore.kernel.org/r/20250518220707.669515-5-jonas@kwiboo.se
[changed to using numeric values, until the next merge-window]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The ArmSoM Sige5 has several USB ports: a Type-A USB 3 port (USB2 lines
going through a hub), a Type-A USB 2.0 port (also going through a hub),
a Type-C DC input port that has absolutely no USB data connection and a
Type-C port with USB3.2 Gen1x1 that's also the maskrom programming port.
Enable these ports, and set the device role to be host for the host
ports.
The data capable Type-C USB port uses a fusb302 for data role switching.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Link: https://lore.kernel.org/r/20250619-rk3576-sige5-usb-v5-2-9069a7e750e1@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for the Broadcom based WiFi/Bluetooth module (BW3752-50B1)
found in ArmSoM Sige5 boards version 1.2. This includes SDIO connected
WiFi with OOB interrupt support, as well as UART connected Bluetooth
with its respective interrupts.
PCM support for Bluetooth SCO audio is left out for now. It is connected
to SAI2 in M0 pin mode in case someone needs to enable it.
Note that v1.1 boards used a Realtek based module which is incompatible
with these DT nodes, so v1.1 would need a different overlay.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-4-3bb31b02623c@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
ArmSoM Sige5 uses a soldered-on WiFi/BT module with WiFi on SDIO and BT
on UART. However, board v1.1 uses a Realtek based BL-M8852BS2, while
v1.2 uses a Broadcom based BW3752-50B1. They use the same pins and
controllers, but require different DT properties to enable.
Thankfully, the WiFi part at least works without explicitly listing it in
the device tree, albeit without OOB interrupt functionality.
Add required device tree nodes that do not depend on the board version so
that at least the WiFi module can appear on the SDIO bus.
WiFi OOB interrupt and Bluetooth function support are not enabled here, as
they require module specific properties.
Signed-off-by: Alexey Charkov <alchark@gmail.com>
Link: https://lore.kernel.org/r/20250614-sige5-updates-v2-3-3bb31b02623c@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Fix a few issues in the panel section of the PinePhone Pro DTS:
- add the second part of the Himax HX8394 LCD panel controller
compatible
- as proposed by Diederik de Haas, reuse the mipi_out and ports
definitions from rk3399-base.dtsi instead of redefining them
- add a pinctrl for the LCD_RST signal for LCD1, derived from
LCD1_RST, which is on GPIO4_D1, as documented on pages 11
and 16 of the PinePhone Pro schematic
Signed-off-by: Olivier Benjamin <olivier.benjamin@bootlin.com>
Reviewed-by: Diederik de Haas <didi.debian@cknow.org>
Link: https://lore.kernel.org/r/20250619-dtb_fixes-v3-1-9cb02ddd8ce4@bootlin.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree for the Luckfox Omni3576 Carrier Board with Core3576
Module, powered by the Rockchip RK3576 SoC with four Cortex-A72 cores,
four Cortex-A53 cores, and a Mali-G52 MC3 GPU. This initial
implementation enables essential functionality for booting Linux and
basic connectivity.
Supported and tested features:
- UART for serial console
- SD card for storage
- PCIe with NVMe SSD (detected, mounted, and fully functional)
- USB 2.0 host ports
- RK806 PMIC for power management
- RTC with timekeeping and wake-up
- GPIO-controlled LED with heartbeat trigger
- eMMC (enabled, not populated on tested board)
The device tree provides a foundation for further peripheral support, such
as WiFi, MIPI-DSI, HDMI, and Ethernet, in future updates.
Tested on Linux 6.15-rc4
Based on the Luckfox SDK, which derives from Rockchip’s SDK examples, with
relevant changes to align with upstream Linux.
Signed-off-by: John Clark <inindev@gmail.com>
Link: https://lore.kernel.org/r/20250516002713.145026-4-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 GPU power domain cannot be activated unless the external
power regulator is already on. When GPU support was added to this DT,
we had no way to represent this requirement, so `regulator-always-on`
was added to the `vdd_gpu_s0` regulator in order to ensure stability.
A later patch series (see "Fixes:" commit) resolved this shortcoming,
but that commit left the workaround -- and rendered the comment above
it no longer correct.
Remove the workaround to allow the GPU power regulator to power off, now
that the DT includes the necessary information to power it back on
correctly.
Fixes: f94500eb73 ("arm64: dts: rockchip: Add GPU power domain regulator dependency for RK3588")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250608184855.130206-1-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Pine64 touch panel is a panel consisting of the Feiyang fy07024di26a30d
panel with a Goodix gt911 touch screen. Add a device tree overlay to
allow the display to be easily used on the device.
This was previously included in the main device tree but left disabled
by default which still required rebuilding the DT to use the device, now
overlays can go upstream the overlay is the best way to handle the
add on devices.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[added the missing v2 to
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64-v2-screen.dtb
^^
rk3399-rockpro64-v2-screen-dtbs := rk3399-rockpro64-v2.dtb \
rk3399-rockpro64-screen.dtbo
dropped address-cells/size-cells from panel node to fix warning about
rk3399-rockpro64-screen.dtso:69.22-84.4: Warning (avoid_unnecessary_addr_size)
/fragment@2/__overlay__/panel@0: unnecessary #address-cells/#size-cells
without "ranges", "dma-ranges" or child "reg" property]
Link: https://lore.kernel.org/r/20250518215944.178582-2-pbrobinson@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Replace deprecated snps,reset-gpio, snps,reset-active-low, and
snps,reset-delays-us in gmac0 and gmac1 nodes with standard reset-gpios,
reset-assert-us, and reset-deassert-us in rgmii_phy0 and rgmii_phy1 nodes.
Add pinctrl properties to PHY nodes and define gmac0_rst and gmac1_rst in
pinctrl node. Reorder phy-handle for consistency.
Signed-off-by: John Clark <inindev@gmail.com>
Link: https://lore.kernel.org/r/20250520003332.163124-2-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Update the i2c1 bus noting that the unknown/unused device at 0x3c is an
iSmartWare SW2001 "encryption IC".
Based on the documentation I was able to find, this IC appears to be
used to authenticate a device for certain programs to ensure they only
run on authorized devices as a form of digital rights management.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20250604024119.381337-1-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This adds support for the Ethernet Switch adapter connected to the
mezzanine connector on RK3588 Jaguar.
This adapter has a KSZ9896 Ethernet Switch with 4 1GbE Ethernet
connectors, two user controllable LEDs, and an M12 12-pin connector
which exposes the following signals:
- RS232/RS485 (max 250Kbps/500Kbps, RX pin1, TX pin2)
- two digital inputs (pin4 routed to GPIO3_C5 on SoC, pin5 to GPIO4_B4)
- two digital outputs (pin7 routed to GPIO3_D3 on SoC, pin8 to
GPIO3_D1)
- two analog inputs (pin10 to channel1 of ADS1015, pin11 to channel2)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
[Andrew's review for gmac1 and switch@5f parts]
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20250604-jaguar-mezz-eth-switch-v3-1-c68123240f9e@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Pull timer cleanup from Thomas Gleixner:
"The delayed from_timer() API cleanup:
The renaming to the timer_*() namespace was delayed due massive
conflicts against Linux-next. Now that everything is upstream finish
the conversion"
* tag 'timers-cleanups-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
treewide, timers: Rename from_timer() to timer_container_of()
Pull x86 fixes from Thomas Gleixner:
"A small set of x86 fixes:
- Cure IO bitmap inconsistencies
A failed fork cleans up all resources of the newly created thread
via exit_thread(). exit_thread() invokes io_bitmap_exit() which
does the IO bitmap cleanups, which unfortunately assume that the
cleanup is related to the current task, which is obviously bogus.
Make it work correctly
- A lockdep fix in the resctrl code removed the clearing of the
command buffer in two places, which keeps stale error messages
around. Bring them back.
- Remove unused trace events"
* tag 'x86-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
fs/resctrl: Restore the rdt_last_cmd_clear() calls after acquiring rdtgroup_mutex
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
x86/fpu: Remove unused trace events
Pull timer fix from Thomas Gleixner:
"Add the missing seq_file forward declaration in the timer namespace
header"
* tag 'timers-urgent-2025-06-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
timens: Add struct seq_file forward declaration
Add initial DMR support, which required smarter RAPL probe
Fix AMD MSR RAPL energy reporting
Add RAPL power limit configuration output
Minor fixes
Signed-off-by: Len Brown <len.brown@intel.com>
For the RAPL package energy status counter, Intel and AMD share the same
perf_subsys and perf_name, but with different MSR addresses.
Both rapl_counter_arch_infos[0] and rapl_counter_arch_infos[1] are
introduced to describe this counter for different Vendors.
As a result, the perf counter is probed twice, and causes a failure in
in get_rapl_counters() because expected_read_size and actual_read_size
don't match.
Fix the problem by skipping the already probed counter.
Note, this is not a perfect fix. For example, if different
vendors/platforms use the same MSR value for different purpose, the code
can be fooled when it probes a rapl_counter_arch_infos[] entry that does
not belong to the running Vendor/Platform.
In a long run, better to put rapl_counter_arch_infos[] into the
platform_features so that this becomes Vendor/Platform specific.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
platform_features->rapl_msrs describes the RAPL MSRs supported. While
RAPL Perf counters can be exposed from different kernel backend drivers,
e.g. RAPL MSR I/F driver, or RAPL TPMI I/F driver.
Thus, turbostat should first blindly probe all the available RAPL Perf
counters, and falls back to the RAPL MSR counters if they are listed in
platform_features->rapl_msrs.
With this, platforms that don't have RAPL MSRs can clear the
platform_features->rapl_msrs bits and use RAPL Perf counters only.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Increase the code readability by moving the no_perf/no_msr flag and the
cai->perf_name/cai->msr sanity checks into the counter probe functions.
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
probe_rapl_msr() is reused for probing RAPL MSR counters, cstate MSR
counters and MPERF/APERF/SMI MSR counters, thus its name is misleading.
Similar to add_perf_counter(), introduce add_msr_counter() to probe a
counter via MSR. Introduce wrapper function add_rapl_msr_counter() at
the same time to add extra check for Zero return value for specified
RAPL counters.
No functional change intended.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
As the only caller of add_msr_perf_counter_(), add_msr_perf_counter()
just gives extra debug output on top. There is no need to keep both
functions.
Remove add_msr_perf_counter_() and move all the logic to
add_msr_perf_counter().
No functional change.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
