sc84x: platform fixes for adsp-6.18.31-y (interrupts, DT correctness, driver fixes) - #3480
Conversation
mhennerich
added
sc846
LLM Reviewrun: 31091956263 |
LLM reviewThis series adds SC846 (ADSP-SC84x) bring-up fixes to run: 31112768014
|
531fe7f to
3f89a33
Compare
|
LLM review issues should be addressed now. |
nunojsa
left a comment
nunojsa
left a comment
There was a problem hiding this comment.
Nice cleanup. Just some minor comments from me...
The DMA channel <-> peripheral assignment is fixed in silicon (HRM "DMA Channel List"), so a bare IRQ entry in /proc/interrupts makes users cross-reference the manual to find out which channel interrupted. Name each channel IRQ after the controller instance and the hardware channel id, which together identify the serviced peripheral: 24: 0 GICv3 286 Level 31022000.dma ch0 25: 0 GICv3 322 Level 31022000.dma ch0 err 40: 12 GICv3 263 Level 3102d000.dma ch23 MDMA destination-side IRQs get a "dst" suffix. The names are derived entirely in the driver; no devicetree property is involved. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Every TRU route change logged at info level; SPI-offload consumers connect and disconnect their trigger routes on each buffer enable/disable cycle, which puts four log lines into dmesg per capture. Demote to dev_dbg. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Named constants for the Trigger Routing Unit generator and receiver IDs used by board files (software triggers, GP timer generators, SPI DMA receivers) so device trees stop hard-coding magic numbers. Values verified against the ADSP-SC84x HRM trigger lists; the SC59x uses the same assignment for these subsets. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Replace the hard-coded SOFT4 trigger master ID in the SHARC remoteproc node with the named constant. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
The ADSP-SC5xx / SC84x port-multiplex hardware separates the pad's output driver (FER) from its input buffer (INEN). When both drivers are disabled, the pad reads back as 0 regardless of the physical level. Selecting a peripheral function (writing PORT_MUX and setting FER) only enables the pad's output path -- INEN stays whatever it was at reset (typically 0), which means any peripheral that needs to sample data back from the pad (SPI MISO/RDY, UART RX, TWI SDA input phase, ...) reads 0. Set INEN unconditionally whenever the pin transitions from GPIO to a peripheral function. This is harmless for output-only signals -- the peripheral drives via the output driver, and the enabled input buffer just reads the driven level. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
3f89a33 to
6fbda9d
Compare
nunojsa
left a comment
nunojsa
left a comment
There was a problem hiding this comment.
The comments now look much better 😄
adi_spi_probe() captured drv_data->sclk_rate via clk_get_rate() before clk_prepare_enable() and never checked the result. If the rate ever reads zero (misconfigured or orphaned clock tree), hz_to_spi_clock() programs SPI_CLOCK to 0 on every transfer: SCLK never toggles and every RX byte silently reads back 0x00 with no error anywhere. Read the rate after clk_prepare_enable() -- a rate read before prepare/enable is not guaranteed valid in general (e.g. CLK_GET_RATE_NOCACHE clocks) -- and fail probe outright on a zero rate instead of producing a silently dead bus. On the SC846 SOM EZ-Kit the rate reads 125 MHz at either position; this is a robustness cleanup, not a bug fix there. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Handle the generic PIN_CONFIG_INPUT_ENABLE pinconf param so board
DTSes can enable a pad's input buffer (PORT_INEN) without also
having to claim the pin as a GPIO consumer.
Rationale: HRM §16 (line 941 on the SC84x HRM) says PORT_INEN gates
the input driver. The pinX block observes the pad AFTER this buffer,
so a pin used purely as an edge IRQ source (e.g. an ADC's DREADY
line) sees no edges when INEN=0. Today the only way to get INEN=1
on such a pin is:
* mux it to a peripheral function -- the driver's portmux_setup
already writes INEN_SET (see the earlier "pinctrl: adi-adsp:
enable input buffer on peripheral-muxed pins" patch), OR
* gpiod_get(..., GPIOD_IN) it from somewhere -- which forces
direction_input(), which writes INEN_SET as a side-effect.
Neither is possible for a bare interrupt-only consumer whose driver
already uses `interrupts=`/`interrupt-names=` (and not `-gpios=`).
The generic `input-enable` pinconf property in the consumer's
`pinctrl-N` group is the right knob for this. The port-gpio driver
already exposes the underlying MMR helpers; wire them up.
`arg == 0` -> disable (INEN_CLEAR), `arg != 0` -> enable (INEN_SET).
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
The TX xmit buffer is mapped once for the port's lifetime with dma_map_single() in startup and unmapped in shutdown. Each transfer only builds a scatterlist VIEW into that mapping via kfifo_dma_out_prepare_mapped() — no per-transfer mapping exists, yet the completion callback, the prep-failure path and stop_tx all called dma_unmap_sg() on it. CONFIG_DMA_API_DEBUG flags this on every TX burst: DMA-API: adi-uart4 31003000.uart: device driver frees DMA memory with different size [map size=4096 bytes] [unmap size=52 bytes] On the current coherent dma-direct platforms this only corrupts the DMA-API bookkeeping, but behind an IOMMU it would tear down the live xmit-buffer mapping mid-lifetime. Drop the bogus unmaps; the cache maintenance for the device remains the dma_sync_single_for_device() performed before every submit. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
… domains The PINT nodes carried the SC59x GIC SPI numbers (65..72), but on SC846 the PINT interrupts sit on GIC SPI 217..224 (per the SC846 SVD, verified on the SC846 SOM EZ-kit: with 65..72 the chained handler installs on lines nothing is wired to and every pint consumer silently receives zero interrupts). Also add the standard interrupt-controller binding (plus the "#interrupt-cells" property) to each PINT: the pint driver already supports irq_domain_xlate_onecell, so consumer nodes can use plain interrupt-parent = <&pintN>; interrupts = <M>; to receive a PINT-domain interrupt (e.g. a data-ready GPIO). Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
With snps,mixed-burst (inherited from the SC59x configuration), sustained MAC DMA traffic hard-hangs the SC846 SoC silently -- no exception, no panic, no watchdog -- independent of which DDR region the buffers live in. Observed on the SC846 SOM EZ-kit: ssh streams die after ~150 MB, low-CPU UDP streaming after ~750 MB, and a 1 Gb/s iiod buffer capture within seconds of starting. Switching to snps,fixed-burst makes the same workloads run indefinitely (validated with multi-GB UDP/TCP streams and long iiod captures). Burst length (snps,pbl = 8) and TSO are not part of the problem and keep their values, so throughput is unaffected. This is a workaround, marked REVISIT in the dtsi: the root cause of the hang is not yet confirmed and may be related to the Rev B SOM LPDDR4 signal-margin issue (fixed in Rev C of the SOM). Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
The HADC node carried GIC SPI 186 over from the SC59x device tree, but per the SC846 HRM interrupt list (and SVD) HADC0_EVT is GIC SPI 118, edge sensitive. With the stale number the enabled HADC never receives its event interrupt. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Several (mostly disabled) peripheral nodes still carried the SC59x GIC
SPI numbers. Correct them per the SC846 HRM system interrupt list and
SVD:
- thermal (TMU0): 7/8 -> 347 (TMU0_FAULT) / 348 (TMU0_ALERT)
(7/8 are the SC846 CGU0/CGU1 event interrupts)
- can0 (CANFD0): 84-86 -> 1/2/3 (WU / IRQ / MSG)
- can1 (CANFD1): 87-89 -> 4/5/6
(84-89 are EMAC0 DMA channel interrupts on SC846)
- lp0: 117/118 -> 152 (LP0_DMA) / 153 (LP0_STAT)
- lp1: 119/120 -> 154 (LP1_DMA) / 155 (LP1_STAT)
- pkte (0x310CD000): 161 -> 226 (PKTE0_IRQ)
- crc2 / crc3: 204/205 -> 48/49 (DCNTEXP, matching crc0/crc1)
- crc2_dma / crc3_dma (MDMA4/5 source channels):
200/289, 202/291 -> 44/54, 46/56
- sram-controller (L2CTL0): 10 -> 143 (L2CTL0_ECC_ERR)
- mmc0: the eMMC host on SC846 is EMSI0 at 0x31152000 with interrupts
214 (MSHC) / 215 (wakeup) -- the node pointed at the SC59x MSHC
address and interrupts
Also note on the CAN nodes that the SC846 hardware is CAN FD, which
the legacy adi,can binding does not cover.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Drop three nodes inherited from the SC59x device tree that describe
peripherals which do not exist on the SC846:
- emac1 (plus its alias and emac1_clkin): the SC84x has a single
10/100/1000 EMAC per the datasheet feature table; the node's
interrupt (227) is PWM0_TRIP on SC846, and no second EMAC appears
in the SC846 interrupt list or SVD.
- rtc0: no RTC block exists in the SC846 memory map or interrupt list.
- ospi: the SC59x Cadence OSPI controller does not exist at
0x31027000 on SC846 (nothing is mapped there). Serial flash on
SC84x is served by two different facilities, both still described
or describable:
* the two "Quad-Data Bit SPI" instances from the datasheet
feature table are SPI1/SPI2 (the adi,spi3 IP with quad data
pins and memory-mapped ranges at 0x60000000), whose nodes
remain in this file, and
* the two xSPI octal/HyperBus flash controllers (XSPI0 at
0x3101C000, IRQ 386; XSPI1 at 0x3114C000, IRQ 387; HRM ch.24),
a new IP needing its own binding and driver support.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Unlike the other SPI controller nodes, spi0 carried no clocks reference on either SoC. The adi,spi3 driver requires its "spi" functional clock -- the CDU gate for the SPI clock domain -- and only clk_prepare_enable() on that reference switches the gate on, so a board enabling spi0 had to know to add the clock itself (and getting the ID wrong, e.g. by porting the SC598 value, silently enables the wrong gate: index 63 is the LP clock on the SC846 provider). The functional clock is a property of the SoC, not the board: add it to the spi0 nodes in both SoC dtsi files, matching spi1/spi2/spi5. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
6fbda9d to
8f1da79
Compare
4 participants
Platform-level fixes for SC846/SC84x on adsp-6.18.31-y, independent of
any new peripheral drivers. All hardware-validated on the SC846 SOM
EZ-kit (MUN lab) unless noted.
Interrupt and device-tree correctness (sc846.dtsi)
SPIs (65..72); on SC846 they are 217..224 (SVD + HRM, verified on
hardware — with the old numbers every pint consumer silently gets
zero interrupts). Also adds the standard
interrupt-controllerbinding to each PINT so consumer nodes can take PINT-domain
interrupts directly.
corrected against the SC846 HRM interrupt list/SVD: TMU thermal,
CAN FD 0/1, link ports, PKTE, CRC2/3 + their MDMA channels,
L2CTL0/sram-controller, and the eMMC host (EMSI0 is at 0x31152000,
IRQs 214/215 — the node pointed at the SC59x MSHC address).
one EMAC), rtc0, and the SC59x OSPI node at an unmapped address
(flash on SC84x is served by the quad-capable SPI1/SPI2 and the two
xSPI octal/HyperBus controllers, which need their own support).
Stability fixes
snps,mixed-burst, sustained MACDMA traffic hard-hangs the SoC silently (no exception, no watchdog;
reproducible within a few hundred MB of streaming). Fixed bursts run
the same workloads indefinitely; pbl/TSO unchanged. Validated with
multi-GB streams and long iiod captures.
dma_unmap_sgcalls onthe TX scatterlist (DMA-API debug flagged map/unmap size mismatch).
clock, and fail probe loudly if it reads 0.
Usability / enablement
after its peripheral (
adi-dma uart0-txetc. in /proc/interrupts),with
labelproperties added for all SC846 and SC59x channels.peripheral-muxed pins (peripheral inputs don't see the pin without
INEN) and support
PIN_CONFIG_INPUT_ENABLE.the SC846 SOM device tree instead of magic numbers.
Validation
Boot-tested on SC846 SOM EZ-kit (base sc846-som-ezkit.dtb): clean
boot, Ethernet stable under multi-GB streaming, named DMA IRQs
visible, no DMA-API warnings. DTBs for all SC59x/SC84x boards build
cleanly.