Backport the generic DRM HDMI CEC helpers (drm_hdmi_cec_helper and
drm_hdmi_cec_notifier_helper) along with the drm_connector CEC state,
drm_bridge CEC callbacks, and drm_bridge_connector glue that the
adapter registration path requires. Propagate the HDMI physical
address to the CEC adapter from the HDMI state helper hotplug path.
Implement the CEC adapter in dw-hdmi-qp: register definitions, IRQ
handling, transmit and receive paths, logical address programming,
and enable/disable. Pass the named "cec" IRQ and the HDMI reference
clock rate down from dw_hdmi_qp-rockchip so the timer base is
initialised from the actual reference clock.
Enable CONFIG_DRM_DW_HDMI_QP_CEC in tart_defconfig.
Panthor (Mali-G610 driver) requests mali_csffw.bin at ~1.2s, before /vendor
mounts at ~2.4s. With FW_LOADER_USER_HELPER intentionally disabled, the
firmware request fails instantly and probe fails. Embed the 276KB blob
directly in the kernel Image so firmware is always available at probe time.
Also disable CONFIG_DRM_PANFROST (Midgard/Bifrost driver) — it will never
bind a Valhall G610 GPU and is dead weight alongside panthor.
Copyright (C) 2026 Brendan Szymanski <hello@bscubed.dev>
This device has no module-loading infrastructure, so =m configs are
silently absent at runtime. Missing SOCK_DIAG made every
InetDiagMessage.destroyLiveTcpSockets() call in system_server block
~6s on netlink timeouts (114 times in one 9-minute boot, watchdog-level
main-thread stalls, Settings ANRs, stale IP/status UI). Missing
AF_VSOCK made traced crash-loop every 5s (vsock://-1:2010
EAFNOSUPPORT), tripping updatable_crashing flag resets.
CONFIG_CFG80211_DEFAULT_PS=n: mt7921u with powersave on goes deaf
after association - EAPOL 2/4 is sent, msg 3 never heard, AP deauths
with reason 15 (4-way handshake timeout) - and idle RTT spikes to
100ms+, delaying inbound connections. Always-powered TV box, so
default powersave off is the right trade.
Hypervisor-only vsock transports (VMware/virtio) stay off.
cfg80211 requests regulatory.db once at ~1.3s — before /vendor mounts at
~2.5s — and caches the failure forever (regdb = ERR_PTR in
net/wireless/reg.c), leaving the kernel stuck in the world regulatory
domain: every 5GHz channel PASSIVE-SCAN, TX capped at 20dBm, and no way
to apply the US country code hint from the framework. On a network whose
AP sits on a DFS channel (ch 144 here) the adapter may never actively
probe, causing intermittent scan misses and multi-minute connects. No
runtime recovery is possible without root (NL80211_CMD_RELOAD_REGDB).
Similarly, an mt7921u adapter present at power-on requests its firmware
pre-/vendor, fails, and wastes ~31s in an MCU retry loop ('Failed to get
patch semaphore') before wireless_reprobe.sh can rebind it post-mount.
Embedded firmware is checked before any filesystem path, so both load
deterministically at first probe regardless of partition mount order.
Files live under firmware/ (CONFIG_EXTRA_FIRMWARE_DIR is srctree-relative);
firmware/.gitignore un-ignores them from the root *.bin exclusion. Adds
~890KB to the Image. Other USB adapters still use the reprobe fallback.
The RTL8125BG 2.5GbE controller on the Orange Pi 5 Ultra uses the
r8169 driver. It was configured as a loadable module (=m), but this
device has no module-loading infrastructure (no modules.load, no
vendor_dlkm), so the module was never shipped and Ethernet was dead
on arrival.
Build the driver into the kernel so it probes at boot.
The driver works without its optional PHY firmware at reduced
functionality; the firmware (rtl_nic/rtl8125b-2.fw etc.) is still
shipped in /vendor/firmware/rtl_nic/ for when the post-fs reprobe
path can load it later.
Add proper named constants for the Synaptics SYN43711 (AP6611S)
WiFi chip used on Orange Pi 5 Ultra:
- SDIO_VENDOR_ID_SYNAPTICS (0x06cb) in sdio_ids.h
- SDIO_DEVICE_ID_BROADCOM_CYPRESS_43711 (0xaabf) in sdio_ids.h
- CY_CC_43711_CHIP_ID (43711) in brcm_hw_ids.h
Driver changes:
- bcmsdh.c: bind both Broadcom (0x02d0) and Synaptics (0x06cb) vendors
- chip.c: add RAM base 0x170000 (from bcmdhd CR4_43711_RAM_BASE)
- sdio.c: firmware mapping entry for brcmfmac43711-sdio
The 0x44b0 device ID is the PCIe function ID. The SDIO device
ID for this chip is 0xaabf (BCM43711_CHIP_ID from bcmdhd headers).
Add entries for both Broadcom (0x02d0) and Synaptics (0x06cb)
SDIO vendor IDs since chip ownership transferred during acquisition.
Allow brcmfmac to bind to the Synaptics SYN43711 (AP6611S) SDIO
WiFi chip used on Orange Pi 5 Ultra. The chip ID will be logged
on first boot so the firmware mapping entry can be added.
- Add rockchip_wlan Kconfig include to drivers/net/wireless/Kconfig
(the Makefile already has the build rule under CONFIG_WL_ROCKCHIP)
- Set CONFIG_WL_ROCKCHIP=y in tart_defconfig to enable bcmdhd build
Define FW_AMPAK_PATH as vendor/firmware/brcm so the driver's
dhd_conf_add_filepath constructs the correct absolute firmware
path /vendor/firmware/brcm/fw_<chip>.bin.
Shifting common code between rkvdec-vp9.c and rkvdec-vdpu381-vp9.c to rkvdec-vp9-common.c
There is still some more common code which needs to be shifted, but still working on it.
The regulator vcc5v0_otg is always on and is on when the kernel boots. THe vin-supply of the regulator is vcc5v0_usb but vcc5v0_usb is connected to vcc5v0_sys, which is always
on boot(refer to documentation). Hence, this regulator should be on at boot and adding these lines, made the USB 3.0 port work for Orange pi 5 pro, which was missing from the beginning.
This node is connected to the m.2 slot found in orange pi 5 pro and certain pins are connected to the gpio, like PCIE20x1_1_PERSTn_M1, PCIE20x1_1_CLKREQn_M1 and PCIE20x1_1_WAKEn_M1.
In absence of these gpio definitions, would cause nvme to be recognised but if it went to sleep, there is no way for them to be waken up. Hence, Adding this resolved the issue -
[ 35.812749] Bluetooth: hci0: BCM: features 0x0f
[ 35.814580] Bluetooth: hci0: BCM4345C5 Ampak_CL1 UART 37.4 MHz BT 5.0 [Version: Version: 0039.0089]
[ 35.815374] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0089
[ 45.335521] platform bridge: deferred probe pending: (reason unknown)
[ 66.658318] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS read failed (134)
[ 66.659131] nvme nvme0: Does your device have a faulty power saving mode enabled?
[ 66.659784] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
[ 69.009422] nvme0n1: I/O Cmd(0x2) @ LBA 7385088, 32 blocks, I/O Error (sct 0x3 / sc 0x71)
[ 69.010143] I/O error, dev nvme0n1, sector 7385088 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[ 69.047131] nvme 0003:31:00.0: Unable to change power state from D3cold to D0, device inaccessible
[ 69.099121] nvme nvme0: Disabling device after reset failure: -19
[ 69.123144] Buffer I/O error on dev nvme0n1p4, logical block 0, async page read
[ 69.123817] init: [libfs_mgr] Can't read '/dev/block/by-name/metadata' superblock: I/O error
[ 69.124672] EXT4-fs (nvme0n1p4): unable to read superblock
[ 69.125197] init: [libfs_mgr] __mount(source=/dev/block/by-name/metadata,target=/metadata,type=ext4)=-1: I/O error
[ 69.126120] init: DSU not detected, proceeding with normal boot
[ 69.126684] Buffer I/O error on dev nvme0n1p2, logical block 0, async page read
[ 69.127342] init: [libfs_mgr] Can't read '/dev/block/by-name/system' superblock: I/O error
[ 69.128100] EXT4-fs (nvme0n1p2): unable to read superblock
[ 69.128596] init: [libfs_mgr] __mount(source=/dev/block/by-name/system,target=/system,type=ext4)=-1: I/O error
[ 69.129465] init: Failed to mount /system: I/O error [ 69.129932] init: Failed to mount required partitions early ...
[ 69.130669] init: InitFatalReboot: signal 6
[ 69.135720] init: #00 pc 00000000003cf510 /init (unwindstack::AndroidLocalUnwinder::InternalUnwind(std::__1::optional<int>, unwindstack::AndroidUnwinderData&)+116) (BuildId: 2a2f03a3b9ebbb40bcce7295bfedf748)
[ 69.137346] init: #01 pc 00000000003c96f4 /init (android::init::InitFatalReboot(int)+204) (BuildId: 2a2f03a3b9ebbb40bcce7295bfedf748)
[ 69.198289] kvm: exiting hardware virtualization
[ 69.198796] reboot: Restarting system with command 'bootloader'
Date: Thu, 17 Apr 2025 08:35:09 +0800 [thread overview]
Message-ID: <1744850111-236269-1-git-send-email-shawn.lin@rock-chips.com> (raw)
Two mistakes here:
1. 0x11 is L0 not L0S, so the naming is wrong from the very beginning.
2. It's totally broken if enabling ASPM as rockchip_pcie_link_up() treat
other states, for instance, L0S or L1 as link down which is obviously
wrong.
Remove the check.
Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver")
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Due to a mistake, Kernel sets the PCI port to Endpoint mode and wouldn't detect nvme drives. With this correction, removes the PCI endpoint config and replaces it with HOST mode only config.
Intial tests are working, detecting the NVME drive but for some NVME drives due to APST and PCIe ASPM/port PM, would not be detected or cause issues.
In some application scenarios, we hope to get the corresponding
connector when the bridge's detect hook is invoked.
In most cases, we can get the connector by drm_atomic_get_connector_for_encoder
if the encoder attached to the bridge is enabled, however there will
still be some scenarios where the detect hook of the bridge is called
but the corresponding encoder has not been enabled yet. For instance,
this occurs when the device is hot plug in for the first time.
Since the call to bridge's detect is initiated by the connector, passing
down the corresponding connector directly will make things simpler.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250703125027.311109-3-andyshrk@163.com
[DB: added the chunk to the cdn-dp driver]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Date: Wed, 03 Dec 2025 20:27:55 +0200 [thread overview]
Message-ID: <20251203-dw-hdmi-qp-scramb-v1-4-836fe7401a69@collabora.com> (raw)
In-Reply-To: <20251203-dw-hdmi-qp-scramb-v1-0-836fe7401a69@collabora.com>
In order to optimize the HPD event handling and run the detect cycle on
the affected connector only, make use of
drm_connector_helper_hpd_irq_event() instead of
drm_helper_hpd_irq_event().
Additionally, move devm_request_threaded_irq() after bridge connector
initialization.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed, 03 Dec 2025 20:27:54 +0200 [thread overview]
Message-ID: <20251203-dw-hdmi-qp-scramb-v1-3-836fe7401a69@collabora.com> (raw)
In-Reply-To: <20251203-dw-hdmi-qp-scramb-v1-0-836fe7401a69@collabora.com>
Add support for HDMI 2.0 display modes, e.g. 4K@60Hz, by permitting TMDS
character rates above the 340 MHz limit of HDMI 1.4b.
Hence, provide the required SCDC management, including the high TMDS
clock ratio and scrambling setup, and filter out the HDMI 2.1 modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
In preparation to allow bridge drivers relying on the HDMI connector
framework to provide HDMI 2.0 support, make use of the atomic version of
drm_connector_funcs.detect() hook and invoke the newly introduced
drm_bridge_detect_ctx() helper.
In particular, this is going to be used for triggering an empty modeset
in drm_bridge_funcs.detect_ctx() callback, in order to manage SCDC
status lost on sink disconnects.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date: Wed, 03 Dec 2025 20:27:52 +0200 [thread overview]
Message-ID: <20251203-dw-hdmi-qp-scramb-v1-1-836fe7401a69@collabora.com> (raw)
In-Reply-To: <20251203-dw-hdmi-qp-scramb-v1-0-836fe7401a69@collabora.com>
Add an atomic variant of the ->detect callback and a new helper to call
the hook while passing an optional drm_modeset_acquire_ctx reference.
When both ->detect_ctx and ->detect are defined, the latter is ignored.
If acquire_ctx is unset, the function takes care of the locking,
while also handling EDEADLK.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
commit 3776c685ebe5f43e9060af06872661de55e80b9a upstream.
Currently, whenever there is a need to transmit an Action frame,
the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to
firmware. The P2P interfaces were available when wpa_supplicant is managing
the wlan interface.
However, the P2P interfaces are not created/initialized when only hostapd
is managing the wlan interface. And if hostapd receives an ANQP Query REQ
Action frame even from an un-associated STA, the brcmfmac driver tries
to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.
This NULL pointer dereferencing triggers a driver crash.
[ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual
address 0000000000000000
[...]
[ 1417.075653] Call trace:
[ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]
[ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]
[ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]
[ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211]
[ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158
[ 1417.076302] genl_rcv_msg+0x220/0x2a0
[ 1417.076317] netlink_rcv_skb+0x68/0x140
[ 1417.076330] genl_rcv+0x40/0x60
[ 1417.076343] netlink_unicast+0x330/0x3b8
[ 1417.076357] netlink_sendmsg+0x19c/0x3f8
[ 1417.076370] __sock_sendmsg+0x64/0xc0
[ 1417.076391] ____sys_sendmsg+0x268/0x2a0
[ 1417.076408] ___sys_sendmsg+0xb8/0x118
[ 1417.076427] __sys_sendmsg+0x90/0xf8
[ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40
[ 1417.076465] invoke_syscall+0x50/0x120
[ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0
[ 1417.076506] do_el0_svc+0x24/0x38
[ 1417.076525] el0_svc+0x30/0x100
[ 1417.076548] el0t_64_sync_handler+0x100/0x130
[ 1417.076569] el0t_64_sync+0x190/0x198
[ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)
Fix this, by always using the vif corresponding to the wdev on which the
Action frame Transmission request was initiated by the userspace. This way,
even if P2P vif is not available, the IOVAR is sent to firmware on AP vif
and the ANQP Query RESP Action frame is transmitted without crashing the
driver.
Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()
to brcmf_p2p_attach(). Because the former function would not get executed
when only hostapd is managing wlan interface, and it is not safe to do
reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior
init_completion().
And in the brcmf_p2p_tx_action_frame() function, the condition check for
P2P Presence response frame is not needed, since the wpa_supplicant is
properly sending the P2P Presense Response frame on the P2P-GO vif instead
of the P2P-Device vif.
Cc: stable@vger.kernel.org
Fixes: 18e2f61 ("brcmfmac: P2P action frame tx")
Signed-off-by: Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20251013102819.9727-1-gokulkumar.sivakumar@infineon.com
[Cc stable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
with dp to hdmi converter bridge present. By enabling this, we can use the 2nd hdmi as a secondary display for AOSP(or even primary if first hdmi port is not used).
This commit introduces vp9 hardware decoder present in vdpu381 on RK3588. Current testing shows that this can play until 4k@30fps - profile 0. Tested using various vp9 based videos and youtube. This is still in development phase and not production ready.
These modifications are from Detlev Casanova from collabora, who is currently developing HW stateless video decoders drivers for rk3588 and rk3576 SoC's . Using his patch for linux and ffmpeg using v4l2 requests and my patches for ffmpeg_codec2, I was able to get 4k@25 fps - 8-bit, running( HEVC and h.264) but still yet to optimise it and need to add hw decoders for vp9, av1, vp8 etc. NOTE - This is a testing build and might cause kernel panics.
