Devicetree
 help / color / mirror / Atom feed
* [RFC 0/2] arm64: dts: socfpga: clarify MMIO vs non-MMIO nodes
@ 2026-09-02  9:25 Dinh Nguyen
  2026-09-02  9:25 ` [RFC PATCH 1/2] dt-bindings: edac: altera: agilex5: document new edac support Dinh Nguyen
  2026-09-02  9:25 ` [RFC PATCH 2/2] arm64: dts: socfpga: agilex5: add support for the ECC manager Dinh Nguyen
  0 siblings, 2 replies; 4+ messages in thread
From: Dinh Nguyen @ 2026-09-02  9:25 UTC (permalink / raw)
  To: robh, krzk+dt, conor+dt; +Cc: dinguyen, devicetree, rounakdas2025

Hi DTS maintainers,

This letter will try to explain this comment[1] regarding the eccmgr node
not having an addressable range, but it's children does.

I am only including the bindings and DTS patches for this RFC to
hopefully not confuse things more.

The eccmgr node is an interrupt aggregator / irqchip, not a standalone
register block. Its INTMASK and INTSTAT registers live inside the
System Manager. The driver reaches them through the altr,sysmgr-syscon
phandle (syscon/regmap), so the manager itself has no reg property and
no unit address. In DT terms it is not an MMIO device.

The children (ocram-ecc, usb-ecc, emac-*-ecc, sdmmc-ecc, l2-ecc,
dma-ecc, ...) are MMIO devices. Each peripheral has its own ECC
controller block at a unique SoC address. The driver maps that block
with of_address_to_resource() / ioremap, so those nodes have a reg
property and a unit address (for example ocram-ecc@ff8cc000).

The parent still has #address-cells, #size-cells, and ranges so those
child addresses can be translated to CPU physical addresses (identity
map). ranges describes the children's address space. It does not give
the parent its own MMIO window.

sdramedac is the exception among the children: SDRAM ECC registers
live in the SDR controller, accessed via altr,sdr-syscon, so that
child also has no reg.

The children stay under eccmgr because they are interrupt clients of
the manager's irqchip, and the A10/S10/Agilex driver walks the
manager's child nodes from probe. One shared IRQ domain, many
per-RAM ECC blocks.

I hope that explains the layout of the EDAC controller on SoCFPGA
platforms. I welcome any feedback.

Thanks,
Dinh

[1] https://lore.kernel.org/all/20260724-fragrant-baboon-of-temperance-c5cdc0@quoll/

Dinh Nguyen (2):
  dt-bindings: edac: altera: agilex5: document new edac support
  arm64: dts: socfpga: agilex5: add support for the ECC manager

 .../edac/altr,socfpga-ecc-manager.yaml        | 85 +++++++++++++------
 .../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 69 +++++++++++++++
 2 files changed, 130 insertions(+), 24 deletions(-)

-- 
2.42.0.411.g813d9a9188


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-09-02  9:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-02  9:25 [RFC 0/2] arm64: dts: socfpga: clarify MMIO vs non-MMIO nodes Dinh Nguyen
2026-09-02  9:25 ` [RFC PATCH 1/2] dt-bindings: edac: altera: agilex5: document new edac support Dinh Nguyen
2026-09-02  9:25 ` [RFC PATCH 2/2] arm64: dts: socfpga: agilex5: add support for the ECC manager Dinh Nguyen
2026-09-02  9:38   ` sashiko-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox