2413637_en-US

[#1]

LPSPI3 registers inaccessible from Linux (Bus error on devmem read) — external SPI device on P11 EXP

Summary

I'm trying to bring up two external MCP2515 CAN controllers (Waveshare 2‑CH CAN HAT, confirmed working on a genuine Raspberry Pi) on the FRDM‑IMX93 board's P11 EXPI header, using LPSPI3 on GPIO_IO08‑11 (the pins that match the Raspberry‑Pi‑compatible header positions per UM12181 Table 21).

After fixing every device‑tree‑level issue I could find (power, pinmux, chip‑select, pinctrl‑assert‑gpios), the SPI clock (SCK) never toggles on the physical header pin, and a direct register read of the LPSPI3 block causes a Bus error. A different, known‑working peripheral (LPUART1) reads back fine from the same address space. This points to a resource/bus access restriction (RDC or similar) rather than anything fixable from the Linux device tree.

Board / software

• Board: FRDM‑IMX93 (NXP), SoC: MIMX9352CVVXMAB
• BSP: NXP i.MX Release Distro, kernel 6.18.2-1.0.0-gf49f45233f7b
• Target peripheral: lpspi3 (spi@42550000, aliased spi2 in /aliases, real dts label confirmed via /proc/device-tree/__symbols__ to be lpspi3)
• External device under test: 2× MCP2515 (Waveshare 2‑CH CAN HAT) on CS0/CS1

What's already confirmed working (ruled out)

1. Power to the header. reg_vexp_3v3 / reg_vexp_5v are regulator-fixed nodes that default to disabled (regulator_summary showed use=0). Added regulator-always-on + regulator-boot-on via overlay fragments targeting &reg_vexp_3v3 / &reg_vexp_5v (confirmed real labels via __symbols__). Verified 3.3 V / 5 V physically present on P11 afterwards.
2. Pinmux. GPIO_IO08‑11 correctly muxed to LPSPI3_PCS0/SIN/SOUT/SCK using the official macros from imx93-pinfunc.h. input_reg/input_val are 0x0000/0x0 for these three functions, so no DAISY‑chain select is required (ruled out via macro inspection, no separate register needed).
3. Chip‑select. cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>, <&gpio2 7 GPIO_ACTIVE_LOW>; (bit‑banged GPIO CS, matching NXP's own upstream board‑support pattern for this node). Confirmed via cat /sys/kernel/debug/gpio and multimeter/logic‑analyzer: CS0 toggles correctly and physically reaches the header pin.
4. pinctrl-assert-gpios. NXP's own upstream &lpspi3 reference for this board includes pinctrl-assert-gpios = <&pcal6408 0 GPIO_ACTIVE_HIGH>; (this line does not appear in most public guides, only in the board's own dts patch). Added it; confirmed via /proc/device-tree/__symbols__ that pcal6408 resolves, and via cat /sys/kernel/debug/gpio that the GPIO is asserted (out hi) once lpspi3's default pinctrl state is requested.
5. Overlay applies cleanly. No FDT_ERR_NOTFOUND from U‑Boot's fdt apply; /sys/bus/spi/devices/ shows spi2.0 and spi2.1 registered by the SPI core.
6. ERR051608 (LPSPI TCR[PRESCALE] errata). Checked spi-fsl-lpspi.c history — the fix (prescale_max = 1 for fsl,imx93-spi) landed in mainline Aug 2024 / stable 6.6.51 & 6.10.10 Sept 2024, well before this kernel version (6.18.2), and the compatible string (fsl,imx93-spi) is already present in the base board dts, so the driver should auto‑apply this limit. Not ruled out with certainty (no direct register confirmation of the actual PRESCALE field written), but timeline strongly suggests it's already handled.

The actual symptom

With CS0/CS1, MISO, MOSI, SCK probed on the physical P11 pins (multimeter, then a logic analyzer at 10–20 MSa/s triggered on CS0 falling edge) while continuously retrying a transfer (spidev_test in a loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind):

• CS0 toggles. Confirmed on both multimeter and logic analyzer.
• SCK never toggles. Flat, no activity, regardless of continuous transfer attempts.
• MOSI never toggles.
• Both MCP2515s fail identically: mcp251x spi2.0/spi2.1: MCP251x didn't enter in conf mode after reset / Probe failed, err=110 (ETIMEDOUT) — i.e. the driver's own SPI‑level reset+read‑CANSTAT sequence gets no response, consistent with SCK never leaving the SoC.

Root cause narrowed to clock / bus access, not device tree

# clk_enable_count AND clk_prepare_count are both 0, despite the controller
# actively being used in a continuous retry loop
$ cat /sys/kernel/debug/clk/clk_summary | grep -i lpspi3
       lpspi3_root      0  0  0  50000000  0  0  50000  N  deviceless        no_connection_id
          lpspi3        0  0  0  50000000  0  0  50000  N  42550000.spi      per

$ cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count
0

lpspi3's functional (per) clock shows clk_enable_count=0 and clk_prepare_count=0 even while 42550000.spi (the real, bound consumer) is actively attempting transfers in a loop (spidev_test loop, and separately by repeatedly forcing mcp251x re‑probe via echo spi2.0 > /sys/bus/spi/drivers/mcp251x/bind). clk_prepare() is the step before clk_enable() — the fact that it's never even called suggests the driver's transfer path (or a pm_runtime_get() in front of it) never reaches its own clock‑management code for this device, rather than the clock being requested and then failing to gate on.

I don't have kernel build tooling to add tracepoints, so I can't yet tell whether this is a pm_runtime resume that silently no‑ops, a missing dependency (e.g. a power-domains reference this board's lpspi3 node needs but doesn't have), or something else in spi-fsl-lpspi.c for this specific kernel build.

The decisive register‑level test — direct devmem read:

$ devmem 0x44380000 32        # LPUART1 base — known-good peripheral
0x04040007

$ devmem 0x42550000 32        # LPSPI3 base (VERID register)
Bus error (core dumped)

A completely unrelated, working peripheral (LPUART1, used for the debug console) reads back fine from the same CPU/bus context; LPSPI3's base address faults on a plain 32‑bit read. I initially suspected a Resource Domain Controller (RDC) style access restriction specific to this board, but several NXP Community threads (i.MX25/i.MX6ULL "devmem return bus error", i.MX8MP I2C‑from‑DSP thread) point to the same symptom being the normal, expected result of touching an AIPS‑bus peripheral whose clock is gated off — not necessarily a security/domain restriction. That's consistent with clk_enable_count=0 above and makes me now think this is a clock‑enablement bug in the driver/PM path for this device, not (necessarily) an RDC block — though I can't fully rule out RDC without lower‑level tooling.

This isn't a general i.MX93 LPSPI3 limitation

For context: a separate NXP Community thread ([iMX93AUTO EVK] SPI Configuration for QCA7006AQ, community.nxp.com/t5/i-MX-Processors/iMX93AUTO-EVK-SPI-Configuration-for-QCA7006AQ-with-imx93AUTO-EVK/m-p/1839847) shows someone successfully driving an external SPI device over LPSPI3 on the same GPIO_IO08‑11 pins on the i.MX93‑11x11‑EVK (same SoC), using:

c

&lpspi3 {
    compatible = "fsl,imx93-spi", "fsl,lpspi";
    cs-gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
    status = "okay";
    ...
};
&iomuxc {
    pinctrl_lpspi3_qca: lpspi3grp {
        fsl,pins = <
            MX93_PAD_GPIO_IO11__LPSPI3_SCK   0x3fe
            MX93_PAD_GPIO_IO10__LPSPI3_SOUT  0x3fe
            MX93_PAD_GPIO_IO09__LPSPI3_SIN   0x3fe
            MX93_PAD_GPIO_IO08__LPSPI3_PCS0  0x3fe   /* native PCS0, not plain GPIO */
        >;
    };
};

I tried this exact variant (native LPSPI3_PCS0/LPSPI3_PCS1 instead of plain GPIO2_IO08/GPIO2_IO07, plus the explicit compatible override) on the FRDM board — no change, devmem 0x42550000 32 still faults, clk_enable_count/clk_prepare_count still 0. This rules out pinmux/compatible‑string choice as the cause on this board, and — combined with the EVK success — makes me suspect something FRDM‑board‑specific (either in imx93-11x11-frdm.dts's handling of lpspi3, or in this board's U‑Boot/ATF‑level RDC/power‑domain setup) rather than a general i.MX93 SoC or mainline‑driver limitation.

Questions for NXP

1. Given clk_prepare_count/clk_enable_count stay at 0 for lpspi3 even while the SPI core is actively driving transfers to a bound spi2.0/spi2.1 device, and a plain register read of 0x42550000 bus‑faults — what's missing from the FRDM‑IMX93's lpspi3 device‑tree node (or from board‑level RDC/power‑domain setup) that the working EVK config doesn't need?
2. Is LPSPI3 on the FRDM‑IMX93 intentionally reserved for another domain (e.g. Cortex‑M33 / secure world, or the on‑board MAYA‑W2 tri‑radio module path) at the board's default RDC/ATF configuration, unlike the EVK?
3. Is there a reference imx93-11x11-frdm-lpspi.dts (analogous to imx93-11x11-evk-lpspi.dts) for using LPSPI3 externally via P11 on this specific board?

How to reproduce

1. Base board dtb: stock imx93-11x11-frdm.dtb shipped with the i.MX Release Distro image (unmodified NXP lpspi3 + pcal6408 + reg_vexp_3v3/reg_vexp_5v nodes — all confirmed present via __symbols__).
2. Apply the overlay described above (regulator always‑on, pinctrl + cs‑gpios + pinctrl‑assert‑gpios on &lpspi3; tried both plain‑GPIO and native‑PCS0/PCS1 pinmux variants, same result both times).
3. Bind spidev (built‑in, CONFIG_SPI_SPIDEV=y) manually to spi2.0:

   echo spidev > /sys/bus/spi/devices/spi2.0/driver_override
   echo spi2.0 > /sys/bus/spi/drivers/spidev/bind

1. spidev_test -D /dev/spidev2.0 -s 1000000 -v — "succeeds" (no I/O error) but RX data is not a loopback of TX even with MOSI/MISO physically shorted; SCK never toggles on a logic analyzer regardless.
2. cat /sys/kernel/debug/clk/clk_summary | grep lpspi3 → clk_enable_count=0.
3. cat /sys/kernel/debug/clk/lpspi3/clk_prepare_count → 0.
4. devmem 0x42550000 32 → Bus error. devmem 0x44380000 32 (LPUART1) → succeeds normally.

Happy to provide the full overlay source, dmesg, and clk_summary/gpio dumps if useful.