QCS6490 family & radxa-dragon-q6a improvements #9289
Conversation
📝 WalkthroughWalkthroughThis PR introduces comprehensive Linux 6.18 kernel support for QCOM QCS6490 and related platforms, spanning 121 patches. It enables Radxa Dragon Q6A board support with device tree changes, updates device drivers for USB 3.0/HDMI connectivity, implements remoteproc improvements for attach/restart behavior, adds PCIe/USB-C enhancements, and includes miscellaneous driver fixes and optimizations across crypto, media, DRM, and power management subsystems. Changes
Estimated code review effort🎯 5 (Critical) | ⏱️ ~120+ minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
bot
added
02
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
patch/kernel/archive/qcs6490-6.18/0046-drm-panel-Add-support-for-Orise-Tech-OTA7290B-DSI-Pa.patch (1)
201-226: Inconsistent physical dimensions between display mode and panel descriptor.The
drm_display_modestruct defineswidth_mm = 135andheight_mm = 217(lines 212-213), while thepanel_descuseswidth_mm = 74andheight_mm = 131(lines 220-221). Theget_modesfunction uses thepanel_descvalues for the connector's display info.For a "10FHD" (10-inch Full HD) panel, the dimensions 135×217mm are more plausible. The current 74×131mm values suggest a ~6-inch display instead.
Suggested fix if 135×217mm is correct
static const struct panel_desc radxa_display_10fhd_ad003_desc = { .display_mode = &radxa_display_10fhd_ad003_1200x1920, - .width_mm = 74, - .height_mm = 131, + .width_mm = 135, + .height_mm = 217, .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST | MIPI_DSI_MODE_NO_EOT_PACKET,patch/kernel/archive/qcs6490-6.18/0047-arm64-dts-qcom-sc7280-Add-cci-aliases.patch (1)
19-22: Copy-paste error:i2c19alias points to wrong CCI I2C controller.Line 22 assigns
i2c19to&cci1_i2c0, but based on the naming pattern, it should reference&cci1_i2c1:
Alias Expected Target i2c16 cci0_i2c0 ✓ i2c17 cci0_i2c1 ✓ i2c18 cci1_i2c0 ✓ i2c19 cci1_i2c1 ✗ Currently, both
i2c18andi2c19alias to the samecci1_i2c0controller, which would causecci1_i2c1to be inaccessible via the alias mechanism.🐛 Proposed fix
i2c16 = &cci0_i2c0; i2c17 = &cci0_i2c1; i2c18 = &cci1_i2c0; - i2c19 = &cci1_i2c0; + i2c19 = &cci1_i2c1;
🤖 Fix all issues with AI agents
In
`@patch/kernel/archive/qcs6490-6.18/0040-crypto-qce-Add-runtime-PM-and-interconnect-bandwidth.patch`:
- Around line 104-127: Revert the replacement of optional clock handling with
pm_clk_add for "iface" and "bus": use devm_clk_get_optional (or
devm_clk_get_optional_enabled if you need it enabled) to fetch qce->iface and
qce->bus, check IS_ERR and return PTR_ERR on error, then only call
pm_clk_add_clk (or pm_clk_add_clk equivalent) when the returned clk is non-NULL
and handle its return value; update the probe code paths around qce->iface and
qce->bus to match this pattern so platforms missing these optional clocks
continue to probe successfully.
In
`@patch/kernel/archive/qcs6490-6.18/0066-spi-geni-qcom-rework-setup_fifo_params.patch`:
- Around line 60-77: The code incorrectly tests mode_changed against
register-offset constants SE_SPI_CPHA/SE_SPI_CPOL instead of the SPI mode bit
masks, so CPHA/CPOL updates never trigger; change the two conditionals that read
"if (mode_changed & SE_SPI_CPHA)" and "if (mode_changed & SE_SPI_CPOL)" to test
against the SPI mode masks "SPI_CPHA" and "SPI_CPOL" respectively (keep the
write logic using SE_SPI_CPHA/SE_SPI_CPOL offsets and the existing writes that
use spi_slv->mode to decide CPHA/CPOL). Ensure you reference the variables
mode_changed, spi_slv->mode and the constants SPI_CPHA/SPI_CPOL in the patch.
In
`@patch/kernel/archive/qcs6490-6.18/0071-r8169-Remove-the-check-of-a-register-to-enable-ASPM-.patch`:
- Around line 23-26: The patch removes the r8168_mac_ocp_read(0xc0b2) register
gate and enables ASPM for all devices with tp->mac_version >=
RTL_GIGA_MAC_VER_46; restore vendor scoping by either reintroducing the original
register check (r8168_mac_ocp_read(tp, 0xc0b2) & 0xf) or add a device-specific
quirk/filter that checks the PCI subsystem/device ID or a device-tree compatible
string (e.g., Radxa Dragon Q6A) before returning true so only the intended
hardware (not all RTL_GIGA_MAC_VER_46 devices) enables ASPM.
In
`@patch/kernel/archive/qcs6490-6.18/0072-media-venus-Workaround-10-bit-decoding-and-performan.patch`:
- Around line 41-46: The commented-out QC10C validation in find_format and
find_format_by_index (the checks comparing fmt[i].pixfmt == V4L2_PIX_FMT_QC10C
and inst->bit_depth == VIDC_BITDEPTH_10) must be resolved: either remove the
commented lines entirely and add a brief commit message explaining the
workaround rationale, or reintroduce active validation with explicit logic
(e.g., skip the check until inst->bit_depth is initialized or return NULL when
bit depth != 10) and add an in-code comment explaining why the bypass is safe;
update the functions find_format and find_format_by_index accordingly and ensure
any deferred-validation path is clearly documented in the code comment
referencing inst->bit_depth and V4L2_PIX_FMT_QC10C.
- Around line 17-30: Define or replace the undefined VENUS_MAX_FPS and reconcile
the decide_core fallback behavior: either add a local definition for
VENUS_MAX_FPS (e.g. match upstream value like 240) or replace uses of
VENUS_MAX_FPS with an explicit literal, and in decide_core() fix the log and
behavior to be consistent by removing commented-out lines, ensuring the dev_warn
message matches the actual actions (if enabling power save via
power_save_mode_enable(inst, true) then log that we're falling back to
power-save/minimal operation; if instead you intend to force max performance
clear the power-save call and set
inst->clk_data.core_id/cu.video_core_enable_mask accordingly) so that
dev_warn(core->dev, ...), inst->clk_data.core_id, cu.video_core_enable_mask and
power_save_mode_enable() all reflect the same intent.
In
`@patch/kernel/archive/qcs6490-6.18/0084-soc-qcom-ice-Add-HWKM-v1-support-for-wrapped-keys.patch`:
- Around line 177-185: The exported functions qcom_ice_generate_key,
qcom_ice_prepare_key, and qcom_ice_import_key now use
QCOM_ICE_HWKM_WRAPPED_KEY_SIZE(ice->hwkm_version) but do not guard against
unsupported HWKM on callers; add a runtime check at the top of each function
(e.g. if (!ice->use_hwkm || ice->hwkm_version == 0) return -ENODEV or
-EOPNOTSUPP) to fail fast for SoCs without HWKM support, or alternatively
document in each exported function header that callers must verify ice->use_hwkm
is true before calling; update all three functions (qcom_ice_generate_key,
qcom_ice_prepare_key, qcom_ice_import_key) to use this guard.
In
`@patch/kernel/archive/qcs6490-6.18/0091-drm-panel-jd9365da-h3-add-enable-callback.patch`:
- Around line 19-53: The init() call was moved into jadard_enable(), breaking
the required sequence; revert that by removing the jadard->desc->init(jadard)
call from jadard_enable() (or delete jadard_enable entirely) and ensure
jadard->desc->init(jadard) is called in jadard_prepare() immediately after the
hardware reset sequence (the gpiod_set_value(jadard->reset, 0); msleep(130);
lines). Also remove the .enable = jadard_enable entry from the jadard_funcs
table (or leave .enable NULL) so init() is only invoked from jadard_prepare()
following reset.
In
`@patch/kernel/archive/qcs6490-6.18/0098-arm64-dts-meson-radxa-zero2-enable-the-npu-node.patch`:
- Around line 1-12: The patch 0098 (arm64 dts: meson: radxa-zero2: enable the
npu node) is misplaced in the qcs6490-6.18 archive and duplicates an existing
patch in the meson64-6.18 archive; remove this duplicate from the qcs6490-6.18
series (delete or exclude patch 0098 from that directory) and ensure the single
authoritative patch remains in the meson64-6.18 series (the file named
board-radxa-zero2-arm64-dts-amlogic-Enable-the-npu-node-for-Radxa-Zero2.patch),
update the series/index so it references only the meson64 location, and
check/remove other similarly misplaced Radxa Zero 2 patches (0095, 0097, 0113,
0117, 0118, 0120, 0121) from the qcs6490-6.18 directory to avoid duplicates.
In
`@patch/kernel/archive/qcs6490-6.18/0099-arm64-dts-meson-g12a-modify-cpu-opp-voltage-value.patch`:
- Around line 1-13: The patch modifies
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi (CPU OPP voltage values) but is
incorrectly placed under the qcs6490-6.18 patch series; move this patch file
into the meson64-6.18 directory so Amlogic Meson SoC changes are grouped
correctly. Update the patch metadata (subject/series location) if needed so the
patch applies in the meson64-6.18 queue and remove it from qcs6490-6.18; ensure
the patch filename and the referenced target (meson-g12a.dtsi) remain unchanged
and that any series index/order is adjusted to match other meson64-6.18 patches.
In
`@patch/kernel/archive/qcs6490-6.18/0104-drm-msm-dpu-Check-mode-against-PINGPONG-or-DSC-max-w.patch`:
- Around line 32-55: The helper msm_display_get_max_pingpong_width can return 0
if any pingpong->max_linewidth is zero, causing all modes to be rejected; update
it to ignore zero max_linewidth entries and fall back to a sane default:
initialize max_pingpong_width from dpu_kms->caps->max_mixer_width (or use it if
no non-zero pingpong widths are found), and when iterating over
dpu_kms->catalog->pingpong[i] only consider pingpong->max_linewidth values > 0
when computing the minimum; ensure the function returns the fallback
caps->max_mixer_width if all pingpong entries are zero.
In
`@patch/kernel/archive/qcs6490-6.18/0109-arm64-dts-meson-radxa-zero-add-USB-Type-C-support-vi.patch`:
- Around line 79-89: The &dwc3 node uses an incorrect container name "ports";
change it to a single "port" node so the endpoint child nodes (usb_dwc2_out:
endpoint@0 and usb_dwc3_out: endpoint@1) attach correctly to &dwc3 and follow
the OF-graph binding; update the block around &dwc3 to replace "ports { ... }"
with "port { ... }" while keeping the remote-endpoint references to &ucsi0_hs_in
and &ucsi0_ss_in unchanged.
In
`@patch/kernel/archive/qcs6490-6.18/0111-drm-edid-add-device-tree-quirk-flags-supports.patch`:
- Around line 38-56: The connector_get_quirks() function uses
EDID_QUIRK_PREFER_LARGE_60 and EDID_QUIRK_PREFER_LARGE_75 but those enum members
are missing; add EDID_QUIRK_PREFER_LARGE_60 and EDID_QUIRK_PREFER_LARGE_75 to
the enum drm_edid_internal_quirk so BIT(EDID_QUIRK_PREFER_LARGE_60) and
BIT(EDID_QUIRK_PREFER_LARGE_75) compile correctly, keeping them alongside
CONNECTOR_QUIRK_PREFER_FHD and preserving the intended bit positions.
In
`@patch/kernel/archive/qcs6490-6.18/0119-arm64-dts-amlogic-meson-g12b-add-missing-PWM-pinctrl.patch`:
- Around line 1-16: The patch
"0119-arm64-dts-amlogic-meson-g12b-add-missing-PWM-pinctrl.patch" was committed
into the Qualcomm archive (qcs6490-6.18) but belongs in the Amlogic archive;
move that patch file from the qcs6490-6.18 patch archive into the meson64-6.18
patch archive, preserve the original commit/author/Signed-off-by metadata, and
update any patch series/index (or quilt/mbox list) references so the patch is
applied with the other meson-g12b/meson64 patches.
🟡 Minor comments (8)
patch/kernel/archive/qcs6490-6.18/0061-mtd-devices-Add-Qualcomm-SCM-storage-driver.patch-276-276 (1)
276-276: Potential integer overflow in size calculation.If
total_blocksandblock_sizeare both 32-bit types, this multiplication will be performed in 32-bit arithmetic before assignment to the 64-bitmtd.size, potentially causing overflow for large flash devices.🔧 Suggested fix
- host->mtd.size = host->info.total_blocks * host->info.block_size; + host->mtd.size = (u64)host->info.total_blocks * host->info.block_size;patch/kernel/archive/qcs6490-6.18/0061-mtd-devices-Add-Qualcomm-SCM-storage-driver.patch-73-77 (1)
73-77: Remove unused#include <linux/dma-mapping.h>header.The
dma-mapping.hheader is included but no DMA mapping functions are used in this driver. The SCM layer (qcom_scm_storage_send_cmd) internally allocates and manages its own TrustZone-protected memory pool viaqcom_tzmem_alloc, copying the caller's buffer as needed. The bounce buffer allocated at line 252 withdevm_kzalloc(dev, host->buffer_size, GFP_KERNEL)is correct and does not require DMA-coherent memory. Remove the unused include.patch/kernel/archive/qcs6490-6.18/0052-arm64-dts-qcom-sc7280-Describe-the-MBI-functionality.patch-38-45 (1)
38-45: Add#msi-cells = <1>;for GICv3 MSI controller compliance.When marking the GIC node as an MSI controller via
msi-controller, the kernel'sarm,gic-v3.yamlbinding requires the#msi-cellsproperty. This property defines the cell size for MSI device IDs and must be present to satisfydtbs_checkvalidation.Required property addition
mbi-alias = <0x0 0x17a10000>; mbi-ranges = <832 128>; msi-controller; + `#msi-cells` = <1>; `#interrupt-cells` = <3>;patch/kernel/archive/qcs6490-6.18/0107-usb-typec-tcpm-support-skipping-VSafe0V-check.patch-41-52 (1)
41-52: Add binding documentation for thetcpm,skip-vsafe0v-checkproperty.Patch 0107 introduces driver code that consumes the
tcpm,skip-vsafe0v-checkdevice property, and patches 0109 and 0113 use it in device trees. This property should be documented in the TCPM device tree binding YAML file to ensure DT schema validation and maintain consistency with kernel binding definitions.patch/kernel/archive/qcs6490-6.18/0001-dt-bindings-phy-qcom-sc8280xp-qmp-usb43dp-phy-Docume.patch-64-90 (1)
64-90: Fix data-lanes constraints for DisplayPort endpoint to match oneOf enumeration.The endpoint@0
data-lanesproperty declaresminItems: 2but includes oneOf branches for 1-lane DisplayPort configurations (single-element arrays). This constraint mismatch will cause dt-schema validation failures for valid 1-lane configurations. ChangeminItemsto 1 for the DisplayPort endpoint, or remove the 1-lane options if they are not actually supported.patch/kernel/archive/qcs6490-6.18/0011-remoteproc-core-Allow-restarting-detached-remoteproc.patch-214-214 (1)
214-214: Typo in comment: "avilable" → "available"- /* Check early if we have firmware avilable if needed */ + /* Check early if we have firmware available if needed */patch/kernel/archive/qcs6490-6.18/0011-remoteproc-core-Allow-restarting-detached-remoteproc.patch-343-350 (1)
343-350: Documentation comment uses wrong enum name.The comment references
RPROC_FEAT_REBOOT_IF_FW_AVAILABLEbut the actual enum value defined at line 355 isRPROC_AUTO_BOOT_RESTART_IF_FW_AVAILABLE. This mismatch could cause confusion.Proposed fix
- * `@RPROC_FEAT_REBOOT_IF_FW_AVAILABLE`: The remoteproc will be restarted if + * `@RPROC_AUTO_BOOT_RESTART_IF_FW_AVAILABLE`: The remoteproc will be restarted ifpatch/kernel/archive/qcs6490-6.18/0027-hack-soc-qcom-pmic_glink-Avoid-platform-rpmsg-probe-.patch-35-47 (1)
35-47: Add guard or document single-instance requirement for rpmsg driver registration.The patch registers the rpmsg driver in
pmic_glink_probe(), which will fail with-EBUSY/-EEXISTif multiple PMIC GLINK platform devices probe (sinceregister_rpmsg_driver()cannot be called twice for the same driver name). Either add a flag to ensure registration happens once, or explicitly document that the DT/SoC guarantees a single instance and will not change.
🧹 Nitpick comments (14)
patch/kernel/archive/qcs6490-6.18/0035-scripts-Add-PKGBUILD-for-testing-on-Arch-Linux-ARM.patch (1)
120-124: Inconsistent indentation in dtbs_install block.Line 123 uses spaces while line 122 uses a tab. While this won't break functionality, it's inconsistent within the same code block.
🔧 Suggested fix for consistency
if [ -d "${srctree}/arch/${SRCARCH}/boot/dts" ]; then echo "Installing dtbs..." ${MAKE} INSTALL_DTBS_PATH="${modulesdir}/dtb" dtbs_install - ${MAKE} INSTALL_DTBS_PATH="${pkgdir}/boot/dtb" dtbs_install + ${MAKE} INSTALL_DTBS_PATH="${pkgdir}/boot/dtb" dtbs_install fipatch/kernel/archive/qcs6490-6.18/0060-firmware-qcom-scm-Add-SCM-storage-interface-support.patch (1)
121-139: Payload copy-back occurs before result validation.The payload is copied back to the caller at lines 121-122 before checking
scm_res.result[0]. On failed storage operations (e.g.,ACCESS_DENIED,STORAGE_ERROR), this could copy potentially invalid or partial data back to the caller.Consider moving the copy-back inside the
STORAGE_RESULT_SUCCESScase:♻️ Proposed fix
if (ret) return ret; - if (payload) - memcpy(payload, payload_buf, size); - switch (scm_res.result[0]) { case STORAGE_RESULT_SUCCESS: + if (payload) + memcpy(payload, payload_buf, size); return 0; case STORAGE_RESULT_NO_MEMORY:patch/kernel/archive/qcs6490-6.18/0068-WIP-change-reserved-mem-layout-for-WP.patch (1)
1-6: WIP patch included in the series — consider finalizing before merge.The patch subject indicates "WIP" (Work-In-Progress) status. Given the PR description confirms successful boot testing with the new BIOS snapshot (
dragon-q6a_flat_build_wp_260120) and verified functionality (desktop, Wi-Fi, media playback, audio), this appears production-ready despite the label.Consider removing the "WIP:" prefix from the commit subject if no further changes are expected, to avoid confusion in the patch history.
patch/kernel/archive/qcs6490-6.18/0099-arm64-dts-meson-g12a-modify-cpu-opp-voltage-value.patch (1)
6-8: Reference points to an old vendor kernel from 2020.The reference
amlogic-4.9-20is a vendor kernel based on Linux 4.9. Consider verifying these voltage values against more recent upstream sources or confirming this aligns with current mainline recommendations for Meson G12A.patch/kernel/archive/qcs6490-6.18/0023-wip-remoteproc-qcom_q6v5_pas-Avoid-using-broken-rese.patch (1)
83-88: Early exit returns success despite non-functional driver.When reset is broken and remoteproc isn't running, the driver exits with
ret = 0to avoid blockingsync_state(). While the comment explains the rationale, returning success for a non-functional probe could mask issues in system integration. Consider whether a distinct return code or logging at a higher severity would help operators identify misconfigured systems.patch/kernel/archive/qcs6490-6.18/0040-crypto-qce-Add-runtime-PM-and-interconnect-bandwidth.patch (1)
191-209: Unnecessary initialization on line 195.The variable
retis initialized to 0 but immediately overwritten byicc_enable()on line 196. This is a minor style nit—can be simplified toint ret;.🔧 Optional cleanup
static int __maybe_unused qce_runtime_resume(struct device *dev) { struct qce_device *qce = dev_get_drvdata(dev); - int ret = 0; + int ret; ret = icc_enable(qce->mem_path);patch/kernel/archive/qcs6490-6.18/0094-arm64-dts-amlogic-enable-device-tree-overlay-support.patch (1)
22-27: Consider using+=instead of:=for DTC_FLAGS.Using
:=will override any DTC_FLAGS that might be set earlier in the build chain. While this typically works fine, using+=is a safer pattern that preserves any global flags:-DTC_FLAGS := -@ +DTC_FLAGS += -@This aligns with patterns used in other arch DT Makefiles that append to DTC_FLAGS rather than replacing them.
patch/kernel/archive/qcs6490-6.18/0088-drm-msm-dp-Filter-out-certain-modes-to-avoid-instabi.patch (1)
31-33: Consider adding a comment explaining the hardware limitation.The magic numbers (3440×1440, 30Hz) would benefit from a brief inline comment explaining why this specific threshold was chosen. This helps future maintainers understand the hardware constraint:
+ /* QCS6490 DP has stability issues above 3440x1440 at >30Hz refresh rates */ if ((mode->hdisplay * mode->vdisplay > 3440 * 1440) && vrefresh > 30) return MODE_BAD;The logic itself is correct—modes at exactly 3440×1440 or at 30Hz and below remain valid.
patch/kernel/archive/qcs6490-6.18/0121-arm64-dts-meson-radxa-zero-series-enhance-WiFi-SDIO-.patch (1)
29-42: Zero2 lackssd-uhs-sdr50while Zero has it—consider adding for consistency.The patch shows Zero (g12a) already has
sd-uhs-sdr50defined before addingsd-uhs-sdr104, but Zero2 (g12b) does not. While the patch successfully enables SDR104 for both devices and testing confirms WiFi works, addingsd-uhs-sdr50to Zero2 would align the configurations and reflect the full UHS mode hierarchy.patch/kernel/archive/qcs6490-6.18/0000.patching_config.yaml (1)
3-8: Consider removing the unused “info stuff” metadata block to reduce churn.
The comment already states it is not used by patching scripts, so trimming it keeps future rebases cleaner.Based on learnings, remove unused metadata rather than updating it.♻️ Proposed cleanup
- # Just some info stuff; not used by the patching scripts - name: qcs6490-6.18 - kind: kernel - type: mainline # or: vendor - branch: linux-6.18.y - last-known-good-tag: v6.18.2patch/kernel/archive/qcs6490-6.18/0108-usb-typec-fusb302-workaround-for-fixed-VBUS-hardware.patch (1)
53-58: DT property binding may need documentation.The
fcs,force-vbus-toggleproperty follows the correct vendor prefix convention. Consider whether a dt-bindings documentation update is needed for upstream acceptance, though this may be deferred for Armbian's vendor patch context.config/boards/radxa-dragon-q6a.conf (1)
33-52: Add checksum verification and error handling for external package download.The function downloads a
.debfrom an external URL without verifying its integrity. This introduces potential security and reliability issues:
- No checksum verification: A compromised or corrupted package could be installed.
- No download error handling: If
wgetfails,dpkg -iwill fail on a missing/incomplete file.- Hardcoded version: May become stale as Radxa releases updates.
♻️ Suggested improvements
function post_family_tweaks__radxa-dragon-q6a_install_alsa_ucm_conf() { # Only install for kernel 6.18.x if [[ "${KERNEL_MAJOR_MINOR}" == "6.18" ]]; then display_alert "Installing alsa-ucm-conf" "${BOARD}: Radxa ALSA UCM configuration" "info" declare alsa_ucm_url="https://github.com/radxa-pkg/alsa-ucm-conf/releases/download/1.2.14-1radxa2/alsa-ucm-conf_1.2.14-1radxa2_all.deb" declare alsa_ucm_deb="/tmp/alsa-ucm-conf_1.2.14-1radxa2_all.deb" + declare alsa_ucm_sha256="<insert_expected_sha256_here>" # Download the package - run_host_command_logged wget -O "${SDCARD}${alsa_ucm_deb}" "${alsa_ucm_url}" + if ! run_host_command_logged wget -q -O "${SDCARD}${alsa_ucm_deb}" "${alsa_ucm_url}"; then + display_alert "Failed to download alsa-ucm-conf" "${alsa_ucm_url}" "warn" + return 0 + fi + + # Verify checksum + if ! echo "${alsa_ucm_sha256} ${SDCARD}${alsa_ucm_deb}" | sha256sum -c - > /dev/null 2>&1; then + display_alert "Checksum verification failed" "alsa-ucm-conf" "warn" + rm -f "${SDCARD}${alsa_ucm_deb}" + return 0 + fi # Install in chroot chroot_sdcard dpkg -i "${alsa_ucm_deb}"patch/kernel/archive/qcs6490-6.18/0070-arm64-configs-Import-qcom_module_defconfig-from-drag.patch (1)
2221-2237: Consider moving debug-heavy options to a debug-only defconfig.This defconfig enables DEBUG_KERNEL, DYNAMIC_DEBUG, MAGIC_SYSRQ, KFENCE, and related tracing options. If this defconfig feeds production images, these add overhead and expand the debug surface; if it’s dev-only, all good—otherwise consider splitting or disabling them.
patch/kernel/archive/qcs6490-6.18/0029-rpmsg-core-Make-it-easier-to-manually-create-endpoin.patch (1)
65-88: Consider a defensive guard against double-open.If a driver calls
rpmsg_dev_open_ept()twice, the previous endpoint is leaked andrpdev->eptis overwritten. AWARN_ON/early return makes misuse explicit.♻️ Suggested guard
struct rpmsg_endpoint *rpmsg_dev_open_ept(struct rpmsg_device *rpdev, rpmsg_rx_cb_t cb, void *priv) { struct rpmsg_driver *rpdrv = to_rpmsg_driver(rpdev->dev.driver); + if (WARN_ON(rpdev->ept)) + return NULL; struct rpmsg_channel_info chinfo = { .src = rpdev->src, .dst = RPMSG_ADDR_ANY, };
| + /* PM clock helpers: register device clocks */ | ||
| + ret = devm_pm_clk_create(dev); | ||
| + if (ret) | ||
| + return ret; | ||
|
|
||
| - qce->iface = devm_clk_get_optional_enabled(qce->dev, "iface"); | ||
| - if (IS_ERR(qce->iface)) | ||
| - return PTR_ERR(qce->iface); | ||
| + ret = pm_clk_add(dev, "core"); | ||
| + if (ret) | ||
| + return ret; | ||
|
|
||
| - qce->bus = devm_clk_get_optional_enabled(qce->dev, "bus"); | ||
| - if (IS_ERR(qce->bus)) | ||
| - return PTR_ERR(qce->bus); | ||
| + ret = pm_clk_add(dev, "iface"); | ||
| + if (ret) | ||
| + return ret; | ||
|
|
||
| - qce->mem_path = devm_of_icc_get(qce->dev, "memory"); | ||
| + ret = pm_clk_add(dev, "bus"); | ||
| + if (ret) | ||
| + return ret; | ||
| + |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Linux kernel pm_clk_add optional clock behavior documentation
💡 Result:
pm_clk_add() / pm_clk_add_clk() do not have “optional clock” semantics: if the clock can’t be found, they fail (typically -ENOENT). In current drivers/base/power/clock_ops.c, __pm_clk_add() explicitly returns -ENOENT when the passed struct clk * is an error pointer (and pm_clk_add() ultimately depends on clk_get() succeeding too). It also documents that pm_clk_add_clk() takes ownership of the clock reference on success (callers must not clk_put() it afterward). [1]
If you want an optional PM clock, the usual pattern is:
- acquire it with an “optional” clock getter (
devm_clk_get_optional()/clk_get_optional()), which returns NULL (not -ENOENT) when the clock isn’t present, and - only call
pm_clk_add_clk()if the returned pointer is non-NULL. [2]
Example:
clk = devm_clk_get_optional(dev, "foo");
if (IS_ERR(clk))
return PTR_ERR(clk);
if (clk) {
ret = pm_clk_add_clk(dev, clk);
if (ret)
return ret;
}Sources:
[1] Linux drivers/base/power/clock_ops.c (Codebrowser) — error handling in __pm_clk_add() and ownership note in pm_clk_add_clk()
[2] Linux Kernel API docs — devm_clk_get_optional() returns NULL when no clock is found
🏁 Script executed:
cd patch/kernel/archive/qcs6490-6.18 && cat -n 0040-crypto-qce-Add-runtime-PM-and-interconnect-bandwidth.patch | sed -n '90,180p'Repository: armbian/build
Length of output: 2938
pm_clk_add() does not support optional clocks—this patch breaks compatibility with platforms missing optional clock entries.
The original code used devm_clk_get_optional_enabled() which gracefully handles missing clocks by returning NULL instead of an error. The patch replaces this with pm_clk_add(dev, "iface") and pm_clk_add(dev, "bus"), which do not have optional semantics: they return -ENOENT and fail the probe if the clock is not found.
According to Linux kernel documentation, the correct pattern for optional PM clocks is:
clk = devm_clk_get_optional(dev, "name");
if (IS_ERR(clk))
return PTR_ERR(clk);
if (clk) {
ret = pm_clk_add_clk(dev, clk);
if (ret)
return ret;
}This patch will break the driver on platforms where the "iface" or "bus" clocks are not defined in the device tree. The probe will fail instead of gracefully continuing.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0040-crypto-qce-Add-runtime-PM-and-interconnect-bandwidth.patch`
around lines 104 - 127, Revert the replacement of optional clock handling with
pm_clk_add for "iface" and "bus": use devm_clk_get_optional (or
devm_clk_get_optional_enabled if you need it enabled) to fetch qce->iface and
qce->bus, check IS_ERR and return PTR_ERR on error, then only call
pm_clk_add_clk (or pm_clk_add_clk equivalent) when the returned clk is non-NULL
and handle its return value; update the probe code paths around qce->iface and
qce->bus to match this pattern so platforms missing these optional clocks
continue to probe successfully.
| + u8 chipselect = spi_get_chipselect(spi_slv, 0); | ||
| + bool cs_changed = (mas->last_cs != chipselect); | ||
| + u32 mode_changed = mas->last_mode ^ spi_slv->mode; | ||
| + | ||
| + mas->last_cs = chipselect; | ||
| + mas->last_mode = spi_slv->mode; | ||
| + | ||
| + if (mode_changed & SPI_LSB_FIRST) | ||
| + mas->cur_bits_per_word = 0; /* force next setup_se_xfer to call spi_setup_word_len */ | ||
| + if (mode_changed & SPI_LOOP) | ||
| + writel((spi_slv->mode & SPI_LOOP) ? LOOPBACK_ENABLE : 0, se->base + SE_SPI_LOOPBACK); | ||
| + if (cs_changed) | ||
| + writel(chipselect, se->base + SE_SPI_DEMUX_SEL); | ||
| + if (mode_changed & SE_SPI_CPHA) | ||
| + writel((spi_slv->mode & SPI_CPHA) ? CPHA : 0, se->base + SE_SPI_CPHA); | ||
| + if (mode_changed & SE_SPI_CPOL) | ||
| + writel((spi_slv->mode & SPI_CPOL) ? CPOL : 0, se->base + SE_SPI_CPOL); | ||
| + if ((mode_changed & SPI_CS_HIGH) || (cs_changed && (spi_slv->mode & SPI_CS_HIGH))) |
There was a problem hiding this comment.
Fix CPHA/CPOL change detection — using register offsets masks the mode bits.
mode_changed compares SPI mode bits, but the code masks with SE_SPI_CPHA / SE_SPI_CPOL (register offsets), so CPHA/CPOL updates won’t fire when the mode changes. This can leave the controller in the wrong phase/polarity.
🐛 Proposed fix
- if (mode_changed & SE_SPI_CPHA)
+ if (mode_changed & SPI_CPHA)
writel((spi_slv->mode & SPI_CPHA) ? CPHA : 0, se->base + SE_SPI_CPHA);
- if (mode_changed & SE_SPI_CPOL)
+ if (mode_changed & SPI_CPOL)
writel((spi_slv->mode & SPI_CPOL) ? CPOL : 0, se->base + SE_SPI_CPOL);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| + u8 chipselect = spi_get_chipselect(spi_slv, 0); | |
| + bool cs_changed = (mas->last_cs != chipselect); | |
| + u32 mode_changed = mas->last_mode ^ spi_slv->mode; | |
| + | |
| + mas->last_cs = chipselect; | |
| + mas->last_mode = spi_slv->mode; | |
| + | |
| + if (mode_changed & SPI_LSB_FIRST) | |
| + mas->cur_bits_per_word = 0; /* force next setup_se_xfer to call spi_setup_word_len */ | |
| + if (mode_changed & SPI_LOOP) | |
| + writel((spi_slv->mode & SPI_LOOP) ? LOOPBACK_ENABLE : 0, se->base + SE_SPI_LOOPBACK); | |
| + if (cs_changed) | |
| + writel(chipselect, se->base + SE_SPI_DEMUX_SEL); | |
| + if (mode_changed & SE_SPI_CPHA) | |
| + writel((spi_slv->mode & SPI_CPHA) ? CPHA : 0, se->base + SE_SPI_CPHA); | |
| + if (mode_changed & SE_SPI_CPOL) | |
| + writel((spi_slv->mode & SPI_CPOL) ? CPOL : 0, se->base + SE_SPI_CPOL); | |
| + if ((mode_changed & SPI_CS_HIGH) || (cs_changed && (spi_slv->mode & SPI_CS_HIGH))) | |
| u8 chipselect = spi_get_chipselect(spi_slv, 0); | |
| bool cs_changed = (mas->last_cs != chipselect); | |
| u32 mode_changed = mas->last_mode ^ spi_slv->mode; | |
| mas->last_cs = chipselect; | |
| mas->last_mode = spi_slv->mode; | |
| if (mode_changed & SPI_LSB_FIRST) | |
| mas->cur_bits_per_word = 0; /* force next setup_se_xfer to call spi_setup_word_len */ | |
| if (mode_changed & SPI_LOOP) | |
| writel((spi_slv->mode & SPI_LOOP) ? LOOPBACK_ENABLE : 0, se->base + SE_SPI_LOOPBACK); | |
| if (cs_changed) | |
| writel(chipselect, se->base + SE_SPI_DEMUX_SEL); | |
| if (mode_changed & SPI_CPHA) | |
| writel((spi_slv->mode & SPI_CPHA) ? CPHA : 0, se->base + SE_SPI_CPHA); | |
| if (mode_changed & SPI_CPOL) | |
| writel((spi_slv->mode & SPI_CPOL) ? CPOL : 0, se->base + SE_SPI_CPOL); | |
| if ((mode_changed & SPI_CS_HIGH) || (cs_changed && (spi_slv->mode & SPI_CS_HIGH))) |
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0066-spi-geni-qcom-rework-setup_fifo_params.patch`
around lines 60 - 77, The code incorrectly tests mode_changed against
register-offset constants SE_SPI_CPHA/SE_SPI_CPOL instead of the SPI mode bit
masks, so CPHA/CPOL updates never trigger; change the two conditionals that read
"if (mode_changed & SE_SPI_CPHA)" and "if (mode_changed & SE_SPI_CPOL)" to test
against the SPI mode masks "SPI_CPHA" and "SPI_CPOL" respectively (keep the
write logic using SE_SPI_CPHA/SE_SPI_CPOL offsets and the existing writes that
use spi_slv->mode to decide CPHA/CPOL). Ensure you reference the variables
mode_changed, spi_slv->mode and the constants SPI_CPHA/SPI_CPOL in the patch.
| - if (tp->mac_version >= RTL_GIGA_MAC_VER_46 && | ||
| - r8168_mac_ocp_read(tp, 0xc0b2) & 0xf) | ||
| + if (tp->mac_version >= RTL_GIGA_MAC_VER_46) | ||
| return true; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, examine the full patch file to understand the complete context
cat -n "patch/kernel/archive/qcs6490-6.18/0071-r8169-Remove-the-check-of-a-register-to-enable-ASPM-.patch"Repository: armbian/build
Length of output: 1424
🏁 Script executed:
# Search for related r8169 ASPM fixes and device-specific code in the kernel archive
fd "0071" patch/kernel/archive/qcs6490-6.18/ --type fRepository: armbian/build
Length of output: 154
🏁 Script executed:
# Check if there are any device-specific quirks or filtering related to Q6A/QCS6490
rg "qcs6490|Q6A|QCS6490" patch/kernel/archive/qcs6490-6.18/ -i --context 3Repository: armbian/build
Length of output: 50369
🏁 Script executed:
# Look for other patches that might have device-specific scoping for r8169
rg "r8169.*ASPM|ASPM.*r8169" patch/kernel/archive/qcs6490-6.18/ -i -A 2 -B 2Repository: armbian/build
Length of output: 718
🏁 Script executed:
# Check if there are device-specific quirks in r8169 driver for RTL_GIGA_MAC_VER_46
rg "RTL_GIGA_MAC_VER_46" patch/kernel/archive/qcs6490-6.18/ -A 3 -B 3Repository: armbian/build
Length of output: 1240
🏁 Script executed:
# Check if this patch modifies anything else that might scope the change
grep -r "rtl_aspm_is_safe" patch/kernel/archive/qcs6490-6.18/0071* -A 5 -B 5Repository: armbian/build
Length of output: 559
Patch enables ASPM unconditionally across all RTL_GIGA_MAC_VER_46+ systems without vendor safety gate.
This change removes the register check that vendors use to explicitly test ASPM 1.2 compatibility, now enabling ASPM globally via mac_version alone. The modification applies to the generic driver code with no device-specific scoping, affecting all r8169 devices with RTL_GIGA_MAC_VER_46 or later, not just Radxa Dragon Q6A.
The patch should either: (a) add a device-specific filter (PCI subsystem ID or device tree quirk) to limit the change to Q6A, or (b) provide evidence that the vendor-tested register gate is no longer required universally. The current change risks reintroducing link issues on other platforms using the same MAC version.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0071-r8169-Remove-the-check-of-a-register-to-enable-ASPM-.patch`
around lines 23 - 26, The patch removes the r8168_mac_ocp_read(0xc0b2) register
gate and enables ASPM for all devices with tp->mac_version >=
RTL_GIGA_MAC_VER_46; restore vendor scoping by either reintroducing the original
register check (r8168_mac_ocp_read(tp, 0xc0b2) & 0xf) or add a device-specific
quirk/filter that checks the PCI subsystem/device ID or a device-tree compatible
string (e.g., Radxa Dragon Q6A) before returning true so only the intended
hardware (not all RTL_GIGA_MAC_VER_46 devices) enables ASPM.
| @@ -688,8 +688,13 @@ static int decide_core(struct venus_inst *inst) | ||
| cu.video_core_enable_mask = min_lp_coreid; | ||
| move_core_to_power_save_mode(core, min_lp_coreid); | ||
| } else { | ||
| - dev_warn(core->dev, "HW can't support this load"); | ||
| - return -EINVAL; | ||
| + // dev_warn(core->dev, "HW can't support this load"); | ||
| + // return -EINVAL; | ||
| + dev_warn(core->dev, "HW is overloaded(?) Will run at max performance.\n"); | ||
| + inst->clk_data.core_id = min_lp_coreid; | ||
| + cu.video_core_enable_mask = min_lp_coreid; | ||
| + move_core_to_power_save_mode(core, min_lp_coreid); | ||
| + power_save_mode_enable(inst, true); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "0072-media-venus-Workaround-10-bit-decoding-and-performan.patch" -type fRepository: armbian/build
Length of output: 156
🏁 Script executed:
cat ./patch/kernel/archive/qcs6490-6.18/0072-media-venus-Workaround-10-bit-decoding-and-performan.patchRepository: armbian/build
Length of output: 3227
🏁 Script executed:
# Check what VENUS_MAX_FPS is defined as
rg "VENUS_MAX_FPS" --type c -B 2 -A 2Repository: armbian/build
Length of output: 39
🏁 Script executed:
# Search in all files for VENUS_MAX_FPS definition
rg "VENUS_MAX_FPS" -B 2 -A 2Repository: armbian/build
Length of output: 1939
🏁 Script executed:
# Look for VENUS_MAX_FPS or related definitions in qcs6490-6.18 patches
rg "VENUS_MAX_FPS|#define.*FPS" patch/kernel/archive/qcs6490-6.18/ -B 1 -A 1Repository: armbian/build
Length of output: 433
🏁 Script executed:
# Search for VENUS_MAX_FPS definition across all qcs6490-6.18 patches
grep -r "define VENUS_MAX_FPS" patch/kernel/archive/qcs6490-6.18/Repository: armbian/build
Length of output: 39
🏁 Script executed:
# Search for where VENUS_MAX_FPS might be defined - check all patch files
grep -r "VENUS_MAX_FPS\|venus.*\.h" patch/kernel/archive/qcs6490-6.18/ | head -20Repository: armbian/build
Length of output: 183
🏁 Script executed:
# Check all patches in order to see if VENUS_MAX_FPS is defined earlier
ls -1 patch/kernel/archive/qcs6490-6.18/*.patch | sort | head -15Repository: armbian/build
Length of output: 1509
🏁 Script executed:
# Search for the definition of VENUS_MAX_FPS in earlier patches
for patch in patch/kernel/archive/qcs6490-6.18/*.patch; do
if grep -q "define.*VENUS_MAX_FPS" "$patch"; then
echo "Found in: $patch"
grep "define.*VENUS_MAX_FPS" "$patch" -B 1 -A 1
fi
doneRepository: armbian/build
Length of output: 39
🏁 Script executed:
# Check if VENUS_MAX_FPS is defined in the original kernel source being patched
# First, let's look at what patches define things in venus headers
grep -l "drivers/media/platform/qcom/venus" patch/kernel/archive/qcs6490-6.18/*.patchRepository: armbian/build
Length of output: 350
🏁 Script executed:
# Check the Linux kernel version and see if VENUS_MAX_FPS is a standard constant
# Look at the kernel source tree baseline for 6.18
rg "define VENUS_MAX_FPS" --type cRepository: armbian/build
Length of output: 39
🏁 Script executed:
# Search for FPS constant definitions in venus driver across all patches
rg "fps.*=\s*\d+" patch/kernel/archive/qcs6490-6.18/0072 -A 1 -B 1Repository: armbian/build
Length of output: 135
🏁 Script executed:
# Check if any of the other venus patches define VENUS_MAX_FPS
grep -h "VENUS_MAX_FPS\|fps.*=" patch/kernel/archive/qcs6490-6.18/007[2-4]*.patchRepository: armbian/build
Length of output: 103
🏁 Script executed:
# Check if VENUS_MAX_FPS exists in upstream Linux kernel 6.18
# Look at the base kernel patches to understand the structure
grep -r "HFI_VIDEO_CODEC_HEVC\|fps = 30" patch/kernel/archive/qcs6490-6.18/ | head -5Repository: armbian/build
Length of output: 312
🏁 Script executed:
# Let's check the actual Linux kernel 6.18 source to see if VENUS_MAX_FPS is a standard constant
# Search all patches to see if any defines this constant
rg "define\s+VENUS_MAX_FPS" patch/Repository: armbian/build
Length of output: 144
🏁 Script executed:
# Check if VENUS_MAX_FPS is defined in any earlier qcs6490-6.18 patch
for i in {0..71}; do
patch_num=$(printf "%04d" $i)
patch_file="patch/kernel/archive/qcs6490-6.18/$(printf "%04d" $i)-*.patch"
if compgen -G "$patch_file" > /dev/null; then
if grep -q "VENUS_MAX_FPS\|#define.*240\|#define.*fps" $(compgen -G "$patch_file" | head -1) 2>/dev/null; then
echo "Found in patch $i"
grep "VENUS_MAX_FPS\|#define.*240\|#define.*fps" $(compgen -G "$patch_file" | head -1)
fi
fi
doneRepository: armbian/build
Length of output: 39
Undefined constant VENUS_MAX_FPS will cause build failure—fix required.
Patch references VENUS_MAX_FPS on line 77 but this constant is never defined in the qcs6490-6.18 series. It exists only in odroidxu4-6.6 (defined as 240). Either import this definition or revert fps to a literal value. Additionally, the fallback in decide_core() still has inconsistent messaging: the log says "max performance" while the code enters power-save mode; clarify the intent and remove commented-out code.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0072-media-venus-Workaround-10-bit-decoding-and-performan.patch`
around lines 17 - 30, Define or replace the undefined VENUS_MAX_FPS and
reconcile the decide_core fallback behavior: either add a local definition for
VENUS_MAX_FPS (e.g. match upstream value like 240) or replace uses of
VENUS_MAX_FPS with an explicit literal, and in decide_core() fix the log and
behavior to be consistent by removing commented-out lines, ensuring the dev_warn
message matches the actual actions (if enabling power save via
power_save_mode_enable(inst, true) then log that we're falling back to
power-save/minimal operation; if instead you intend to force max performance
clear the power-save call and set
inst->clk_data.core_id/cu.video_core_enable_mask accordingly) so that
dev_warn(core->dev, ...), inst->clk_data.core_id, cu.video_core_enable_mask and
power_save_mode_enable() all reflect the same intent.
| - if (V4L2_TYPE_IS_CAPTURE(type) && fmt[i].pixfmt == V4L2_PIX_FMT_QC10C && | ||
| - !(inst->bit_depth == VIDC_BITDEPTH_10)) | ||
| - return NULL; | ||
| + // if (V4L2_TYPE_IS_CAPTURE(type) && fmt[i].pixfmt == V4L2_PIX_FMT_QC10C && | ||
| + // !(inst->bit_depth == VIDC_BITDEPTH_10)) | ||
| + // return NULL; |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
find . -name "0072-media-venus-Workaround-10-bit-decoding-and-performan.patch" -type fRepository: armbian/build
Length of output: 156
🏁 Script executed:
cat -n "./patch/kernel/archive/qcs6490-6.18/0072-media-venus-Workaround-10-bit-decoding-and-performan.patch"Repository: armbian/build
Length of output: 3808
Remove commented-out QC10C validation or document the workaround rationale.
The checks preventing QC10C acceptance when inst->bit_depth is not 10 are commented out in both find_format (lines 41-46) and find_format_by_index (lines 54-59). While the patch title indicates this is an intentional workaround, leaving commented-out code in the codebase is problematic. Either delete the commented lines entirely and document in the commit message why this validation bypass is necessary and safe, or restore the checks with clear explanation in code comments. If the intent is to defer validation until bit_depth is initialized, that logic should be explicit in active code rather than commented-out.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0072-media-venus-Workaround-10-bit-decoding-and-performan.patch`
around lines 41 - 46, The commented-out QC10C validation in find_format and
find_format_by_index (the checks comparing fmt[i].pixfmt == V4L2_PIX_FMT_QC10C
and inst->bit_depth == VIDC_BITDEPTH_10) must be resolved: either remove the
commented lines entirely and add a brief commit message explaining the
workaround rationale, or reintroduce active validation with explicit logic
(e.g., skip the check until inst->bit_depth is initialized or return NULL when
bit depth != 10) and add an in-code comment explaining why the bypass is safe;
update the functions find_format and find_format_by_index accordingly and ensure
any deferred-validation path is clearly documented in the code comment
referencing inst->bit_depth and V4L2_PIX_FMT_QC10C.
| From 2d55f5d464cf7941083dd9437cf67c13ae47af87 Mon Sep 17 00:00:00 2001 | ||
| From: Jiali Chen <chenjiali@radxa.com> | ||
| Date: Fri, 12 Dec 2025 03:27:24 +0000 | ||
| Subject: [PATCH 099/121] arm64: dts: meson-g12a: modify cpu opp voltage value | ||
|
|
||
| Reference to vendor kernel [1]. | ||
|
|
||
| [1] https://github.com/CoreELEC/linux-amlogic/blob/amlogic-4.9-20/arch/arm64/boot/dts/amlogic/g12a_s905x2_u211.dts | ||
|
|
||
| Signed-off-by: Jiali Chen <chenjiali@radxa.com> | ||
| --- | ||
| arch/arm64/boot/dts/amlogic/meson-g12a.dtsi | 10 +++++----- | ||
| 1 file changed, 5 insertions(+), 5 deletions(-) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for existing meson/amlogic kernel patch directories
echo "=== Meson/Amlogic kernel patch directories ==="
find patch/kernel/archive/ -maxdepth 1 -type d | grep -E 'meson|amlogic' | sort
echo ""
echo "=== QCS6490 patches referencing meson ==="
grep -l 'meson' patch/kernel/archive/qcs6490-6.18/*.patch 2>/dev/null | wc -l
grep -l 'meson' patch/kernel/archive/qcs6490-6.18/*.patch 2>/dev/null | head -10
echo ""
echo "=== Sample of all patches in qcs6490-6.18 ==="
ls -1 patch/kernel/archive/qcs6490-6.18/ | head -20
echo ""
echo "=== Check architecture families in qcs6490-6.18 ==="
for patch in patch/kernel/archive/qcs6490-6.18/*.patch; do
grep -h "^Subject:" "$patch" 2>/dev/null | sed 's/^Subject: //' | cut -d: -f1-2
done | sort -u | head -30Repository: armbian/build
Length of output: 3536
🏁 Script executed:
#!/bin/bash
# Get more context on patch 0099 and surrounding radxa patches
echo "=== Checking if meson64-6.18 contains any radxa-specific patches ==="
grep -l 'radxa' patch/kernel/archive/meson64-6.18/*.patch 2>/dev/null | wc -l
grep -l 'radxa' patch/kernel/archive/meson64-6.18/*.patch 2>/dev/null | head -5
echo ""
echo "=== Checking radxa patches in qcs6490-6.18 ==="
grep -l 'radxa' patch/kernel/archive/qcs6490-6.18/*.patch 2>/dev/null | wc -l
echo ""
echo "=== Examining the specific patch 0099 ==="
head -20 patch/kernel/archive/qcs6490-6.18/0099-arm64-dts-meson-g12a-modify-cpu-opp-voltage-value.patchRepository: armbian/build
Length of output: 1534
Amlogic device tree patches should be organized in meson64-6.18, not qcs6490-6.18.
This patch modifies arch/arm64/boot/dts/amlogic/meson-g12a.dtsi (Amlogic Meson SoC) but is located in the qcs6490-6.18 patch directory (Qualcomm SoC family). While the patch itself is legitimate and properly authored, it should reside in meson64-6.18 where other Meson-based device tree changes are organized.
This is part of a broader organizational issue: 66 Radxa-specific patches are present in qcs6490-6.18, while only 7 Radxa patches exist in meson64-6.18. Patches targeting Amlogic Meson devices (including those modifying Radxa Zero variants) should be consolidated in the Meson kernel family directory to maintain correct separation by target SoC architecture.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0099-arm64-dts-meson-g12a-modify-cpu-opp-voltage-value.patch`
around lines 1 - 13, The patch modifies
arch/arm64/boot/dts/amlogic/meson-g12a.dtsi (CPU OPP voltage values) but is
incorrectly placed under the qcs6490-6.18 patch series; move this patch file
into the meson64-6.18 directory so Amlogic Meson SoC changes are grouped
correctly. Update the patch metadata (subject/series location) if needed so the
patch applies in the meson64-6.18 queue and remove it from qcs6490-6.18; ensure
the patch filename and the referenced target (meson-g12a.dtsi) remain unchanged
and that any series index/order is adjusted to match other meson64-6.18 patches.
| +static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms) | ||
| +{ | ||
| + const struct dpu_pingpong_cfg *pingpong; | ||
| + u32 max_pingpong_width = dpu_kms->catalog->pingpong[0].max_linewidth; | ||
| + | ||
| + /* | ||
| + * Find the smallest overall PINGPONG max_linewidth in the catalog since | ||
| + * max_linewidth can differ between PINGPONGs even within the same | ||
| + * chipset. | ||
| + * | ||
| + * Note: While, for DPU 8.x+, PINGPONG_0 can technically support up to | ||
| + * 8k resolutions, this requires reworking the RM to try to reserve | ||
| + * PINGPONG_0 for modes greater than 5k. | ||
| + * | ||
| + * Once this additional logic is implemented, we can drop this helper | ||
| + * and use the reserved PINGPONG's max_linewidth | ||
| + */ | ||
| + for (int i = 1; i < dpu_kms->catalog->pingpong_count; i++) { | ||
| + pingpong = &dpu_kms->catalog->pingpong[i]; | ||
| + max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth); | ||
| + } | ||
| + | ||
| + return max_pingpong_width; | ||
| +} |
There was a problem hiding this comment.
Guard against zero max_linewidth to avoid rejecting all modes.
If any pingpong entry leaves max_linewidth at 0, the min reduction yields 0 and downstream checks will reject every mode. Safer to fall back to caps->max_mixer_width and skip zero entries.
🐛 Suggested fix
-static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms)
+static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms)
{
const struct dpu_pingpong_cfg *pingpong;
- u32 max_pingpong_width = dpu_kms->catalog->pingpong[0].max_linewidth;
+ u32 max_pingpong_width = dpu_kms->catalog->caps->max_mixer_width;
/*
@@ -49,8 +49,9 @@ static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms)
*/
for (int i = 1; i < dpu_kms->catalog->pingpong_count; i++) {
pingpong = &dpu_kms->catalog->pingpong[i];
- max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth);
+ if (pingpong->max_linewidth)
+ max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth);
}
return max_pingpong_width;
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| +static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms) | |
| +{ | |
| + const struct dpu_pingpong_cfg *pingpong; | |
| + u32 max_pingpong_width = dpu_kms->catalog->pingpong[0].max_linewidth; | |
| + | |
| + /* | |
| + * Find the smallest overall PINGPONG max_linewidth in the catalog since | |
| + * max_linewidth can differ between PINGPONGs even within the same | |
| + * chipset. | |
| + * | |
| + * Note: While, for DPU 8.x+, PINGPONG_0 can technically support up to | |
| + * 8k resolutions, this requires reworking the RM to try to reserve | |
| + * PINGPONG_0 for modes greater than 5k. | |
| + * | |
| + * Once this additional logic is implemented, we can drop this helper | |
| + * and use the reserved PINGPONG's max_linewidth | |
| + */ | |
| + for (int i = 1; i < dpu_kms->catalog->pingpong_count; i++) { | |
| + pingpong = &dpu_kms->catalog->pingpong[i]; | |
| + max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth); | |
| + } | |
| + | |
| + return max_pingpong_width; | |
| +} | |
| static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms) | |
| { | |
| const struct dpu_pingpong_cfg *pingpong; | |
| u32 max_pingpong_width = dpu_kms->catalog->caps->max_mixer_width; | |
| /* | |
| * Find the smallest overall PINGPONG max_linewidth in the catalog since | |
| * max_linewidth can differ between PINGPONGs even within the same | |
| * chipset. | |
| * | |
| * Note: While, for DPU 8.x+, PINGPONG_0 can technically support up to | |
| * 8k resolutions, this requires reworking the RM to try to reserve | |
| * PINGPONG_0 for modes greater than 5k. | |
| * | |
| * Once this additional logic is implemented, we can drop this helper | |
| * and use the reserved PINGPONG's max_linewidth | |
| */ | |
| for (int i = 1; i < dpu_kms->catalog->pingpong_count; i++) { | |
| pingpong = &dpu_kms->catalog->pingpong[i]; | |
| if (pingpong->max_linewidth) | |
| max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth); | |
| } | |
| return max_pingpong_width; | |
| } |
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0104-drm-msm-dpu-Check-mode-against-PINGPONG-or-DSC-max-w.patch`
around lines 32 - 55, The helper msm_display_get_max_pingpong_width can return 0
if any pingpong->max_linewidth is zero, causing all modes to be rejected; update
it to ignore zero max_linewidth entries and fall back to a sane default:
initialize max_pingpong_width from dpu_kms->caps->max_mixer_width (or use it if
no non-zero pingpong widths are found), and when iterating over
dpu_kms->catalog->pingpong[i] only consider pingpong->max_linewidth values > 0
when computing the minimum; ensure the function returns the fallback
caps->max_mixer_width if all pingpong entries are zero.
| +&dwc3 { | ||
| + ports { | ||
| + usb_dwc2_out: endpoint@0 { | ||
| + remote-endpoint = <&ucsi0_hs_in>; | ||
| + }; | ||
| + | ||
| + usb_dwc3_out: endpoint@1 { | ||
| + remote-endpoint = <&ucsi0_ss_in>; | ||
| + }; | ||
| + }; | ||
| +}; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check how other meson DTS files structure dwc3 ports
find . -type f \( -name "*meson*.dts" -o -name "*meson*.dtsi" -o -name "*radxa*.dts" \) | head -20Repository: armbian/build
Length of output: 1516
🏁 Script executed:
#!/bin/bash
# Search for dwc3 definitions in meson files
rg -l 'meson|radxa' --glob '*.dts' --glob '*.dtsi' | xargs rg -A 15 '&dwc3\s*\{' | head -100Repository: armbian/build
Length of output: 39
🏁 Script executed:
#!/bin/bash
# Look for usb controller definitions with ports structure
rg -B 2 -A 10 'ports\s*\{' --glob '*.dts' --glob '*.dtsi' | grep -A 10 'dwc\|usb' | head -80Repository: armbian/build
Length of output: 5707
🏁 Script executed:
#!/bin/bash
# Search for any documentation or binding files
find . -type f -name '*.yaml' -o -name '*.json' | grep -i 'dwc3\|usb' | head -20Repository: armbian/build
Length of output: 39
🏁 Script executed:
#!/bin/bash
# Find and examine the patch file
find . -name "*0109-arm64-dts-meson-radxa-zero-add-USB-Type-C-support*" -type fRepository: armbian/build
Length of output: 156
🏁 Script executed:
#!/bin/bash
# Search for dwc3 in meson g12 kernel files more carefully
find . -path "*/meson64-6.18/*" -name "*.dts" -o -name "*.dtsi" | xargs grep -l dwc3 2>/dev/nullRepository: armbian/build
Length of output: 118
🏁 Script executed:
#!/bin/bash
# Look for kernel bindings documentation for Amlogic/meson USB
find . -name "*.yaml" -type f | xargs grep -l "amlogic\|meson" 2>/dev/null | head -20Repository: armbian/build
Length of output: 426
🏁 Script executed:
#!/bin/bash
# Search for any existing dwc3 definitions in meson kernel files
rg 'dwc3|DWC3' --glob '*/meson64-*/*' -B 2 -A 8Repository: armbian/build
Length of output: 205
🏁 Script executed:
#!/bin/bash
# Read the patch file
cat ./patch/kernel/archive/qcs6490-6.18/0109-arm64-dts-meson-radxa-zero-add-USB-Type-C-support-vi.patchRepository: armbian/build
Length of output: 4400
🏁 Script executed:
#!/bin/bash
# Search for any existing dwc3 node definitions in kernel patches
rg 'endpoints?\s*\{' --glob '*.patch' --glob '*.dts' --glob '*.dtsi' -B 3 -A 8 | grep -A 8 -B 3 'dwc\|meson'Repository: armbian/build
Length of output: 50370
🏁 Script executed:
#!/bin/bash
# Check Linux kernel dwc3 binding documentation to confirm correct structure
find . -name "*dwc3*" -o -name "*usb*" | grep -i "\.yaml\|\.txt" | grep -i binding | head -10Repository: armbian/build
Length of output: 39
🏁 Script executed:
# Extract the exact differences from patch 0117
grep -A 15 "^@@" ./patch/kernel/archive/qcs6490-6.18/0117-arm64-dts-amlogic-fix-USB-DWC3-port-nodes-for-Radxa-.patch | head -80Repository: armbian/build
Length of output: 717
Use port instead of ports for dwc3 endpoint nodes.
The &dwc3 block should have a single port node containing the endpoints, not a ports node. This matches the OF-graph binding specification and the standard pattern used across meson devices. Patch 0117 in this series fixes this exact issue by changing &dwc3 { ports { ... } } to &dwc3 { port { ... } }.
Diff showing the required correction
&dwc3 {
- ports {
+ port {
usb_dwc2_out: endpoint@0 {
remote-endpoint = <&ucsi0_hs_in>;
};
usb_dwc3_out: endpoint@1 {
remote-endpoint = <&ucsi0_ss_in>;
};
};
};
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0109-arm64-dts-meson-radxa-zero-add-USB-Type-C-support-vi.patch`
around lines 79 - 89, The &dwc3 node uses an incorrect container name "ports";
change it to a single "port" node so the endpoint child nodes (usb_dwc2_out:
endpoint@0 and usb_dwc3_out: endpoint@1) attach correctly to &dwc3 and follow
the OF-graph binding; update the block around &dwc3 to replace "ports { ... }"
with "port { ... }" while keeping the remote-endpoint references to &ucsi0_hs_in
and &ucsi0_ss_in unchanged.
| +static u32 connector_get_quirks(struct drm_connector *connector) | ||
| +{ | ||
| + struct device_node *np = connector->dev->dev->of_node; | ||
| + u32 quirks = 0; | ||
| + | ||
| + if (!np) | ||
| + return 0; | ||
| + | ||
| + if (of_property_read_bool(np, "quirk-prefer-fhd")) | ||
| + quirks |= BIT(CONNECTOR_QUIRK_PREFER_FHD); | ||
| + | ||
| + if (of_property_read_bool(np, "quirk-prefer-large-60")) | ||
| + quirks |= BIT(EDID_QUIRK_PREFER_LARGE_60); | ||
| + | ||
| + if (of_property_read_bool(np, "quirk-prefer-large-75")) | ||
| + quirks |= BIT(EDID_QUIRK_PREFER_LARGE_75); | ||
| + | ||
| + return quirks; | ||
| +} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat patch/kernel/archive/qcs6490-6.18/0111-drm-edid-add-device-tree-quirk-flags-supports.patch | head -200Repository: armbian/build
Length of output: 2730
🏁 Script executed:
# Search for EDID quirk enum and related definitions
rg -n "enum.*quirk|EDID_QUIRK_" --type=c -B2 -A2 drivers/gpu/drm/drm_edid.c 2>/dev/null | head -100Repository: armbian/build
Length of output: 39
🏁 Script executed:
# Find where update_display_info is defined and how quirks are combined
rg -n "update_display_info|connector_get_quirks" --type=c -B3 -A15 drivers/gpu/drm/drm_edid.c 2>/dev/null | head -150Repository: armbian/build
Length of output: 39
🏁 Script executed:
# Check if these enum values exist elsewhere in the patch series
find patch/kernel/archive/qcs6490-6.18/ -name "*.patch" -exec grep -l "EDID_QUIRK_PREFER_LARGE" {} \;Repository: armbian/build
Length of output: 147
🏁 Script executed:
# Search for the full enum definition in the patch file
grep -n "EDID_QUIRK_PREFER_LARGE\|enum drm_edid_internal_quirk" patch/kernel/archive/qcs6490-6.18/0111-drm-edid-add-device-tree-quirk-flags-supports.patchRepository: armbian/build
Length of output: 251
🏁 Script executed:
# Check what the actual drm_edid.c file contains (if available)
if [ -f drivers/gpu/drm/drm_edid.c ]; then
grep -n "EDID_QUIRK_PREFER_LARGE\|enum drm_edid_internal_quirk" drivers/gpu/drm/drm_edid.c | head -50
else
echo "drm_edid.c not in repository"
fiRepository: armbian/build
Length of output: 85
Patch references undefined enum values EDID_QUIRK_PREFER_LARGE_60 and EDID_QUIRK_PREFER_LARGE_75.
Lines 50 and 53 in connector_get_quirks() use BIT(EDID_QUIRK_PREFER_LARGE_60) and BIT(EDID_QUIRK_PREFER_LARGE_75), but these enum values are never defined in the patch. The enum additions at lines 101-102 only include CONNECTOR_QUIRK_PREFER_FHD. This will cause a compilation error. Add the missing enum definitions to enum drm_edid_internal_quirk:
+ EDID_QUIRK_PREFER_LARGE_60,
+ EDID_QUIRK_PREFER_LARGE_75,
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0111-drm-edid-add-device-tree-quirk-flags-supports.patch`
around lines 38 - 56, The connector_get_quirks() function uses
EDID_QUIRK_PREFER_LARGE_60 and EDID_QUIRK_PREFER_LARGE_75 but those enum members
are missing; add EDID_QUIRK_PREFER_LARGE_60 and EDID_QUIRK_PREFER_LARGE_75 to
the enum drm_edid_internal_quirk so BIT(EDID_QUIRK_PREFER_LARGE_60) and
BIT(EDID_QUIRK_PREFER_LARGE_75) compile correctly, keeping them alongside
CONNECTOR_QUIRK_PREFER_FHD and preserving the intended bit positions.
| From 5460e498d8807b5af789f9ba702200234df25d52 Mon Sep 17 00:00:00 2001 | ||
| From: Jiali Chen <chenjiali@radxa.com> | ||
| Date: Tue, 13 Jan 2026 06:57:27 +0000 | ||
| Subject: [PATCH 119/121] arm64: dts: amlogic: meson-g12b: add missing PWM | ||
| pinctrl nodes | ||
|
|
||
| Add pinctrl definitions for PWM_B (on GPIO H and Z banks), | ||
| PWM_C (on GPIO Z bank) and PWM_D (on GPIO A and Z banks). | ||
|
|
||
| By adding these nodes, these pins can be configured for PWM functionality. | ||
|
|
||
| Signed-off-by: Jiali Chen <chenjiali@radxa.com> | ||
| --- | ||
| arch/arm64/boot/dts/amlogic/meson-g12b.dtsi | 42 +++++++++++++++++++++ | ||
| 1 file changed, 42 insertions(+) | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# List all patch archive directories to understand organization
ls -d patch/kernel/archive/*-6.18 2>/dev/null | head -20Repository: armbian/build
Length of output: 335
🏁 Script executed:
# List all patches in qcs6490-6.18 and examine their content
fd -e patch . patch/kernel/archive/qcs6490-6.18/ 2>/dev/null | while read patch; do
echo "=== $(basename "$patch") ==="
head -15 "$patch" | grep -E "Subject|arch|device tree"
done | head -100Repository: armbian/build
Length of output: 7230
🏁 Script executed:
# Check if Amlogic/meson patches exist in other directories
find patch/kernel/archive -name "*meson*" -o -name "*amlogic*" 2>/dev/null | head -20Repository: armbian/build
Length of output: 1813
🏁 Script executed:
# Check if meson64-6.18 directory has patches
ls -la patch/kernel/archive/meson64-6.18/ 2>/dev/null | head -50Repository: armbian/build
Length of output: 4849
🏁 Script executed:
# Check all meson-related 6.18 directories
ls -d patch/kernel/archive/meson*-6.18 2>/dev/nullRepository: armbian/build
Length of output: 90
🏁 Script executed:
# Verify the actual patch file mentioned in the review
head -30 patch/kernel/archive/qcs6490-6.18/0119-arm64-dts-amlogic-meson-g12b-add-missing-PWM-pinctrl.patch 2>/dev/nullRepository: armbian/build
Length of output: 1079
Move this Amlogic meson-g12b patch to the meson64-6.18 kernel patch directory.
This PWM pinctrl patch for Amlogic's meson-g12b device tree is in the qcs6490-6.18 archive, which contains Qualcomm patches. Amlogic patches belong in patch/kernel/archive/meson64-6.18/, which already contains related Amlogic board and driver patches.
🤖 Prompt for AI Agents
In
`@patch/kernel/archive/qcs6490-6.18/0119-arm64-dts-amlogic-meson-g12b-add-missing-PWM-pinctrl.patch`
around lines 1 - 16, The patch
"0119-arm64-dts-amlogic-meson-g12b-add-missing-PWM-pinctrl.patch" was committed
into the Qualcomm archive (qcs6490-6.18) but belongs in the Amlogic archive;
move that patch file from the qcs6490-6.18 patch archive into the meson64-6.18
patch archive, preserve the original commit/author/Signed-off-by metadata, and
update any patch series/index (or quilt/mbox list) references so the patch is
applied with the other meson-g12b/meson64 patches.
amazingfate
left a comment
amazingfate
left a comment
There was a problem hiding this comment.
Please work based on the current patches instead of overwriting all of them, it makes review hard. And radxa's kernel tree has some unnecessary patches, I don't want them included.
| @@ -0,0 +1,136 @@ | |||
| From 3c150552f89421bcc47bd8e5355b0daf9f361d52 Mon Sep 17 00:00:00 2001 | |||
There was a problem hiding this comment.
This is not necessary for this soc.
2 participants
Description
git format-patchto get latest kernel patches from Radxa on top of 6.18.2Reasoning
Lots of changes since initial support/bios for Radxa-Dragon-Q6A. This makes it compatible with the latest updates
How Has This Been Tested?
Checklist:
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
✏️ Tip: You can customize this high-level summary in your review settings.