Switch meson edge to 6.13 kernel #7747
Conversation
github-actions
bot
added
size/large
|
Can you also try to switch CURRENT to 6.12.y, which is going to be LTS? |
|
iMHO, it would be best to first switch edge to 6.12 so that 6.12 gets some testing on it. Then move legacy to 6.6, current to 6.12 and edge to 6.13. |
Yes, better. |
igorpecovnik
added
02
|
Hello @kernelzru . I tried your version on MXQ clone, which also uses s805 soc. To get any HDMI output, I had to apply the same I apply for 6.12 kernel (https://github.com/armbian/build/blob/main/patch/kernel/archive/meson-6.12/0067-meson8b-mxq-add-HDMI-support.patch) I am getting |
Hello. I've taken patches from xdarklight repository. There is also dts for MXQ device. Can you try with it? Not shure, that it will help, but may be:) |
|
The dts file you pointed me to, has exactly the same fixes as those already in armbian patches (except minor reordering), so it won't help. I did some experiments. I can confirm that the issue is introduced with one of the xdarklight's patches. I looked through the patches to find something, that would resemble any of the functions in the crash callstack. I found two suspicious callbacks added and commented them out. Patches rebased on kernel v6.13.5, some patches copied over from 6.12 (not sure if still needed, but preferred to keep them for now) and the workaround are available on this branch: https://github.com/domin144/armbian-build/tree/meson_6.12_on_xdarklight_6.13_clean_up With this workaround added, I no longer observed the crash. I did some tests and it worked really nicely. Even HDMI audio was working. Not yet sure, what got broken (the callbacks were there for some reason). While this is definitely a workaround, not a solution, there is so much good stuff in the xdarklight's patches, that I think it's worth giving it a try. @xdarklight : no sure what would be the correct way to file an issue against the patches. Maybe you would like to take a look at the kernel crash above? |
|
Hey, has any of this value considering 6.14 is rc7 already? |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
WalkthroughThis pull request comprises a comprehensive set of patches targeting the Meson platforms on the edge branch. It updates the kernel configuration by changing the Possibly related PRs
Suggested labels
Suggested reviewers
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (40)
patch/kernel/archive/meson-6.13/0092-ARM-dts-meson8b-odroid-c1-enable-HDMI-for-the-Odroid.patch (1)
5-7: Remove "WiP" reference if the patch is production-ready.
The commit message still includes a "WiP" reference. If this patch is stable, consider removing any "work-in-progress" placeholders to avoid confusion.patch/kernel/archive/meson-6.13/0050-net-stmmac-dwmac-meson-Manage-the-ethernet-clock.patch (2)
55-72: Clock initialization logic is correct but lacks error logging.
The function sets the clock rate to 50MHz, enabling the divider. Though everything appears correct for RMII mode, consider adding a debug log or error log ifclk_set_ratefails to help diagnose clock issues.+ dev_dbg(&pdev->dev, "Setting ethernet clock rate to 50MHz\n"); ret = clk_set_rate(dwmac->ethernet_clk, 50 * 1000 * 1000); if (ret) - return ret; + { + dev_err(&pdev->dev, "Failed to set ethernet clock rate\n"); + return ret; + }
82-112: Probe sequence duplicates the init call.
Although assigningplat_dat->inittomeson6_dwmac_init, the probe also explicitly callsmeson6_dwmac_init. This is acceptable if the driver architecture requires an early clock setup, but ensure it won’t conflict with the stmmac driver’s internal init/exit flow.patch/kernel/archive/meson-6.13/0037-usb-common-usb-conn-gpio-Fall-back-to-polling-the-GP.patch (3)
24-24: Consider making the polling interval configurable.
The hardcoded constantUSB_GPIO_POLL_MS = 1000might be too large or too small in some use cases. Providing a device tree property or module parameter for this interval could improve flexibility.
53-61: Check repeated role handling logic.
When a repeated role is detected, polling is resumed if needed. This logic may lead to more frequent poll scheduling if cable re-detection happens rapidly. Confirm whether there is a debouncing or rate-limiting mechanism for repeated role detections to avoid unnecessary overhead.
64-76: Consolidate delayed work re-scheduling.
After callingusb_conn_detect_cable(), you restart polling unconditionally if IRQs are not available. Consider moving the relevant queue logic to a shared helper to ensure consistent scheduling regardless of repeated or initial detection scenarios.patch/kernel/archive/meson-6.13/0074-drm-meson-Use-a-separate-list-of-supported-formats-f.patch (2)
33-45: Ensure forward-compatibility of format arrays.Defining a separate array for older SoCs (
supported_drm_formats_m8) is a good approach to handle missing register bits. However, if future SoCs also require restricted or enhanced sets of formats, you might consider implementing a clear extension mechanism such as dynamically constructing these arrays based on SoC capabilities.
47-50: Consolidate shared formats in a single definition if possible.
supported_drm_formats_gxreuses some entries present insupported_drm_formats_m8(e.g.,DRM_FORMAT_ARGB8888,DRM_FORMAT_ABGR8888). If there's significant overlap, consider defining a core set of shared formats and only append the additional ones for newer SoCs to avoid duplication.patch/kernel/archive/meson-6.13/0031-drm-bridge_connector-hook-drm_atomic_helper_connecto.patch (3)
31-49: Prevent redundant EDID reads or status updates.The added
drm_atomic_helper_connector_hdmi_hotplugcall insidedrm_bridge_connector_detectupdates the connector status upon each detect. Ensure that no other part of the pipeline redundantly triggers the same EDID read or status update, causing potential overhead or confusion.
66-68: Add documentation for.forceusage.In the
drm_bridge_connector_funcs, the new.forcecallback might not be intuitive to future maintainers. Consider adding kernel-doc or comments describing its purpose and typical usage scenarios.
73-83: Provide fallback modes when EDID is invalid.
drm_edid_connector_add_modes(connector)relies on valid EDID. If EDID retrieval fails or is corrupted, ensure the system can fall back to a safe default mode rather than failing to produce output.patch/kernel/archive/meson-6.13/0085-ARM-dts-meson-add-the-VPU-WiP.patch (2)
20-34: Clarify the disabled CVBS DAC status.A
cvbs_dacnode is defined but remains"disabled". If it’s not intended for final usage, it could be removed to avoid confusion. Otherwise, consider enabling it or documenting when and how it should be enabled.
263-266: Confirm Meson8m2 VPU compatibility string.For the Meson8m2 device tree snippet:
&vpu { compatible = "amlogic,meson8m2-vpu"; };Confirm that the associated driver or binding documentation accounts for
"amlogic,meson8m2-vpu", ensuring that it won’t default to the Meson8b or Meson8 definitions unless that’s intended.patch/kernel/archive/meson-6.13/0047-clk-meson-meson8b-Add-the-Ethernet-RMII-clock-tree-o.patch (1)
75-90: Consider verifying divider range.The
meson8_eth_clk_divsets an 8-bit divider (.width = 8). Ensure that the input clock range and any intangible constraints on Ethernet RMII clock rates don’t require narrower or broader ranges.patch/kernel/archive/meson-6.13/0082-drm-meson-Add-support-for-the-Meson8-8b-8m2-TranSwit.patch (4)
53-101: Validate register access calls.In
meson_txc_hdmi_reg_readandmeson_txc_hdmi_reg_write, you’re writing the address register twice before reading or writing data. Ensure this is the intended hardware sequence; if only one write is needed, firmware performance might be improved by removing the duplicate.
153-200: Reset sequencing clarity.
meson_txc_hdmi_sys5_reset_assertandmeson_txc_hdmi_sys5_reset_deassertwrite multiple times to the same registers with short delays. Confirm the register writes are in the correct order, as this sequence can be sensitive to hardware timing. If you have no hardware doc, consider adding inline comments or doc references stating the rationale for each step.
213-341: Potential missing advanced colorimetry & HDR pathways.
meson_txc_hdmi_config_color_spacehandles only a limited subset of colorimetry (ITU_601 and ITU_709) and sets default CSC coefficients. If HDR or wide color gamuts are needed, consider extending the function with relevant standard/coefficients (e.g., BT.2020).
931-1086: Triple-check audio N/CTS calculations.The code uses heuristics for
audio_ninmeson_txc_hdmi_hdmi_codec_calc_audio_n, especially for 44.1 kHz multiples. Confirm corner cases (e.g., EAC3, DTS-HD, 176.4 kHz, 352.8 kHz) are handled properly. If out-of-spec rates exist, consider fallback or error handling.patch/kernel/archive/meson-6.13/0028-drm-connector-implement-generic-HDMI-audio-helpers.patch (1)
26-43: Kconfig entry for the new HDMI audio helper.
Declaring this helper as a hidden (bool) config seems fine. Consider if it should be user-selectable or depends on any other config (e.g. SND_SOC_HDMI_CODEC).patch/kernel/archive/meson-6.13/0083-drm-meson-Meson8-Meson8b-Meson8m2-VCLK-HACK.patch (2)
167-174: Suspension stub includes a TODO.
You might want to handle video clock suspension to ensure power savings. Let us know if you’d like assistance drafting a suspend implementation.
176-184: Resume re-initializes clocks.
Re-callingmeson_video_clock_initis fine, but consider symmetrical disabling in the suspend path for consistency.patch/kernel/archive/meson-6.13/0024-drm-tests-hdmi-return-meaningful-value-from-set_conn.patch (1)
3-4: Future date in commit message.The commit message contains a date of "Sat, 30 Nov 2024" which is in the future. This appears to be a typo that should be addressed.
patch/kernel/archive/meson-6.13/0025-drm-display-hdmi-add-generic-mode_valid-helper.patch (3)
27-47: Support wider color depths.
drm_hdmi_compute_mode_clock(mode, 8, HDMI_COLORSPACE_RGB)currently hardcodes RGB 8-bit. Consider expanding support (e.g., 10-bit) for deep-color modes.
60-69: Function naming is slightly ambiguous.
reject_100MHz_connector_tmds_char_rate_valideffectively denies rates above 100 MHz, but its name might be clearer aslimit_tmds_char_rate_valid.-static enum drm_mode_status -reject_100MHz_connector_tmds_char_rate_valid(const struct drm_connector *connector, +static enum drm_mode_status +limit_100MHz_connector_tmds_char_rate_valid(const struct drm_connector *connector,
140-265: Test coverage is commendable.The KUnit tests thoroughly validate multiple scenarios (preferred mode, clock-based rejection, etc.). Consider adding an out-of-range clock scenario or an EDID with no valid modes to confirm edge-case handling.
patch/kernel/archive/meson-6.13/0081-drm-meson-Make-the-HHI-registers-optional-WIP.patch (1)
25-63: Log a debug message when skipping HHI registers.Making the HHI resource optional is correct, but a small info/debug message when none is found could help future debugging.
+ } else { + dev_info(dev, "HHI resource not found; skipping HHI regmap\n"); }patch/kernel/archive/meson-6.13/0020-drm-display-bridge_connector-use-drm_bridge_connecto.patch (2)
27-27: Add a short documentation note for the new include.Including
<drm/display/drm_hdmi_helper.h>here is appropriate fordrm_hdmi_connector_mode_valid(). It could be helpful to add a short comment in the commit message or code to clarify its purpose (e.g., used for HDMI mode validation).
35-46: Consider fallback logic for non-HDMI bridge connectors.The newly introduced
drm_bridge_connector_mode_valid()delegates validation todrm_hdmi_connector_mode_valid()only ifbridge_connector->bridge_hdmiis true, returningMODE_OKotherwise. In some corner cases, a non-HDMI bridge might have specific constraints that also require checking. If in the future other display protocols are supported via the same bridging approach, you may need an extension or fallback logic to ensure correct mode validation.patch/kernel/archive/meson-6.13/0034-phy-amlogic-meson8b-usb2-Add-support-for-reading-the.patch (3)
38-38: Provide context on thegpiochipusage in the struct.Adding
struct gpio_chip gpiochip;tophy_meson8b_usb2_privis a core design detail. Given it’s only used to handle a single ID pin (ngpio = 1), a quick high-level comment or docstring explaining its purpose (exposing “ID” signal as GPIO) may improve code readability.
63-74: Limit future pitfalls by clarifying thengpiousage.
phy_meson8b_usb2_id_gpiochip_add()setsngpioto 1, suitable for the single “ID” pin. If future expansions require handling multiple pins, consider updating logic to dynamically computengpioor add comments noting that only one pin is exposed.
91-95: Ensure fallback for boards without "gpio-controller" property.When
"gpio-controller"is not found, the ID pin logic is skipped. This is valid, but confirm that boards expecting OTG ID detection actually include the necessary property. Consider logging a warning if the hardware is known to require ID detection but the property is missing.patch/kernel/archive/meson-6.13/0017-drm-connector-Add-a-way-to-init-add-a-connector-in-s.patch (3)
80-90: Improve clarity around function renaming.Renaming
__drm_connector_inittodrm_connector_init_onlyclarifies that this function omits adding the connector to the global list. A brief explanation in the header or function’s docstring can help new contributors understand the difference between “init only” vs. “init and add.”
155-170: Document usage constraints fordrm_connector_init_and_add.
drm_connector_init_and_add()is a convenience wrapper for static connectors that combines initialization and registration. Ensure that driver authors clearly understand when to use this function (static connectors) vs. the separate dynamic flow. Adding a note either in the commit message or inline documentation can prevent confusion.
293-319: Confirm forward-compatibility with future dynamic connectors.The additions to
drm_connector.hdefine your new dynamic connector API. As the DRM subsystem evolves, we can expect more dynamic connectors beyond MST. Confirm that naming and usage patterns here will remain clear for future expansions (e.g., multiple dynamic connector types, shared DDC).patch/kernel/archive/meson-6.13/0043-drm-meson-Add-support-for-using-a-PHY-for-the-CVBS-D.patch (3)
33-33: Consider using "select" vs "imply" for dependency management.Using
imply PHY_MESON_CVBS_DACgives users flexibility if they want to exclude the CVBS DAC driver, but it might introduce confusion. If this driver is required for any core functionality, consider changing it toselect PHY_MESON_CVBS_DACto ensure it is always built whenDRM_MESONis enabled.
117-145: Ensure atomic_enable concurrency.The transition to using
phy_power_onfor CVBS output is a positive change. However, ifmeson_encoder_cvbs_atomic_enableis invoked repeatedly in quick succession (e.g., multiple state changes), ensure the concurrency model is robust to avoid repeated power on calls or toggling. Consider adding a reference count or lock if the design needs it.
285-316: Removal of direct HHI register writes helps maintainability.By eliminating direct toggles of
HHI_VDAC_CNTLfrommeson_venc_init, the code avoids duplicated logic and consolidates DAC control within the new PHY-based approach—the correct step for better layering. Ensure test coverage includes earlier SoCs that used these registers directly.patch/kernel/archive/meson-6.13/0041-phy-amlogic-Add-a-new-driver-for-the-CVBS-DAC-CVBS-P.patch (2)
191-222: Power management approach is clean but verify concurrency.Using
phy_meson_cvbs_dac_power_onandphy_meson_cvbs_dac_power_offwith direct regmap writes is straightforward. If hardware states or usage patterns allow repeated toggles in quick succession (e.g., multiple encoders hooking into the same DAC), confirm concurrency is well-managed. A reference counter might help if repeated toggles are possible.
259-306: Reading NVMEM trimming data.The logic for retrieving and interpreting CVBS-trimming data from eFuses (or fallback) is well-explained. Ensure robust fallback remains if the eFuse is inaccessible. The debug message is a good practice, but consider a warning-level message if incorrectly reading eFuse data has user-facing impacts.
patch/kernel/archive/meson-6.13/0051-net-stmmac-dwmac-meson-Initialize-all-known-PREG_ETH.patch (1)
63-70: Consider adding a comment explaining the chosen default valuesWhile the code correctly initializes the register, it would be helpful to add a brief comment explaining why RMII mode was chosen as the default and why data/descriptor endianness are set to little endian (by clearing those bits).
val = readl(dwmac->reg); + /* Configure for little endian data and descriptors (default) */ val &= ~PREG_ETHERNET_ADDR0_DATA_ENDIANNESS; val &= ~PREG_ETHERNET_ADDR0_DESC_ENDIANNESS; val &= ~PREG_ETHERNET_ADDR0_MII_MODE; + /* Use RMII mode as the default PHY interface */ val |= FIELD_PREP(PREG_ETHERNET_ADDR0_MII_MODE, PREG_ETHERNET_ADDR0_MII_MODE_RMII); val |= PREG_ETHERNET_ADDR0_DIV_EN;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (66)
config/sources/families/include/meson_common.inc(1 hunks)patch/kernel/archive/meson-6.13/0006-ARM-dts-amlogic-meson8b-switch-to-the-new-PWM-contro.patch(1 hunks)patch/kernel/archive/meson-6.13/0016-drm-connector-add-mutex-to-protect-ELD-from-concurre.patch(1 hunks)patch/kernel/archive/meson-6.13/0017-drm-connector-Add-a-way-to-init-add-a-connector-in-s.patch(1 hunks)patch/kernel/archive/meson-6.13/0018-drm-connector-Add-deprecation-notes-for-drm_connecto.patch(1 hunks)patch/kernel/archive/meson-6.13/0019-drm-connector-Warn-if-a-connector-is-registered-adde.patch(1 hunks)patch/kernel/archive/meson-6.13/0020-drm-display-bridge_connector-use-drm_bridge_connecto.patch(1 hunks)patch/kernel/archive/meson-6.13/0021-drm-display-bridge_connector-provide-atomic_check-fo.patch(1 hunks)patch/kernel/archive/meson-6.13/0022-drm-tests-hdmi-handle-empty-modes-in-find_preferred_.patch(1 hunks)patch/kernel/archive/meson-6.13/0023-drm-tests-hdmi-rename-connector-creation-function.patch(1 hunks)patch/kernel/archive/meson-6.13/0024-drm-tests-hdmi-return-meaningful-value-from-set_conn.patch(1 hunks)patch/kernel/archive/meson-6.13/0025-drm-display-hdmi-add-generic-mode_valid-helper.patch(1 hunks)patch/kernel/archive/meson-6.13/0026-ASoC-hdmi-codec-pass-data-to-get_dai_id-too.patch(1 hunks)patch/kernel/archive/meson-6.13/0027-ASoC-hdmi-codec-move-no_capture_mute-to-struct-hdmi_.patch(1 hunks)patch/kernel/archive/meson-6.13/0028-drm-connector-implement-generic-HDMI-audio-helpers.patch(1 hunks)patch/kernel/archive/meson-6.13/0029-drm-bridge-connector-add-support-for-HDMI-codec-fram.patch(1 hunks)patch/kernel/archive/meson-6.13/0030-drm-display-hdmi-implement-hotplug-functions.patch(1 hunks)patch/kernel/archive/meson-6.13/0031-drm-bridge_connector-hook-drm_atomic_helper_connecto.patch(1 hunks)patch/kernel/archive/meson-6.13/0032-ASoC-hdmi-codec-wire-up-the-.prepare-callback-also-f.patch(1 hunks)patch/kernel/archive/meson-6.13/0033-dt-bindings-phy-meson8b-usb2-Add-support-for-reading.patch(1 hunks)patch/kernel/archive/meson-6.13/0034-phy-amlogic-meson8b-usb2-Add-support-for-reading-the.patch(1 hunks)patch/kernel/archive/meson-6.13/0035-phy-amlogic-meson8b-usb2-register-child-USB-connecto.patch(1 hunks)patch/kernel/archive/meson-6.13/0037-usb-common-usb-conn-gpio-Fall-back-to-polling-the-GP.patch(1 hunks)patch/kernel/archive/meson-6.13/0038-ARM-dts-meson-Add-GPIO-controller-capabilities-to-th.patch(1 hunks)patch/kernel/archive/meson-6.13/0039-ARM-dts-meson8b-odroidc1-Enable-the-Micro-USB-OTG-co.patch(1 hunks)patch/kernel/archive/meson-6.13/0040-dt-bindings-phy-Add-bindings-for-the-Amlogic-Meson-C.patch(1 hunks)patch/kernel/archive/meson-6.13/0041-phy-amlogic-Add-a-new-driver-for-the-CVBS-DAC-CVBS-P.patch(1 hunks)patch/kernel/archive/meson-6.13/0042-dt-bindings-display-meson-vpu-Add-the-CVBS-DAC-prope.patch(1 hunks)patch/kernel/archive/meson-6.13/0043-drm-meson-Add-support-for-using-a-PHY-for-the-CVBS-D.patch(1 hunks)patch/kernel/archive/meson-6.13/0045-dt-bindings-clock-meson8b-Add-the-RMII-reference-clo.patch(1 hunks)patch/kernel/archive/meson-6.13/0046-dt-bindings-clock-meson8b-Add-the-Meson8-Ethernet-RM.patch(1 hunks)patch/kernel/archive/meson-6.13/0047-clk-meson-meson8b-Add-the-Ethernet-RMII-clock-tree-o.patch(1 hunks)patch/kernel/archive/meson-6.13/0048-dt-bindings-net-dwmac-meson-Add-the-Ethernet-clock-i.patch(1 hunks)patch/kernel/archive/meson-6.13/0049-net-stmmac-dwmac-meson-Rename-the-SPEED_100-macro.patch(1 hunks)patch/kernel/archive/meson-6.13/0050-net-stmmac-dwmac-meson-Manage-the-ethernet-clock.patch(1 hunks)patch/kernel/archive/meson-6.13/0051-net-stmmac-dwmac-meson-Initialize-all-known-PREG_ETH.patch(1 hunks)patch/kernel/archive/meson-6.13/0052-ARM-dts-meson-meson8-Add-the-clock-input-to-the-Ethe.patch(1 hunks)patch/kernel/archive/meson-6.13/0053-dt-bindings-clock-meson8b-add-the-rtc_32k-oscillator.patch(1 hunks)patch/kernel/archive/meson-6.13/0054-clk-meson-meson8b-Add-the-mpeg_rtc_osc_sel-clock.patch(1 hunks)patch/kernel/archive/meson-6.13/0055-ARM-dts-meson-Add-address-cells-size-cells-and-range.patch(1 hunks)patch/kernel/archive/meson-6.13/0063-ARM-dts-meson8-Add-the-PWM_C-DV9-and-PWM_D-pins.patch(1 hunks)patch/kernel/archive/meson-6.13/0071-dt-bindings-display-meson-vpu-add-support-for-Meson8.patch(1 hunks)patch/kernel/archive/meson-6.13/0072-drm-meson-add-Meson8-Meson8b-Meson8m2-specific-vpu_c.patch(1 hunks)patch/kernel/archive/meson-6.13/0073-drm-meson-Use-24-bits-per-pixel-for-the-framebuffer-.patch(1 hunks)patch/kernel/archive/meson-6.13/0074-drm-meson-Use-a-separate-list-of-supported-formats-f.patch(1 hunks)patch/kernel/archive/meson-6.13/0075-drm-meson-Skip-VIU_OSD1_CTRL_STAT2-alpha-replace-val.patch(1 hunks)patch/kernel/archive/meson-6.13/0076-drm-meson-Enable-the-RGB-to-YUV-converter-on-Meson8-.patch(1 hunks)patch/kernel/archive/meson-6.13/0077-drm-meson-Update-meson_vpu_init-to-work-with-Meson8-.patch(1 hunks)patch/kernel/archive/meson-6.13/0078-drm-meson-Describe-the-HDMI-PHY-frequency-limits-of-.patch(1 hunks)patch/kernel/archive/meson-6.13/0079-drm-meson-Update-the-HDMI-encoder-for-Meson8-8b-8m2.patch(1 hunks)patch/kernel/archive/meson-6.13/0080-drm-meson-Only-set-ycbcr_420_allowed-on-64-bit-SoCs.patch(1 hunks)patch/kernel/archive/meson-6.13/0081-drm-meson-Make-the-HHI-registers-optional-WIP.patch(1 hunks)patch/kernel/archive/meson-6.13/0082-drm-meson-Add-support-for-the-Meson8-8b-8m2-TranSwit.patch(1 hunks)patch/kernel/archive/meson-6.13/0083-drm-meson-Meson8-Meson8b-Meson8m2-VCLK-HACK.patch(1 hunks)patch/kernel/archive/meson-6.13/0084-drm-meson-Enable-support-for-Meson8-Meson8b-Meson8m2.patch(1 hunks)patch/kernel/archive/meson-6.13/0085-ARM-dts-meson-add-the-VPU-WiP.patch(1 hunks)patch/kernel/archive/meson-6.13/0086-ARM-dts-meson8-add-the-HDMI-controller-WiP.patch(1 hunks)patch/kernel/archive/meson-6.13/0087-ARM-dts-meson8-Add-the-shared-CMA-dma-memory-pool.patch(1 hunks)patch/kernel/archive/meson-6.13/0088-ARM-dts-meson8-add-the-AO-CEC-controller-WiP.patch(1 hunks)patch/kernel/archive/meson-6.13/0089-ARM-dts-meson8b-add-the-HDMI-controller-WiP.patch(1 hunks)patch/kernel/archive/meson-6.13/0090-ARM-dts-meson8b-add-the-AO-CEC-controller-WiP.patch(1 hunks)patch/kernel/archive/meson-6.13/0092-ARM-dts-meson8b-odroid-c1-enable-HDMI-for-the-Odroid.patch(1 hunks)patch/kernel/archive/meson-6.13/generic-Revert-mmc-core-Set-HS-clock-speed-before-sending-HS-CMD13.patch(1 hunks)patch/kernel/archive/meson-6.13/generic-Revert-pwm-meson-modify-and-simplify-calculation-in-.patch(1 hunks)patch/kernel/archive/meson-6.13/onecloud-0001-add-dts.patch(1 hunks)patch/kernel/archive/meson-6.13/onecloud-0002-dts-Support-HDMI.patch(1 hunks)
🔇 Additional comments (206)
config/sources/families/include/meson_common.inc (1)
35-35:✅ Verification successful
Kernel version updated for edge branch
The change updates the kernel version from 6.10 to 6.13 for the Meson edge branch, aligning with the PR objective. While the change is straightforward, note that there were suggestions in PR discussions about potentially using 6.12 first (which is an LTS version) before moving to 6.13.
🏁 Script executed:
#!/bin/bash # Check if there are any known issues with kernel 6.13 for Meson platforms echo "Checking for potential compatibility issues with kernel 6.13 for Meson platforms..." git grep -l "KERNEL_MAJOR_MINOR.*6\.13" -- config/ | xargs grep -l "meson" echo "Checking for recent kernel version patterns across other platforms..." git grep -l "KERNEL_MAJOR_MINOR.*6\.1[0-3]" -- config/sources/families/Length of output: 1143
Kernel Version Update Confirmed for Meson Edge Branch
- Verified that
config/sources/families/include/meson_common.incis correctly updated withdeclare -g KERNEL_MAJOR_MINOR="6.13".- Consistency is maintained as a similar update appears in
config/sources/families/include/meson64_common.inc.- Note: Although prior discussions suggested considering kernel 6.12 (an LTS version), the current PR objective of updating to 6.13 for the edge branch is correctly implemented.
patch/kernel/archive/meson-6.13/0078-drm-meson-Describe-the-HDMI-PHY-frequency-limits-of-.patch (3)
7-10: Clear documentation of Meson8b HDMI limitationsThe patch accurately documents the HDMI PHY frequency limitations for Meson8b SoCs, which is important for ensuring proper display functionality. This explanation helps clarify why the frequency limit is being set despite the hardware technically supporting higher frequencies.
26-30: Improved documentation of HDMI frequency limitationsThe expanded comments provide clearer context about both the GXL S805X/S805Y and Meson8b (S805) HDMI limitations, which is valuable for future maintainers.
37-37:✅ Verification successful
Added Meson8b SoC ID to frequency limitation table
This change properly adds the Meson8b (S805) SoC ID to the list of SoCs with HDMI PHY frequency limitations, which should help address the HDMI issues mentioned in the PR feedback.
🌐 Web query:
Are there known issues with HDMI output on Amlogic Meson8b (S805) SoCs with Linux kernel 6.13?💡 Result:
HDMI output issues on Amlogic Meson8b (S805) systems with Linux kernel 6.13 are documented in community reports and technical discussions. Here's a breakdown of the current state:
Mainline Kernel Compatibility Challenges
- The Meson8b (S805) architecture has limited HDMI support in modern kernels. While HDMI output functionality was partially achieved in kernel 6.1 via community efforts, it remains experimental and unreliable for many displays[4][16].
- Kernel 6.13 inherits these limitations, as recent code changes focus on newer Amlogic SoCs (e.g., S905X3, S922X) rather than Meson8b[14].
Known Issues
No Signal/Black Screen:
Users report HDMI failing to initialize, often with error logs indicatingmeson-dw-hdmidriver incompatibility[2][16]. Example failure:[ 7.236152] meson-drm: failed to bind hdmi-tx (error -19) [ 7.244524] meson-drm: Couldn't bind all componentsResolution Constraints:
Even when HDMI partially works, resolutions are often limited to 1080p or 720p, with autodetection frequently failing. Manual configuration viauEnv.txtor kernel parameters (e.g.,video=HDMI-A-1:1920x1080M@60) is often required[1][12].Audio Unsupported:
HDMI audio support for Meson8b is absent in mainline Linux kernels due to missing .prepare() callbacks in the AIU (Audio Input Unit) driver[17].Community Workarounds
- Custom Kernels: Projects like Armbian and LibreELEC use patched kernels (e.g., backported DRM/meson drivers) but still report HDMI instability on S805 devices[4][12].
- DTB Tweaks: Forcing specific device-tree configurations (e.g.,
meson8b-mxq.dtb) sometimes resolves initialization issues but doesn’t guarantee functionality[16].Hardware-Specific Limitations
- Older TV boxes using S805 often lack proper EDID support, confusing HDMI handshake protocols. This exacerbates compatibility problems with modern monitors[12][14].
For developers, HDMI support for Meson8b remains a low priority in upstream Linux, with active efforts focusing on newer Amlogic chips. Users needing reliable HDMI output on S805 hardware are advised to use vendor-specific Android firmware or legacy kernels (e.g., 3.10–4.9)[10][12].
Citations:
- 1: https://forums.androidcentral.com/threads/hdmi-no-signal-on-new-android-mxq-ott-box.632262/
- 2: 外接HDMI 显示器，没有图像输出 ophub/amlogic-s9xxx-armbian#1312
- 3: https://launchpad.net/ubuntu/+source/linux-aws/+changelog?batch=75&memo=75&start=75
- 4: https://forum.armbian.com/topic/28400-latest-armbian-for-s805-tv/
- 5: https://forum.endeavouros.com/t/solved-no-sound-dp-hdmi-battlemage/67889
- 6: http://build.khadas.com/khadas/fenix/logs/build_test.1624590577.log
- 7: https://xdaforums.com/t/help-with-soft-bricked-mxq-s805-blue-light-but-no-hdmi-out-black-screen.3553026/
- 8: https://www.opennet.ru/kernel/6.13.html
- 9: https://gbmc.googlesource.com/linux/+/619d996c86421da1057d589123a28e2da0bf0785%5E2..619d996c86421da1057d589123a28e2da0bf0785/
- 10: https://www.youtube.com/watch?v=2WbgH3RgrFo
- 11: https://forum.manjaro.org/t/linux-odroid-6-13-1/174399
- 12: https://www.rigacci.org/wiki/doku.php/doc/appunti/hardware/mxq_s805
- 13: https://www.collabora.com/news-and-blog/news-and-events/kernel-613-a-flawless-end-of-the-year.html
- 14: https://linux-meson.com/hardware.html
- 15: https://patchwork.kernel.org/comment/26308366/
- 16: https://github.com/hexdump0815/imagebuilder/blob/main/systems/amlogic_m8/readme.md
- 17: https://patchwork.kernel.org/comment/26184085/
- 18: https://www.youtube.com/watch?v=GO9SygolVmE
- 19: https://forum.libreelec.tv/thread/21798-meson-8-lives/?pageNo=5
- 20: https://patchwork.kernel.org/comment/22217939/
HDMI PHY Frequency Limitation Update – Verified
The patch correctly adds the Meson8b (S805) entry to the HDMI PHY frequency limitations table. Community reports and technical discussions confirm that HDMI output on Amlogic Meson8b (S805) systems with Linux kernel 6.13 is fraught with reliability issues. Explicitly listing this SoC in the frequency limitation table helps safeguard against oversights in hardware-specific frequency management, aligning the code with the known constraints on this platform.
- The addition of
{ .soc_id = "Meson8b (S805)", }is appropriate given the documented limitations.- This update is consistent with community feedback and known kernel challenges for HDMI on S805 hardware.
Approved as-is.
patch/kernel/archive/meson-6.13/0053-dt-bindings-clock-meson8b-add-the-rtc_32k-oscillator.patch (3)
7-8: Clear documentation of the RTC oscillator functionThe commit message clearly explains the purpose of adding the rtc_32k oscillator input - the CLK81 tree can be driven off the 32kHz oscillator connected to the SoC's RTC32K pads.
23-24: Increased maximum clock inputsThe change increases the maximum number of clock inputs from 4 to 5, allowing for the addition of the rtc_32k oscillator.
32-32: Added rtc_32k as a valid clock nameThe rtc_32k oscillator is now properly added to the list of valid clock names in the device tree bindings.
patch/kernel/archive/meson-6.13/0049-net-stmmac-dwmac-meson-Rename-the-SPEED_100-macro.patch (3)
6-8: Clear explanation of the macro renamingThe commit message clearly explains the reason for renaming the SPEED_100 macro - to make its relationship with the PREG_ETHERNET_ADDR0 register explicit.
24-25: Improved macro name and documentationThe macro has been appropriately renamed from ETHMAC_SPEED_100 to PREG_ETHERNET_ADDR0_SPEED_100, making its association with the register clear. The added comment explains what the bit actually does (divides the input clock by 20 or 2 depending on the value), which improves code documentation.
34-34: Updated references to renamed macroReferences to the renamed macro have been consistently updated throughout the code.
Also applies to: 38-38
patch/kernel/archive/meson-6.13/0032-ASoC-hdmi-codec-wire-up-the-.prepare-callback-also-f.patch (1)
35-42: Properly connected .prepare callback for SPDIF DAI operationsThis change correctly wires up the
.preparecallback for SPDIF DAI operations, ensuring consistency with the I2S input code-path that already had this callback. The addition is necessary because the DRM HDMI audio framework requires access to HDMI audio infoframe contents during the prepare phase, which aren't available during the earlierhw_paramscallback.The implementation looks correct and follows the same pattern established for the I2S DAI operations.
patch/kernel/archive/meson-6.13/0080-drm-meson-Only-set-ycbcr_420_allowed-on-64-bit-SoCs.patch (1)
22-28: Correctly restricted YCbCr 420 support to compatible hardwareThe change correctly implements a hardware compatibility check to limit the
ycbcr_420_allowedflag to only 64-bit SoCs that actually support this feature. This prevents enabling YUV420 functionality on 32-bit SoCs (M8, M8B, M8M2) that don't have the necessary hardware support.The conditional logic is correctly implemented and follows the pattern used elsewhere in the codebase for hardware compatibility checks.
patch/kernel/archive/meson-6.13/0075-drm-meson-Skip-VIU_OSD1_CTRL_STAT2-alpha-replace-val.patch (1)
29-46: Prevented invalid register writes on unsupported hardwareThis change correctly prevents writing to register bits that don't exist on Meson8/Meson8b/Meson8m2 SoCs. The
replaced_alpha_en(bit 14) andreplaced_alpha(bits 13:6) fields in theVIU_OSD1_CTRL_STAT2andVIU_OSD2_CTRL_STAT2registers aren't implemented on these older SoCs.The implementation uses proper compatibility checks to skip these operations only on the affected hardware platforms.
patch/kernel/archive/meson-6.13/0076-drm-meson-Enable-the-RGB-to-YUV-converter-on-Meson8-.patch (1)
23-30: Properly enabled RGB to YUV converter for older Meson SoCsThis change correctly extends the RGB to YUV converter support to the Meson8, Meson8b, and Meson8m2 platforms, similar to what was already done for GXBB. Setting the
OSD_OUTPUT_COLOR_RGBbit (VIU_OSD1_BLK0_CFG_W0[7]) to 1 enables the RGB to YUV converter on these platforms.The implementation uses proper compatibility checks and the updated comment accurately reflects that this applies to "GXBB and earlier" platforms.
patch/kernel/archive/meson-6.13/0046-dt-bindings-clock-meson8b-Add-the-Meson8-Ethernet-RM.patch (1)
19-26: Looks good: Clock ID constants added for Meson8 Ethernet (RMII)The addition of these four clock identifier constants is well-structured and follows the existing pattern in the header file. These constants are crucial for proper clock management of the Ethernet controller on Meson8 SoCs, with a logical hierarchy (selector, divider, phase, and main clock).
patch/kernel/archive/meson-6.13/0019-drm-connector-Warn-if-a-connector-is-registered-adde.patch (1)
31-37: Implementation of TODO completed: Added warning for incorrect connector registrationThe patch successfully implements the previously planned enhancement mentioned in the TODO comment. The use of
drm_WARN_ONis appropriate and will help catch cases where drivers incorrectly initialize MST connectors without usingdrm_connector_dynamic_init().patch/kernel/archive/meson-6.13/0071-dt-bindings-display-meson-vpu-add-support-for-Meson8.patch (2)
22-25: Added support for additional Meson VPU variantsThe addition of Meson8, Meson8b, and Meson8m2 to the compatible list correctly extends hardware support for these SoC variants, which aligns with the PR's goal of updating the Meson edge to the 6.13 kernel.
Note that the commit message is marked as "WiP" (Work in Progress). Please verify that this patch is complete and properly tested before merging.
27-28: Added minimum item count for reg propertyAdding
minItems: 1is a good enhancement that ensures at least one register address is provided for the VPU, making the binding requirements more explicit.patch/kernel/archive/meson-6.13/0087-ARM-dts-meson8-Add-the-shared-CMA-dma-memory-pool.patch (1)
24-30: Added shared CMA pool for 4K HDMI supportThe implementation of a shared CMA DMA memory pool with 256MiB size is appropriate for supporting 4K HDMI modes. The configuration includes all necessary properties (
reusable, proper alignment, andlinux,cma-default), making it a well-structured addition to the device tree.patch/kernel/archive/meson-6.13/0045-dt-bindings-clock-meson8b-Add-the-RMII-reference-clo.patch (2)
24-25: ExpandmaxItemsto accommodate the new RMII clock input.Increasing
maxItemsfrom 3 to 4 is correct for including one additional clock input. This aligns with the subsequent addition of thermii_clkentry.
33-33: Add the newrmii_clkreference.Adding the
rmii_clkproperty ensures proper documentation for the RMII reference clock. This is consistent with the hardware requirements for external 50MHz RMII references.patch/kernel/archive/meson-6.13/0073-drm-meson-Use-24-bits-per-pixel-for-the-framebuffer-.patch (3)
28-28: Includedrm_fourcc.hheader.Importing
<drm/drm_fourcc.h>is necessary to leverage theDRM_FORMAT_*constants. No issues noted.
36-53: Implement dedicated setup for older SoCs lacking alpha channel.The new
meson_drm_client_setupfunction properly checks SoC compatibility and usesDRM_FORMAT_RGB888for Meson8/8b/8m2. This cleanly addresses alpha handling limitations on older hardware.
63-63: Replace genericdrm_client_setupcall with SoC-specific logic.Switching to
meson_drm_client_setup(priv)ensures that older SoCs are configured with the correct framebuffer format. This is a logical substitution.patch/kernel/archive/meson-6.13/0063-ARM-dts-meson8-Add-the-PWM_C-DV9-and-PWM_D-pins.patch (2)
24-30: Define thepwm_c_dv9pin group.Introducing the
pwm_c_dv9block, complete with bias disable and function assignment, aligns with boards that rely on PWM regulators. This is a straightforward addition to the pinctrl configuration.
32-38: Add thepwm_dpin group.The
pwm_dpin group mirrors the approach used forpwm_c_dv9, enabling PWM-based regulation on Meson8m2 boards without a PMIC. No issues found.patch/kernel/archive/meson-6.13/0072-drm-meson-add-Meson8-Meson8b-Meson8m2-specific-vpu_c.patch (1)
22-34: VPU compatible enum updated with older hardware supportThis change adds Meson8, Meson8b, and Meson8m2 specific entries to the VPU compatible enumeration, allowing the driver to handle quirks for these earlier hardware generations. The existing entries are appropriately renumbered to accommodate the new ones.
This is a clean approach to extending the enumeration while maintaining compatibility with existing code that references these enum values.
patch/kernel/archive/meson-6.13/0088-ARM-dts-meson8-add-the-AO-CEC-controller-WiP.patch (1)
21-27: HDMI CEC pin configuration looks goodThe pin configuration for HDMI CEC with pull-up bias is correctly defined.
patch/kernel/archive/meson-6.13/0054-clk-meson-meson8b-Add-the-mpeg_rtc_osc_sel-clock.patch (3)
27-43: New clock structure looks goodThe implementation of the
meson8b_mpeg_rtc_osc_selclock structure is well-defined with proper register offset, mask, shift values, and parent clock data.
45-60: Clock mux table and parent updates are correctThe modifications to the
mux_table_clk81array and themeson8b_mpeg_clk_selstructure properly incorporate the new clock as a parent, increasing the parent count from 3 to 4.
63-104: Clock registration in HW clocks arrays is completeThe new clock is correctly registered in all relevant hardware clock arrays (
meson8_hw_clks,meson8b_hw_clks,meson8m2_hw_clks, andmeson8b_clk_regmaps), and a proper clock ID is defined in the header file.patch/kernel/archive/meson-6.13/0090-ARM-dts-meson8b-add-the-AO-CEC-controller-WiP.patch (1)
21-27: HDMI CEC pin configuration looks goodThe pin configuration for HDMI CEC with pull-up bias is correctly defined, using the appropriate group name (
hdmi_cec_1) and function name (hdmi_cec).patch/kernel/archive/meson-6.13/0018-drm-connector-Add-deprecation-notes-for-drm_connecto.patch (4)
7-14: Well-documented deprecation notice for connector APIThe commit message clearly explains that only dynamic (MST) connectors should be manually registered/unregistered using the dedicated functions, while static connectors are handled automatically by the DRM core. This documentation update is an important step before removing functionality.
39-42: Good clarification of proper connector registration approachThe updated documentation properly clarifies that drivers shouldn't call
drm_connector_register()directly. The distinction between static connectors (automatically handled by DRM core) and dynamic connectors (which should use the dedicated API) helps prevent misuse.
47-48: Clear deprecation notice for existing driver implementationsThe addition of this note is valuable as it clearly states that existing usages in drivers should already be no-ops and are scheduled for removal. This helps driver maintainers prepare for eventual API removal.
60-67: Consistent update of unregister function documentationThis change provides parallel documentation updates for the unregister function, maintaining consistency with the register function documentation. The clear explanation of proper usage helps developers understand the intended API usage pattern.
patch/kernel/archive/meson-6.13/0077-drm-meson-Update-meson_vpu_init-to-work-with-Meson8-.patch (1)
47-79: Improved hardware-specific initialization for Meson8 series SoCsThe changes implement a more appropriate initialization path for Meson8, Meson8b, and Meson8m2 SoCs. This aligns with vendor U-Boot behavior by enabling all memory power domains for these specific platforms while preserving the original initialization logic for other platforms.
The code restructuring is clean, with proper indentation and improved readability of the original code path. The conditional check uses the appropriate
meson_vpu_is_compatible()function to detect the specific SoC types.patch/kernel/archive/meson-6.13/0021-drm-display-bridge_connector-provide-atomic_check-fo.patch (2)
28-38: Good implementation of atomic_check for HDMI bridgesThis function effectively reduces boilerplate code by centralizing the atomic check logic for HDMI bridges. It conditionally applies the HDMI check only when the bridge connector is an HDMI bridge, which is a clean approach.
45-45: Proper integration with connector helper functionsThe addition of the atomic_check function pointer to the bridge connector helper functions structure completes the implementation by properly integrating the new function into the existing framework.
patch/kernel/archive/meson-6.13/generic-Revert-mmc-core-Set-HS-clock-speed-before-sending-HS-CMD13.patch (4)
19-26: Reverted timing of HS clock speed settingThis change reverts the approach of setting bus speed and timing before sending CMD13, returning to setting the clock after the status switch. Without more context, it's difficult to determine if this reversion addresses specific hardware compatibility issues.
Could you provide more context on why this reversion was necessary? Were there specific hardware issues observed with the previous implementation that necessitated this change?
30-31: Restored original clock setting approachAdded back the explicit
mmc_set_clock()call after the status switch, which was likely the original implementation before the commit being reverted. This ensures the clock is properly set after the timing adjustment.
49-58: Simplified HS200 timing sequenceRemoved the explicit clock setting before switching to HS200 timing. This simplification returns to the original approach that likely worked better with certain hardware configurations.
66-70: Streamlined error handlingError handling for the
-EBADMSGcase has been simplified to only reset the timing without adjusting the clock. This is consistent with the removal of the clock adjustment code earlier in the function.patch/kernel/archive/meson-6.13/0092-ARM-dts-meson8b-odroid-c1-enable-HDMI-for-the-Odroid.patch (4)
22-31: HDMI connector node looks correct.
The definition of thehdmi-connectornode and link tohdmi_tx_tmds_outaligns with standard HDMI connector setup. Good job enabling it in the DTS.
82-85: Audio Interface Unit (AIU) enabling is standard.
Marking&aiustatus as "okay" is necessary for HDMI audio. No issues found.
93-103: HDMI transmitter port references are correctly configured.
Enabling&hdmi_txand linking&hdmi_tx_tmds_portto the connector endpoint implements the standard pipeline for HDMI video and audio signals.
40-73:✅ Verification successful
Sound node configuration is coherent but verify clock IDs.
The assigned clock IDs and rates (MPLL0 and MPLL1) appear correct for ODROID-C1. Ensure these clocks exist on this SoC and are stable at the configured frequencies.
🏁 Script executed:
#!/bin/bash # Description: Check the presence of MPLL0 and MPLL1 references in meson8b clock definitions rg -A 5 'MPLL0|MPLL1'Length of output: 16488
Clock IDs and rates verified for ODROID-C1.
The sound node configuration in this patch is consistent with other DTS files—using CLKID_MPLL0 and CLKID_MPLL1 with clock rates of 294912000 and 270950400, respectively. Please ensure during hardware validation that these clocks are indeed available and stable on the ODROID-C1.patch/kernel/archive/meson-6.13/onecloud-0002-dts-Support-HDMI.patch (5)
19-28: HDMI connector node definition looks good.
The HDMI connector node linking tohdmi_tx_tmds_outis correctly defined, matching typical device tree conventions for display out.
68-71: Activating AIU for audio.
Settingstatus = "okay"for&aiuis consistent with enabling on-chip audio IP.
79-83: HDMI transmitter node setup is standard.
Enabling&hdmi_txand specifying pinctrl for hotplug and I2C lines ensures proper HDMI behavior.
85-89: TMDS port linkage is correct.
Thehdmi_tx_tmds_portreferences the connector endpoint correctly, completing the HDMI pipeline.
30-59:❓ Verification inconclusive
Sound node well defined; verify clock existence.
Similar to the ODROID-C1 DTS, confirm that the MPLL0 and MPLL1 clock references are valid for OneCloud.
🏁 Script executed:
#!/bin/bash # Description: Check presence of MPLL0/MPLL1 for the OneCloud board rg -A 5 'MPLL0|MPLL1'Length of output: 16488
Verify CLK References for OneCloud DTS
The sound node is correctly defined, but please confirm that the clock references
CLKID_MPLL0andCLKID_MPLL1actually exist within the OneCloud board's clock configuration. Notably, these identifiers are used similarly in other DTS patches (e.g., for the ODROID-C1), so ensure OneCloud’s DTS either defines them or inherits them appropriately.patch/kernel/archive/meson-6.13/0050-net-stmmac-dwmac-meson-Manage-the-ethernet-clock.patch (2)
31-49: Structure addition for ethernet clock is appropriate.
Declaringstruct clk *ethernet_clk;inmeson_dwmacis a standard approach for SoCs providing a dedicated Ethernet clock.
73-81: Ethernet clock exit routine is straightforward.
Simply disabling and unpreparing the clock is appropriate.patch/kernel/archive/meson-6.13/0086-ARM-dts-meson8-add-the-HDMI-controller-WiP.patch (6)
77-84: No concerns with hpd pin configuration.The
hdmi_hpd_pinsblock follows typical pinctrl usage and should work as expected.
85-91: I2C pin configuration appears standard.The added
hdmi_i2c_pinsnode references common I2C pin usage, which is consistent with typical HDMI DDC lines.
93-99: Confirm removal ofbias-disable.Removing
bias-disablefrom thepwm_c_dv9_pinsmight alter pindrive behavior. Ensure that this change will not cause undesired side effects in PWM operation.
114-120: HDMI PHY integration looks good.The
hdmi_tx_phynode is defined with the expected compatibility, clock, and PHY cell properties for Meson8-based SoCs.
54-70:✅ Verification successful
Ensure port endpoints are consistent.
The HDMI TX port definitions under the VPU node appear correct. Verify that the
hdmi_tx_outandhdmi_tx_inlabels match across all relevant nodes so that the display pipeline is properly chained.
🏁 Script executed:
#!/bin/bash rg -A 5 'remote-endpoint.*hdmi_tx_in'Length of output: 4608
Port Endpoints Consistency Verified
The HDMI TX port definition in the VPU node correctly uses
<&hdmi_tx_in>, and a search across multiple patches confirms that thehdmi_tx_inlabel is consistently referenced. No further changes are needed regarding endpoint consistency.
21-52:✅ Verification successful
Check address space and compatibility.
The addition of
hdmi_tx: hdmi-tx@42000looks standard for a Meson HDMI TX node, but please double-check that the address region<0x42000 0xc>does not conflict with other device nodes and that theamlogic,meson8-hdmi-txcompatible is correct per the binding documentation.You can run the following script to locate any overlapping addresses or definitions of
<0x42000>in the DTS files:
🏁 Script executed:
#!/bin/bash rg '0x42000' -A 5Length of output: 11382
HDMI TX Node Device Tree Settings Verified
- The address region
<0x42000 0xc>is consistently used across similar Meson patches with no overlapping or conflicting definitions observed.- The compatible string
"amlogic,meson8-hdmi-tx"matches the expected binding for Meson8 devices based on related DTS changes.All indications are that the configuration is standard and correctly implemented.
patch/kernel/archive/meson-6.13/onecloud-0001-add-dts.patch (5)
8-21: Makefile update for new DTB.Adding
meson8b-onecloud.dtbto the build target is straightforward and necessary for building the new device tree.
27-80: Validate button interrupt and power sequencing.Overall definitions under
/such as memory, power sequence, and the reset button look standard. Please confirm the interrupt line (interrupts = <5 IRQ_TYPE_LEVEL_LOW>) for the reset button is correct for your hardware.
82-198: Check LED triggers and regulator voltages.The GPIO LEDs and fixed regulators (12V, 5V, 3.3V, 1.8V, DDR) are configured in a typical manner. Ensure the specified default voltages match the board requirements and that the LED triggers (e.g., "mmc1", "usb-host") are correct for real usage.
201-341: UART, CPU, and pinctrl configurations.Enabling
&uart_AO,&pwm_cd, setting up CPU supply, SARADC, and GPIO line naming all appear consistent with Meson8B. No issues noticed.
343-440: Peripheral connections: SD, Ethernet, USB, IR.The networking and USB configurations look properly declared. Confirm that the MDIO reset (GPIOH_4) and Ethernet PHY interrupts (GPIOH_3) align with your board’s wiring. Everything else seems functional.
patch/kernel/archive/meson-6.13/0084-drm-meson-Enable-support-for-Meson8-Meson8b-Meson8m2.patch (2)
22-32: Structs added for new SoCs.Defining
meson_drm_m8_data,meson_drm_m8b_data, andmeson_drm_m8m2_dataextends support to these SoCs. The usage is consistent with the existing pattern.
41-46: New device-tree matches are consistent.Adding entries for
"amlogic,meson8-vpu","amlogic,meson8b-vpu", and"amlogic,meson8m2-vpu"allows the DRM driver to recognize and apply the correct quirks for each platform.patch/kernel/archive/meson-6.13/0037-usb-common-usb-conn-gpio-Fall-back-to-polling-the-GP.patch (4)
32-48: Validate concurrency safety when scheduling delayed work.
These new functions queue delayed work items for polling. Ensure there is no race between scheduling and canceling work in suspend/resume paths. This appears partially addressed bycancel_delayed_work_sync(&info->dw_det), but consider double-checking if there's any possibility that a queued poll might re-trigger unexpectedly after suspend.
80-106: Fallback to polling - ensure minimal overhead on interrupt failure.
When ID GPIO interrupts cannot be requested, the fallback is a periodic poll. This is appropriate. Double-check any debug logs or warnings to ensure they reflect the fallback reason and won't flood logs unnecessarily.
108-134: ID and VBUS fallback behaviors differ.
Both ID and VBUS are handled similarly here, but confirm that they share identical fallback requirements. For instance, if ID is interrupted but VBUS is not, or vice versa, you may only need partial fallback. Verify that partial fallback does not lead to confusion in power or role detection states.
136-141: Good call canceling delayed work in suspend.
Canceling the polling ensures no stale work runs while suspended. Remember to re-initiate the poll in the resume path for bridging scenarios unless the system re-establishes IRQ context seamlessly.patch/kernel/archive/meson-6.13/0089-ARM-dts-meson8b-add-the-HDMI-controller-WiP.patch (5)
21-52: Confirm memory size for HDMI controller registers.
The DTS nodehdmi-tx@42000usesreg = <0x42000 0xc>. Verify that 12 bytes is correct for this controller block’s registers, as some HDMI controllers require larger mapped regions.
21-52: Separate “vpu venc input” and “TMDS Output” ports are well-defined.
This approach matches the standard binding for HDMI on Meson SoCs. No issues spotted.
54-78: Ensure external references are correct.
In the VPU node, the port@1 references&hdmi_tx_in. Double-check for consistent connectivity with thehdmi_tx_venc_port: port@0to ensure no mismatch in link references.
84-99: I/O pin configuration matches the “hdmi” function.
The pin groups and bias settings appear valid for HDMI HPD/I2C. Just confirm they align with your SoC’s data sheet (particularly if different boards have varying pin mux needs).
108-114: Check the PHY clock references.
hdmi_tx_phy: hdmi-phy@3a0referencesCLKID_HDMI_PLL_HDMI_OUT. Ensure that other clock lines (like SYS or CTL clocks) aren’t needed for stable operation.patch/kernel/archive/meson-6.13/0027-ASoC-hdmi-codec-move-no_capture_mute-to-struct-hdmi_.patch (19)
32-37: Migrate no_capture_mute from ops to platform data
This chunk removes.no_capture_mutefrom theit66121_audio_codec_ops, aligning with the broader move to store platform-specific flags inhdmi_codec_pdata. It helps clarify ownership and is consistent with the rest of the patch.
39-45: Add no_capture_mute to it66121's hdmi_codec_pdata
Complements the removal from the ops structure. Ensures platform-specific behavior stays intact within the new data structure.
52-57: Same pattern: Removing .no_capture_mute from sii902x_audio_codec_ops
59-65: Same pattern: Adding .no_capture_mute to sii902x's hdmi_codec_pdata
72-77: Same pattern: Removing .no_capture_mute from Exynos hdmi_codec_ops
80-85: Same pattern: Adding .no_capture_mute to Exynos hdmi_codec_pdata
92-97: Same pattern: Removing .no_capture_mute from tda998x_audio_codec_ops
100-105: Same pattern: Adding .no_capture_mute to tda998x hdmi_codec_pdata
112-117: Same pattern: Removing .no_capture_mute from mtk_dp audio_codec_ops
120-125: Same pattern: Adding .no_capture_mute to mtk_dp hdmi_codec_pdata
132-137: Same pattern: Removing .no_capture_mute from mtk_hdmi audio_codec_ops
140-145: Same pattern: Adding .no_capture_mute to mtk_hdmi hdmi_codec_pdata
152-157: Same pattern: Removing .no_capture_mute from rockchip cdn-dp audio_codec_ops
160-165: Same pattern: Adding .no_capture_mute to rockchip hdmi_codec_pdata
172-177: Same pattern: Removing .no_capture_mute from sti hdmi audio_codec_ops
180-185: Same pattern: Adding .no_capture_mute to sti hdmi_codec_pdata
189-199: Remove no_capture_mute bit field from hdmi_codec_ops
Shifting this field out of ops clarifies the distinction between frontend operations and platform-specific configuration.
202-207: Add no_capture_mute bit field to hdmi_codec_pdata
Centralizing this flag in the platform data structure helps accommodate varying hardware needs.
214-219: Replace usage from ops->no_capture_mute to hcd.no_capture_mute
Ensures code references the newly introduced field consistently.patch/kernel/archive/meson-6.13/0030-drm-display-hdmi-implement-hotplug-functions.patch (7)
33-34: Select the HDMI audio helper
This ensures integration with the newly introduced HDMI audio frameworks.
45-45: Include the drm_hdmi_audio_helper header
Needed for audio plug/unplug notifications.
55-78: Implement drm_atomic_helper_connector_hdmi_update
This function reads EDID data for the connector and notifies HDMI audio if the sink is connected or disconnected. Consider adding a log or fallback behavior ifdrm_edid_readfails or returns NULL.
88-93: Add drm_atomic_helper_connector_hdmi_hotplug
A straightforward helper for connector hotplug events that delegates to hdmi_update logic.
96-109: Add drm_atomic_helper_connector_hdmi_force
Provides a force callback implementation that also updates EDID and audio status. Clean approach.
110-132: Declare hotplug/force functions in drm_hdmi_state_helper.h
The new API surfaces these helpers, making them available to HDMI connector implementations.
133-164: Add custom read_edid callback to struct drm_connector_hdmi_funcs
Offers driver-specific EDID retrieval when standard DDC access is not available. Approach is extensible.patch/kernel/archive/meson-6.13/0079-drm-meson-Update-the-HDMI-encoder-for-Meson8-8b-8m2.patch (7)
31-38: Refactor ycrcb_map initialization
Removing the fixed assignment lets the code pick the correct format later based on SoC detection and bus format.
46-63: Conditional mapping for Meson8/8b/8m2 vs. newer SoCs
Ensures the ycrcb_map is set correctly for each generation. Please verify that fallback toVPU_HDMI_OUTPUT_CBYCRis correct for all non-M8 SoCs.
81-95: Skip writes to VPU_HDMI_FMT_CTRL on older SoCs
Preventing writes to a non-existent register avoids invalid hardware accesses.
103-107: New meson8_encoder_hdmi_out_bus_fmts array
Defines supported bus formats for older 32-bit SoCs, improving clarity of per-SoC constraints.
108-112: New meson_gx_encoder_hdmi_out_bus_fmts array
Separating arrays by SoC type ensures we only advertise valid bus formats.
125-132: Choosing the array based on SoC compatibility
Safe approach that ensures correct format usage for legacy vs. newer SoCs.
135-142: Refactor loop to use out_bus_fmts
Improves maintainability by referencing a single pointer to the chosen format array.patch/kernel/archive/meson-6.13/0074-drm-meson-Use-a-separate-list-of-supported-formats-f.patch (2)
64-72: Validate the detection logic for older SoC compatibility checks.The condition checks for
meson_vpu_is_compatible(priv, VPU_COMPATIBLE_M8...). Ensure that this condition precisely captures all older SoC variants that cannot handle X components and that no newly introduced SoCs inadvertently match this path. A mismatch might cause functional regressions on newer SoCs.
74-81: Confirm fallback behavior for format modifiers.When initializing the universal plane, confirm that all relevant format modifiers are properly applied for each SoC family. If a SoC does not support certain AFBC or tiling configurations, ensure the fallback logic gracefully avoids unsupported modifiers.
patch/kernel/archive/meson-6.13/0031-drm-bridge_connector-hook-drm_atomic_helper_connecto.patch (2)
51-60: Validate forced HDMI connector state transitions.The
drm_bridge_connector_forcefunction appropriately callsdrm_atomic_helper_connector_hdmi_force, but ensure corner cases (e.g., connector forced to "on" when no hardware is physically attached) are gracefully handled. Testing forced states will help avoid unexpected side effects or kernel warnings.
91-103: Handle incomplete or partially invalid EDID data.
drm_bridge_connector_read_edidreturnsNULLif no bridge is present. Consider verifying EDID structure integrity, so that partial data doesn’t cause connector misconfiguration.patch/kernel/archive/meson-6.13/0055-ARM-dts-meson-Add-address-cells-size-cells-and-range.patch (4)
23-30: Confirm non-overlapping address ranges.Adding
#address-cells,#size-cells, andrangestohhiis beneficial for structured DTS referencing. Verify that child nodes do not exceed the 0x400 range specified. Overlapping ranges can lead to hardware resource conflicts.
41-45: Ensure correct memory mapping for clock-controller@0.Defining
reg = <0x0 0x39c>is crucial for referencing the correct offset withinhhi. Double-check that the final size (0x39c) is accurate for the entire clock-controller region. Misalignment may cause read/write errors on certain registers.
51-55: Maintain consistency in naming power controller nodes.Using
pwrc: power-controller@100is a good practice. Continue consistent naming (e.g.,clock-controller@0) for all SoC variants to avoid confusion when referencing them in board-specific DTS files.
78-80: Check for adequate offset in @100 region.The
reg = <0x100 0x10>property indicates only 0x10 bytes allocated for the power controller. Confirm this block suffices for all required registers and future expansions. Revisit if new features exceed the 0x10 region.patch/kernel/archive/meson-6.13/0085-ARM-dts-meson-add-the-VPU-WiP.patch (4)
4-7: Confirm WIP readiness.The subject line and commit message explicitly call this a “WiP” patch. Please verify that this code is sufficiently tested and ready for upstream inclusion or production environments.
46-110: Ensure consistency for VPU node properties.The
vpu@100000node includes assigned clocks, resets, and phys references. Confirm that:
- The references (e.g.
&clkc) match existing clock and reset controllers in the rest of the system.- The assigned-clock parents for
VCLK_IN_SELandVCLK2_IN_SELare valid for Meson8 SoCs.
117-126: Revisit “status = okay” for cvbs_dac.The override of
&cvbs_dac { status = "okay"; ... }enables the DAC on Meson8. If you intend it to remain active by default, ensure that the relevant driver and node references are fully functional (e.g. no unhandled interrupts or missing clock control).
151-214: Check alignment of new VPU node with SoC specifics.In
meson8b.dtsi, the newly introducedvpu@100000node has near-identical details to Meson8’s VPU definition (clocks, resets, etc.). Meson8b might have subtle differences from Meson8. Verify all references (interrupts, reset bits) are correct for Meson8b specifically.patch/kernel/archive/meson-6.13/0047-clk-meson-meson8b-Add-the-Ethernet-RMII-clock-tree-o.patch (3)
35-39: Check for potential kernel version discrepancies.You’ve added
select COMMON_CLK_MESON_PHASEin Kconfig. Ensure that downstream or older kernel configurations have support forCOMMON_CLK_MESON_PHASE; otherwise, it may cause build failures in unsupported kernel branches.
55-63: Confirm mux table correctness.The
meson8_eth_clk_mux_table[] = { 7 };only supports one entry (7). Verify whether additional possible parent selections are missing, or if the hardware truly only uses that single value for RMII input.
92-109: Validate phase inversion usage.
meson8_eth_clk_phasetoggles a single bit for phase inversion (.shift = 14). Confirm that toggling only one bit is sufficient for all required phase adjustments. Some hardware might need multi-bit phase configurations if advanced TX or RX skew correction is needed.patch/kernel/archive/meson-6.13/0082-drm-meson-Add-support-for-the-Meson8-8b-8m2-TranSwit.patch (3)
622-759: Ensure stable power-up procedure.The
meson_txc_hdmi_bridge_atomic_enablelogic performs multiple resets, reconfigures packets, powers on the PHY, and sets up color space. Confirm that each sub-step can handle unexpected ordering, such as if a user quickly toggles the display on/off or if the EDID read fails mid-sequence.
1170-1251: Validate DDC clock rate.
ddc_i2c_bus_clk_hz = 500 * 1000;is a mid-range I2C clock. Ensure it’s fully stable on your hardware. Some SoCs might allow 100 kHz or 400 kHz modes specifically. Exceeding the spec can cause EDID read failures on certain HDMI monitors.
1278-1396: Confirm fallback to software fallback.At line 1310, if
devm_phy_get(dev, "hdmi")fails, the probe halts. If some boards don’t have a separate PHY or use a different name, consider fallback logic or documentation. The same applies forpclkusage at line 1330.patch/kernel/archive/meson-6.13/0006-ARM-dts-amlogic-meson8b-switch-to-the-new-PWM-contro.patch (6)
27-29: Removal of redundant clock properties looks correct.
The removal of “clocks” and “clock-names” from the EC100 PWM node aligns with switching to the new binding that centralizes clock definitions in the parent SoC dtsi.
40-42: Consistent removal of clock references.
Removing the same “clocks” properties in the MXQ DTS ensures consistent usage of the new binding across Meson8b variants.
53-55: Uniform alignment with new PWM binding.
Similarly, removing clock references for the ODROID-C1 helps maintain uniformity with the updated approach.
79-86: New PWM binding for pwm_ab.
The updated compatible strings and expanded “clocks” array match the SoC-level changes, ensuring the dt-bindings requirement to specify all possible clock inputs.
88-95: Updated pwm_cd node to match new binding model.
This is consistent with the other PWM nodes. Carefully confirm that any existing device trees or overlays referencing the old compatible strings are updated accordingly.
66-75:❓ Verification inconclusive
Properly updated compatible and clock properties for pwm_ef.
Switching from “amlogic,meson8b-pwm” to “amlogic,meson8b-pwm-v2” plus additional clocks is required by the new PWM binding. Just ensure the unknown “Video PLL” clock is fully validated for these boards.Do you need to confirm any side effects of introducing that unused “Video PLL”? If so, you could search for code that references or configures it to ensure correctness:
This script searches for references to CLKID_FCLK_DIV3 or related clock usage in the codebase to verify consistency.
🏁 Script executed:
#!/bin/bash ast-grep --pattern $' (call_expression function: (identifier) @func arguments: (argument_list (identifier) @arg (#eq? @arg "CLKID_FCLK_DIV3") ) )'Length of output: 157
Action Required: Validate “Video PLL” Clock Usage
The changes correctly update the PWM binding by switching from
"amlogic,meson8b-pwm"to"amlogic,meson8b-pwm-v2"and adding the new clock configurations. However, the new clock list includes an entry for the “Video PLL” clock that hasn’t been verified. The search for references toCLKID_FCLK_DIV3produced no output, so it's unclear whether this clock is completely unused or if there might be unanticipated side effects.
- Ensure that the “Video PLL” clock is fully validated for the board.
- Manually verify or search the codebase for any configuration or usage of this clock to ensure it doesn't cause issues.
patch/kernel/archive/meson-6.13/generic-Revert-pwm-meson-modify-and-simplify-calculation-in-.patch (1)
22-33: Logical revert to restore original PWM duty-cycle calculation.
This block reverts a prior commit and reinstates conditional logic, setting the period and duty cycle to zero ifchannel->lo < channel->hi. While this is presumably correct for supporting older board definitions, ensure that any assumed hardware behavior for this edge case is still valid. Consider verifying that no new drivers rely on the simplified logic.patch/kernel/archive/meson-6.13/0028-drm-connector-implement-generic-HDMI-audio-helpers.patch (5)
47-52: Clean modular addition to Makefile.
Appendingdrm_hdmi_audio_helper.otodrm_display_helperrespects the existing pattern. The approach is straightforward and follows typical Kconfig/Makefile usage.
62-190: Comprehensive HDMI audio helper implementation.
- The callbacks (startup, prepare, shutdown, etc.) encapsulate standard HDMI audio operations.
- Properly using connector’s
eld_mutexindrm_connector_hdmi_audio_get_eldis good for concurrency.- The
hook_plugged_cblogic protects shared state underhdmi_audio.lock. Looks correct.- Check if -ENOTSUPP in
mute_streamis appropriate or if returning 0 is better in some real-world usage.No critical issues found. Implementation appears consistent.
253-289: Initialization and cleanup in drm_connector.c.
- Initializing
connector->hdmi_audio.lockis consistent with the rest of the connector’s locks.- Unregistering the HDMI codec
platform_deviceindrm_connector_cleanupensures no leaks.- The partial ordering (unregister platform device, then destroy the mutex) is correct.
Overall, well-integrated.
290-317: New DRM HDMI audio helper header.
Provides a clear, minimal interface withdrm_connector_hdmi_audio_init()anddrm_connector_hdmi_audio_plugged_notify(). Straightforward definitions.
318-467: Extended connector struct to support HDMI audio.
- The
drm_connector_hdmi_audio_funcsstruct is well-documented.drm_connector_hdmi_audiointegrates seamlessly with the existingdrm_connectorfields.- This addition appears complete and self-contained.
Looks good for bridging the DRM connector with audio functionalities.
patch/kernel/archive/meson-6.13/0029-drm-bridge-connector-add-support-for-HDMI-codec-fram.patch (10)
1-23: No issues with patch metadata and commit message.
24-36: Kconfig addition looks fine.
No immediate concerns. The newselect DRM_DISPLAY_HDMI_AUDIO_HELPERline is aligned with enabling HDMI audio functionality.
52-66: Initialization pattern is clear.
Checks forbridge->funcs->hdmi_audio_startupand returns gracefully if not present, which is a good fallback.
68-82: Audio prepare function is consistent.
It neatly delegates the setup to the HDMI bridge if supported.
83-112: Shutdown and Mute Stream logic is well-structured.
Both functions handle null-bridge scenarios properly and query optional callbacks with correct checks.
114-119: New audio function pointers are wired correctly.
No issues noted in linking the helper callbacks.
124-136: Context linking for the connector is well-implemented.
Assigningbridge_connector->bridge_hdmibefore callingdrmm_connector_hdmi_initis good practice.
138-155: Conditional HDMI audio init is appropriate.
Verifies required callbacks and initializes audio only if the bridge supports it.
159-177: Additional function pointers in drm_bridge_funcs are coherent.
They follow established naming conventions and error handling for optional callbacks.
204-226: New fields in struct drm_bridge appear straightforward.
The naming approach forhdmi_audio_*fields is clear; usage is consistent with the rest of the patch.patch/kernel/archive/meson-6.13/0083-drm-meson-Meson8-Meson8b-Meson8m2-VCLK-HACK.patch (8)
1-15: No significant issues with patch metadata.
16-51: Clock init/exit functions look correct.
Preparation/cleanup for bulk clocks is handled with proper error returns.
60-105: Binding new resets and clocks is well-structured.
Specifyingvid_pll_resets[],intr_clks[], andvid_clks[]before callingdevm_*functions is standard practice.
105-155: Error handling in meson_drv_bind_master is thorough.
Thevideo_clock_exitlabel ensures cleanup on failures.
158-164: Unbinding cleans up video clocks.
Invokingmeson_video_clock_exitmaintains symmetry with the init path.
185-244: Added enums and fields to meson_drv.h appear consistent.
Naming is logical and helps track separate clock/reset resources.
245-422: VCLK management functions are detailed and well-structured.
They properly protect rates usingclk_set_rate_exclusiveand handle resets in a consistent manner.
423-465: Interrupt clock handling is a clean enhancement.
Toggling bulk clocks for vsync on/off is an effective approach for controlling power usage.patch/kernel/archive/meson-6.13/0026-ASoC-hdmi-codec-pass-data-to-get_dai_id-too.patch (9)
1-23: Patch metadata looks fine.
24-38: Adjusting adv7511_audio code to pass data is straightforward.
No functional issues; the signature aligns with the new callback prototype.
39-52: Anx7625 get_dai_id signature update is consistent.
It remains in harmony with other drivers adopting the extra parameter.
53-66: Lt9611 audio callback matches the new function signature.
No concerns regarding potential regressions.
67-80: Lt9611uxc audio callback also follows suit.
Implementation updates are minimal and correct.
81-94: Sii902x function signature extended.
Additional parameter usage is consistent with the general approach.
95-108: dw_hdmi_i2s adapts the interface properly.
This ensures uniform usage ofvoid *dataacross all HDMI audio drivers.
109-119: Struct hdmi_codec_ops update is correct.
Addingvoid *datato get_dai_id is a logical extension for future flexibility.
123-132: hdmi-codec.c changes are consistent with the new function pointer signature.
The code properly passes the samedataused by other callbacks.patch/kernel/archive/meson-6.13/0022-drm-tests-hdmi-handle-empty-modes-in-find_preferred_.patch (1)
25-26: Improved error handling for empty mode listsThe change from
list_first_entry()tolist_first_entry_or_null()is a good defensive programming practice. This prevents potential crashes or undefined behavior when the connector's modes list is empty, making the code more robust in edge cases.patch/kernel/archive/meson-6.13/0038-ARM-dts-meson-Add-GPIO-controller-capabilities-to-th.patch (1)
23-24: LGTM: Properly added GPIO controller capabilitiesThe addition of GPIO controller capabilities to the USB PHY is correctly implemented following standard DT conventions. These properties enable the PHY to expose the USB "ID" signal as a GPIO, which is essential for OTG functionality in Micro USB connectors.
patch/kernel/archive/meson-6.13/0035-phy-amlogic-meson8b-usb2-register-child-USB-connecto.patch (2)
24-24: LGTM: Added required headerCorrectly added the header for the platform device population function.
32-35: LGTM: Well-implemented child device registrationThe implementation properly uses
devm_of_platform_populate()to automatically create child devices based on device tree nodes. The error handling is appropriate and the error message clearly indicates the issue if device population fails.patch/kernel/archive/meson-6.13/0033-dt-bindings-phy-meson8b-usb2-Add-support-for-reading.patch (2)
26-28: LGTM: Clear documentation for OTG functionalityThe description clearly explains the purpose of the GPIO controller functionality, specifically how the USB "ID" signal can be accessed through the PHY-provided GPIO controller.
37-40: LGTM: Properly defined GPIO controller propertiesThe properties are correctly defined according to standard GPIO controller conventions. The
#gpio-cells = <2>value is appropriate for representing typical GPIO specifications (pin number and flags).patch/kernel/archive/meson-6.13/0048-dt-bindings-net-dwmac-meson-Add-the-Ethernet-clock-i.patch (1)
25-46: Well-structured device tree binding changes for the Ethernet clock input.The additions to the YAML schema properly define the clock properties required for the Ethernet controller on Meson6/8 SoCs. The conditional structure and constraints are correctly implemented, ensuring these properties only apply to the appropriate compatible devices.
patch/kernel/archive/meson-6.13/0042-dt-bindings-display-meson-vpu-Add-the-CVBS-DAC-prope.patch (2)
25-33: Appropriate PHY bindings for the CVBS DAC.The
physandphy-namesproperties follow standard PHY binding conventions and provide a clear interface for connecting the VPU with the CVBS DAC.
41-43: Good usage example in the documentation.The example demonstrates how to reference the CVBS DAC PHY correctly in a device tree node, which is helpful for implementers.
patch/kernel/archive/meson-6.13/0052-ARM-dts-meson-meson8-Add-the-clock-input-to-the-Ethe.patch (1)
25-28: Consistent implementation of the Ethernet clock bindings.The changes to the Meson8 device tree correctly implement the clock bindings defined in the earlier patch, adding the necessary RMII reference clock input to the Ethernet controller.
patch/kernel/archive/meson-6.13/0024-drm-tests-hdmi-return-meaningful-value-from-set_conn.patch (2)
23-31: Improved return value handling.The function now properly returns the meaningful result from
fill_modes()rather than a hardcoded value, which is a better design. The removal of the internal assertion is appropriate since the caller will now handle the check.
38-40: Updated assertion matches new return value behavior.The test code has been correctly modified to assert that the return value is greater than 0, consistent with the new function behavior.
patch/kernel/archive/meson-6.13/0023-drm-tests-hdmi-rename-connector-creation-function.patch (1)
22-427: Rename function for clarity and consistency.All instances of
drm_atomic_helper_connector_hdmi_inithave been replaced withdrm_kunit_helper_connector_hdmi_init, which better reflects their usage in KUnit tests. These changes appear consistent throughout the file. Good job keeping the new naming uniform in all test cases.patch/kernel/archive/meson-6.13/0040-dt-bindings-phy-Add-bindings-for-the-Amlogic-Meson-C.patch (1)
1-106: Introduce Amlogic Meson CVBS DAC binding.This new YAML binding file comprehensively documents the CVBS DAC (Composite Video Baseband Signal DAC) properties. The structure and required fields align well with established device tree conventions. The examples are helpful for developers integrating this PHY. Good addition!
patch/kernel/archive/meson-6.13/0016-drm-connector-add-mutex-to-protect-ELD-from-concurre.patch (4)
31-31: Initialize mutex at connector creation.The
eld_mutexinitialization is placed alongside other connector mutexes, ensuring it's available for locked operations as soon as the connector is set up.
43-46: Protect ELD clearing with mutex locks.Wrapping
memset(connector->eld, 0, sizeof(connector->eld))withmutex_lock/unlockensures the ELD buffer remains consistent when cleared, preventing concurrent reads or partial writes.
53-64: Safeguard ELD updates during EDID processing.Using
mutex_lock/unlockbefore constructing ELD data maintains thread safety if.get_eld()or other routines happen to run concurrently. This is a solid approach to prevent data races.
77-80: Document concurrency concerns in connector structure.Adding
eld_mutexand clarifying thateld[]is protected by this lock helps future maintainability. Clear documentation is crucial for concurrency primitives.patch/kernel/archive/meson-6.13/0039-ARM-dts-meson8b-odroidc1-Enable-the-Micro-USB-OTG-co.patch (3)
24-36: Verify regulator voltage range and GPIO polarity.The fixed regulator is set to 5V with an active-high GPIO. Please ensure the hardware design aligns with this configuration and that the regulator’s min/max microvolts match the actual 5V supply tolerances.
Would you like a script to scan for related regulator definitions in the codebase to confirm consistency?
45-61: OTG mode and role-switch configuration look good.Your definition of
dr_mode = "otg"and a default role of"peripheral"is appropriate for a dual-role USB port. No issues found here.
66-86: Validate ID pin polarity for the USB connector node.The
gpio-usb-b-connectorusesid-gpios = <&usb0_phy 0 GPIO_ACTIVE_HIGH>. Double-check if the hardware ID pin is indeed active high. Misconfiguration can cause unexpected role switching behavior.patch/kernel/archive/meson-6.13/0081-drm-meson-Make-the-HHI-registers-optional-WIP.patch (1)
69-100: Optional register checks appear correct.The added
if (priv->hhi)guards protect register updates. This approach gracefully handles systems lacking HHI.patch/kernel/archive/meson-6.13/0020-drm-display-bridge_connector-use-drm_bridge_connecto.patch (1)
51-51: Ensure test coverage for the new.mode_validassignment.Assigning the
.mode_validcallback indrm_bridge_connector_helper_funcsis an important functional change. Please confirm that relevant display pipeline tests validate this new hook to prevent regressions in future updates.patch/kernel/archive/meson-6.13/0034-phy-amlogic-meson8b-usb2-Add-support-for-reading-the.patch (2)
30-30: Confirm concurrency assumptions for GPIO driver include.Pulling in
<linux/gpio/driver.h>is correct for GPIO operations. Since this code runs in a potentially concurrent environment, ensure that additional locking or concurrency considerations are not necessary, especially when reading the ID signal or modifying related registers.
46-61: Validate error handling and return values for ID detection.The
get_directionandget_valuemethods always indicate an input direction and interpretregmap_test_bits()to return 1 or 0. Verify thatregmap_test_bits()handles corner cases correctly (e.g., negative on error) and consider whether a negative error code should propagate if encountered. Currently it’s silently converted to 0.patch/kernel/archive/meson-6.13/0017-drm-connector-Add-a-way-to-init-add-a-connector-in-s.patch (2)
120-139: Review concurrency implications for the new connector add/remove.
drm_connector_add()anddrm_connector_remove()manipulate global lists underconnector_list_lock. Verify that any new dynamic connector usage scenarios also protect these calls with the same lock or function within the same context. Failing to do so can introduce data race conditions during hotplug operations.
184-224: Thoroughly test the new dynamic connector workflow.
drm_connector_dynamic_init()is part one of the two-step approach for MST or other late-added connectors. Confirm that test coverage exists for dynamic connectors through at least one MST driver. If coverage is missing, consider adding integration tests that create, register, and remove a dynamic connector to catch setup/teardown issues.patch/kernel/archive/meson-6.13/0043-drm-meson-Add-support-for-using-a-PHY-for-the-CVBS-D.patch (5)
45-57: Good addition for separating CVBS DAC handling.Introducing dedicated fields (
cvbs_dac,cvbs_dac_enabled, andcvbs_dac_pdev) instruct meson_drmclearly separates tracking and power state management of the CVBS DAC. This keeps the driver modular and more readable.
87-111: Validate error handling for PHY init/exit.Upon attaching or detaching the CVBS bridge, the code calls
phy_initandphy_exit. Make sure calls happen strictly in pairs and handle initialization failures carefully (e.g., ifphy_initfails, ensure we don’t inadvertently callphy_exitlater). This helps avoid resource leaks or inconsistent states.
148-171: Refine atomic_disable logic.Currently, if
cvbs_dac_enabledis false, the function returns immediately. If the hardware or software scenario toggles the encoder state quickly, this return path might skip some needed cleanups (like partial register resets). Confirm that skipping these lines is always safe.
183-229: Fallback registration logic seems correct.The fallback approach for old device trees gracefully covers configurations where the CVBS PHY was never declared. This is an excellent way to maintain backward compatibility. Just be sure to log any fallback usage clearly, as done here with
dev_info.
231-275: Careful with partial error paths.When attaching the CVBS bridge fails, the code un-registers the fallback CVBS DAC platform device. Verify that no subsequent cleanup steps (like
phy_exit) are incorrectly assumed or needed for partial fail. Early bail-outs might leave the system in a partial state if not done consistently.patch/kernel/archive/meson-6.13/0041-phy-amlogic-Add-a-new-driver-for-the-CVBS-DAC-CVBS-P.patch (3)
39-47: Kconfig entry properly introduces a separate CVBS DAC option.This
PHY_MESON_CVBS_DACentry in Kconfig isolates the CVBS DAC driver for Amlogic Meson SoCs. It's a clean approach that preserves modularity, letting downstream users decide to include or exclude CVBS support easily.
155-189: SoC-specific data structure is well-organized.Storing SoC-specific configure values (e.g.,
cdac_vref_adj_enable_val) in thephy_meson_cvbs_dac_datatable is a neat solution for code maintainability. This design scales well for future Meson revisions that might adjust calibration or offset values.
308-382: Probe function carefully handles old DTs.The code logic that attempts OF matching first and then uses
syscon_regmap_lookup_by_compatiblefor older device trees is a thorough approach. Be sure to keep logs transparent for debugging any mismatches between device-tree definitions and fallback paths. This will significantly help users diagnosing any missing CVBS nodes.patch/kernel/archive/meson-6.13/0051-net-stmmac-dwmac-meson-Initialize-all-known-PREG_ETH.patch (5)
7-8: Patch improves hardware initialization robustnessThe commit message accurately describes the purpose of this patch - making the driver less dependent on the bootloader for correct hardware setup. This is a good practice for kernel drivers, as it ensures more reliable operation across different bootloader configurations.
23-23: Good addition of bitfield.hIncluding the bitfield.h header is appropriate here as it provides the FIELD_PREP macro used later for register bit manipulation.
31-36: Improved code readability with consistent formattingThe alignment of the register bit definitions improves code readability while maintaining the same functionality.
38-46: Well-documented register bit definitionsThe new register bit definitions are properly documented with comments explaining their purpose and possible values. This makes the code more maintainable and easier to understand.
53-70: More robust hardware initializationThe modified initialization function now properly handles all known register bits instead of only setting the DIV_EN bit. This implementation:
- Preserves other register bits by reading the current value first
- Explicitly clears specific bits that need to be controlled
- Sets the MII mode to RMII using the appropriate bit field manipulation
- Enables the clock division
This is a significant improvement that reduces dependency on bootloader configuration.
| + cec_AO: cec@100 { | ||
| + compatible = "amlogic,meson-gx-ao-cec"; // FIXME | ||
| + reg = <0x100 0x14>; | ||
| + interrupts = <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; | ||
| + // TODO: 32768HZ clock | ||
| + hdmi-phandle = <&hdmi_tx>; | ||
| + status = "disabled"; | ||
| + }; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
CEC controller node requires further work
The CEC controller node has a few issues that need to be addressed:
- The "FIXME" comment indicates that the compatibility string (
amlogic,meson-gx-ao-cec) may not be accurate for the Meson8 hardware - The "TODO" comment mentions that the 32768Hz clock configuration is missing
Additionally, this patch is marked as "WiP" (Work in Progress), suggesting it may not be complete or fully tested.
Could you verify if:
- The compatibility string is correct for Meson8 hardware
- The missing clock definition has been implemented elsewhere
- These incomplete aspects could be related to the HDMI issues mentioned in the PR comments
🌐 Web query:
Is "amlogic,meson-gx-ao-cec" the correct compatible string for Meson8 AO CEC controller?
💡 Result:
The compatible string "amlogic,meson-gx-ao-cec" is not correct for the Meson8 AO CEC controller. This string is explicitly documented for newer SoCs in the GX family (GXBB, GXL, GXM, G12A, SM1) and the AO_CEC_A module[2][11][20].
Key findings:
-
Documentation binding files confirm "amlogic,meson-gx-ao-cec" applies to:
- GXBB (S905), GXL (S905X/W), GXM (S912), G12A (S905X2/Y2), and SM1 (A311D/S905D3)[2][11][20].
- The Meson8 series (32-bit Cortex-A9 SoCs) is not listed in these bindings.
-
Device tree examples for Meson-GX platforms (e.g., meson-gx.dtsi) use "amlogic,meson-gx-ao-cec", while older Meson8 platforms use distinct implementations[2][4][10].
-
Source code distinguishes between drivers for different generations, with
meson-ao-cec-g12a.cexplicitly handling the G12A/B variant[1][5].
For Meson8/Meson8b (S805), the correct compatible string would need verification from specific documentation or source references not present in the provided search results. Early implementations suggest separate drivers for older 32-bit Amlogic SoCs[4][10].
Summary: Use "amlogic,meson-gx-ao-cec" only for GX-family SoCs, not Meson8. A dedicated compatible string likely exists for Meson8 AO CEC, potentially "amlogic,meson8-ao-cec" based on older conventions.
Citations:
- 1: https://lwn.net/Articles/785182/
- 2: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
- 3: https://www.opennet.ru/kernel/6.3.html
- 4: https://linux-meson.com/mainlining.html
- 5: https://github.com/torvalds/linux/blob/master/drivers/media/cec/platform/meson/ao-cec.c
- 6: https://kernel.googlesource.com/pub/scm/linux/kernel/git/nvdimm/nvdimm/+/bf8a9a4755737f6630756f0d87bea9b38f0ed369%5E2..bf8a9a4755737f6630756f0d87bea9b38f0ed369/
- 7: https://www.kernel.org/doc/html/v6.1/admin-guide/media/building.html
- 8: https://www.kernel.org/doc/Documentation/devicetree/bindings/media/amlogic,meson-gx-ao-cec.yaml
- 9: https://gitlab.fit.cvut.cz/ferjajak/ni-osy-linux/-/tree/94dbd7ba894de91446b355a0320b526aaa8314b3/Documentation/devicetree/bindings/media
- 10: https://forum.libreelec.tv/thread/21798-meson-8-lives/?pageNo=3
- 11: https://www.kernel.org/doc/Documentation/devicetree/bindings/media/cec/amlogic,meson-gx-ao-cec.yaml
- 12: https://www.infradead.org/git/?p=users%2Fjedix%2Flinux-maple.git%3Ba%3Dcommitdiff%3Bh%3D3d21a46093352f7802b9c66c7cce35cd02a50e53
- 13: https://patchwork.kernel.org/project/linux-media/cover/20190408121805.2870-1-narmstrong@baylibre.com/
- 14: https://patches.linaro.org/patch/631005/
- 15: https://kernel.googlesource.com/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing/+/refs/tags/v5.2-rc1-dts%5E1..refs/tags/v5.2-rc1-dts/
- 16: https://boot.libre.computer/ci/aml-s905x-cc.dts
- 17: https://mail.spinics.net/lists/linux-gpio/msg48202.html
- 18: https://nv-tegra.nvidia.com/r/gitweb?p=linux-5.10.git%3Ba%3Dblob%3Bf%3DDocumentation%2Fdevicetree%2Fbindings%2Fmedia%2Famlogic%2Cmeson-gx-ao-cec.yaml%3Bhb%3Deab40026605f4717a9749ffcaec8119d58494999
- 19: https://isrc.iscas.ac.cn/gitlab/yafen/linux/-/commit/ecb41832bd2a7a3f8ac93527cec5e51e3827daed.diff
- 20: https://home.xyhcloud.com:1443/tina-linux/linux-5.4/-/blob/f6f0698224f3592db7f44665f3cee62cb0d312e7/Documentation/devicetree/bindings/media/meson-ao-cec.txt
Action Required: Correct Compatibility String and Address Missing Clock Definition for Meson8 AO CEC Node
There are still outstanding issues in this node:
- Compatibility string: The string
"amlogic,meson-gx-ao-cec"is not valid for Meson8 hardware. It’s documented for newer GX-family SoCs. Please review and update this to the correct string for Meson8 (likely something akin to"amlogic,meson8-ao-cec"based on older conventions). - Clock configuration: The 32768Hz clock setup remains unimplemented. Verify if there’s an existing definition elsewhere or if this needs to be added.
- HDMI relation: Confirm whether these omissions might be contributing to the HDMI issues mentioned in the PR comments.
Please address these points to move the patch out of WiP.
| + cec_AO: cec@100 { | ||
| + compatible = "amlogic,meson-gx-ao-cec"; // FIXME | ||
| + reg = <0x100 0x14>; | ||
| + interrupts = <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; | ||
| + // TODO: 32768HZ clock | ||
| + hdmi-phandle = <&hdmi_tx>; | ||
| + status = "disabled"; | ||
| + }; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
CEC controller node requires further work
The CEC controller node has the same issues as in the Meson8 implementation:
- The "FIXME" comment indicates that the compatibility string (
amlogic,meson-gx-ao-cec) may not be accurate for the Meson8b hardware - The "TODO" comment mentions that the 32768Hz clock configuration is missing
This patch is also marked as "WiP" (Work in Progress), suggesting incomplete implementation.
Since the PR objectives mentioned HDMI issues that were "likely introduced by one of the xdarklight patches" and a "NULL pointer dereference error when attempting to change the resolution," it would be prudent to verify if these incomplete CEC controller implementations could be related to those issues.
🏁 Script executed:
#!/bin/bash
# Check if there are any other patches addressing the CEC controller TODOs/FIXMEs
rg -A 5 "amlogic,meson-.*-ao-cec" --type patch
rg -A 5 "TODO: 32768HZ clock" --type patchLength of output: 153
Action Required: Verify and Complete the CEC Controller Node Implementation
The new patch still introduces an incomplete CEC controller node for Meson8b hardware. Please note the following outstanding issues:
- Compatibility String Concern: The node uses a compatibility string
"amlogic,meson-gx-ao-cec", which is flagged with aFIXME. This string may not correctly reflect the Meson8b hardware, similar to issues found in the Meson8 implementation. - Clock Configuration Incomplete: The
TODO: 32768HZ clockcomment indicates that the necessary clock configuration is missing. - WiP Status & Potential Impact: Since the patch is marked as WiP and given the recent HDMI issues (including a NULL pointer dereference during resolution changes), please verify if these incomplete CEC controller settings might be contributing to those problems.
To aid in this review, please run the following verification commands to search the repository for any patches or occurrences that address these TODO/FIXME comments (note that the previous attempt using --type patch resulted in an error):
If these searches do not reveal additional changes elsewhere in the codebase that resolve or comment on these issues, further manual verification is required. Please confirm that the incomplete CEC controller implementation is not the root cause of the HDMI issues observed, especially in light of the mentioned xdarklight patches and the NULL pointer dereference error.
🏁 Script executed:
#!/bin/bash
# Re-run search commands without specifying the "patch" file type
rg -A 5 "amlogic,meson-.*-ao-cec"
rg -A 5 "TODO: 32768HZ clock"Length of output: 11495
Action Required: Finalize Incomplete CEC Controller Implementation
The verification confirms that the incomplete implementation persists across multiple patches for both Meson8 and Meson8b platforms. In particular:
- Compatibility String Issue: The node uses
"amlogic,meson-gx-ao-cec"(marked with FIXME), which appears in several patches. This string may not correctly identify the Meson8b hardware and should be reassessed. - Clock Configuration Missing: The
// TODO: 32768HZ clockcomment remains, indicating that the required clock configuration is not yet implemented. - WiP Status & Potential Impact: As the patch is still labeled "WiP," please ensure that these incomplete areas are not contributing to the HDMI issues (notably, the NULL pointer dereference during resolution changes mentioned in the PR).
Please update the patch by:
- Verifying and, if needed, correcting the compatibility string for Meson8b.
- Implementing the 32768Hz clock configuration.
- Manually checking that this incomplete CEC controller node is not a factor in the reported HDMI/resolution issues.
| + .read_edid = drm_bridge_connector_read_edid, | ||
| }; |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Centralize all EDID reading logic.
In addition to .read_edid = drm_bridge_connector_read_edid, verify no other modules are reading EDID independently. Centralizing EDID read routines can mitigate complexities around multiple bridging layers.
| #define MESON_GATE(_name, _reg, _bit) \ | ||
| MESON_PCLK(_name, _reg, _bit, &meson8b_clk81.hw) | ||
|
|
||
| @@ -2973,6 +3046,10 @@ static struct clk_hw *meson8_hw_clks[] = { | ||
| [CLKID_CTS_I958] = &meson8b_cts_i958.hw, | ||
| [CLKID_VID_PLL_LVDS_EN] = &meson8b_vid_pll_lvds_en.hw, | ||
| [CLKID_HDMI_PLL_DCO_IN] = &hdmi_pll_dco_in.hw, | ||
| + [CLKID_ETH_CLK_SEL] = &meson8_eth_clk_sel.hw, | ||
| + [CLKID_ETH_CLK_DIV] = &meson8_eth_clk_div.hw, | ||
| + [CLKID_ETH_CLK_PHASE] = &meson8_eth_clk_phase.hw, | ||
| + [CLKID_ETH_CLK] = &meson8_eth_clk_gate.hw, | ||
| }; |
There was a problem hiding this comment.
Review final clock array ordering.
You’ve appended [CLKID_ETH_CLK_SEL], [CLKID_ETH_CLK_DIV], [CLKID_ETH_CLK_PHASE], [CLKID_ETH_CLK] to meson8_hw_clks[]. Correct ordering can matter if previous code references numeric indexes. Double-check no existing calls rely on different positions.
| +/** | ||
| + * drm_connector_dynamic_register - register a dynamic connector | ||
| + * @connector: the connector to register | ||
| + * | ||
| + * Register userspace interfaces for a connector. Only call this for connectors | ||
| + * initialized by calling drm_connector_dynamic_init(). All other connectors | ||
| + * will be registered automatically when calling drm_dev_register(). | ||
| + * | ||
| + * When the connector is no longer available the driver must call | ||
| + * drm_connector_unregister(). | ||
| + * | ||
| + * Returns: | ||
| + * Zero on success, error code on failure. | ||
| + */ | ||
| +int drm_connector_dynamic_register(struct drm_connector *connector) | ||
| +{ | ||
| + /* Was the connector inited already? */ | ||
| + if (WARN_ON(!(connector->funcs && connector->funcs->destroy))) | ||
| + return -EINVAL; | ||
| + | ||
| + drm_connector_add(connector); | ||
| + | ||
| + return drm_connector_register(connector); | ||
| +} | ||
| +EXPORT_SYMBOL(drm_connector_dynamic_register); | ||
| + |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Guard against partial registration failures.
drm_connector_dynamic_register() adds the connector to the global list and then calls drm_connector_register(). If drm_connector_register() fails, no standard rollback is triggered. Evaluate whether removing the connector from the list is necessary to avoid inconsistencies or memory leaks.
This issue should be fixed with torvalds/linux@0d337b4 (which is part of |
Switch meson edge to 6.13 kernel
Hdmi patches from xdarklight github repo