From: Dinh Nguyen <dinguyen@kernel.org>
To: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org
Cc: dinguyen@kernel.org, devicetree@vger.kernel.org, rounakdas2025@gmail.com
Subject: [RFC 0/2] arm64: dts: socfpga: clarify MMIO vs non-MMIO nodes
Date: Wed, 2 Sep 2026 04:25:49 -0500 [thread overview]
Message-ID: <20260902092551.488203-1-dinguyen@kernel.org> (raw)
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
next reply other threads:[~2026-09-02 9:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 9:25 Dinh Nguyen [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902092551.488203-1-dinguyen@kernel.org \
--to=dinguyen@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=robh@kernel.org \
--cc=rounakdas2025@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox