nRF54L15 SPIM00 + MIPI-DBI display: SPI transfers no longer reach the panel (blank) — regression NCS v3.1.1 → v3.3.x/v3.4.0

[Francesco01]

Environment

• Custom board based on nRF54L15 (*/nrf54l15/cpuapp), SoC nRF54L15.
• Display: 320×480 SPI panel (ST7796S-class controller) driven via MIPI-DBI-SPI over SPIM00.
• Tested on NCS v3.1.1 (Zephyr 4.1), v3.3.1 (Zephyr 4.3.99), v3.4.0 (Zephyr 4.4). Same application source in all three.

Summary / regression The exact same firmware:

• NCS v3.1.1 → display works perfectly.
• NCS v3.3.1 → blank/white panel.
• NCS v3.4.0 → blank/white panel.

So a regression was introduced in Zephyr 4.3 / NCS v3.3.x that stops SPIM00 SPI data from physically reaching the panel.

Symptom On v3.3.1/v3.4.0 the custom display driver init completes with no errors (reset OK, blanking, orientation, display-ON all return 0). A direct full-screen RED fill done inside the driver via mipi_dbi_write_display() — bypassing LVGL entirely — also returns success (ret=0), but nothing appears on the panel; it stays white. I inserted a 3-second hold right after the fill: the panel is white the whole time. So the SPI writes report success at the API level but do not physically reach the device.

Devicetree (relevant parts)

mipi_dbi_spi {
    compatible = "zephyr,mipi-dbi-spi";
    spi-dev   = <&spi00>;
    dc-gpios    = <&gpio2 7 GPIO_ACTIVE_HIGH>;   /* P2.07 */
    reset-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;    /* P1.05 */
    st7796s@0 {
        compatible = "custom,st7796s";
        mipi-mode = "MIPI_DBI_MODE_SPI_4WIRE";
        mipi-max-frequency = <8000000>;
    };
};
&spi00 {
    cs-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;       /* P2.10 */
    pinctrl-0 = <&spi00_default>;                 /* SCK P2.06, MOSI P2.08, MISO P2.09 */
};

What we already ruled out

• Not LVGL: the RED fill is a direct driver SPI write, no LVGL involved, and it fails too.
• Not the v3.4.0 SPIM driver refactor alone: v3.3.1 still ships the older spi_nrfx_spim.c and is also blank.
• Not the reset line: manually pulsing P1.05 with raw nrf_gpio (HIGH→LOW→HIGH) does not help.
• Not power domain / constant latency: adding nrf_sys_event_request_global_constlat() (returns 0) makes no difference.
• Everything else works on v3.4.0 (I²C sensors, fuel gauge, etc.) — only the SPI-to-display path is affected.

Questions

1. What changed in the nRF54L SPIM00 / MIPI-DBI-SPI path between Zephyr 4.1 and 4.3 that could make spi/mipi_dbi transfers return success but not physically clock out to the panel?
2. Are there new required properties for driving a MIPI-DBI display on SPIM00 (the 128 MHz high-speed instance) in NCS v3.3+ — e.g. memory-region / a DMA-accessible RAM region, a clock/power-domain setting, or pin constraints on Port 2?
3. Is 8 MHz a valid mipi-max-frequency for SPIM00 (128 MHz fixed source) in the current driver, or must it be a specific value?