kernel/linux.git/drivers/soc/sunxi, branch v7.2-rc1

soc: sunxi: sram: Add H616 SRAM regions

2026-04-27T15:25:35+00:00

The Allwinner H616 has two switchable peripheral SRAM regions: - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access to this region is enabled by default. CPU access can be disabled, after which reads will show the same stale value for all addresses, while writes are ignored. The mux value for this region is different from previous generations. - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64 KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When CPU access is disabled, the whole region reads as zero, while writes are ignored. The mux value for this region is the same as on the A64 and H6. Add data for the VE SRAM. The register values were taken from the BSP vendor kernel. Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260324164357.1607247-7-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: Support claiming multiple regions per device

2026-04-27T15:25:35+00:00

On the H616, the video engine needs to claim two SRAM regions. Support claiming multiple regions per device. Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260324164357.1607247-6-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: Allow SRAM to be claimed multiple times

2026-04-27T15:25:35+00:00

On the H616, the SRAM C region is an alias mapping to part of the VE SRAM (accessible in whole at a different address) and part of the DE SRAM (otherwise unaccessible). As such both the VE and DE need to claim this SRAM region to prevent access from the CPU. The SRAM claim API is designed so that a "claim" routes the SRAM to the peripheral device, disabling access from the CPU. So long as the written register value is the same for all the claimants involved, allowing multiple or repeated claims is trivial. This is indeed the case for all supported SRAM regions. The only known SRAM region to have multiple different settings is the SRAM C2 region; this can be claimed by the AE, CE, or ACE (assumed to be AE + CE). This region is not supported, and likely will never be needed nor supported, as there is no documentation for the peripherals involved. Change the SRAM region "claimed" field from a boolean to a reference count. A claim will increment the count, while a release decreases it. The first claim will trigger the register value write. The driver otherwise behaves as before. Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260324164357.1607247-5-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: Const-ify sunxi_sram_func data and references

2026-04-27T15:25:35+00:00

sunxi_sram_func contains value mapping that do not change at runtime. Const-ify them. Reviewed-by: Jernej Skrabec Link: https://patch.msgid.link/20260324164357.1607247-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: mbus: don't access of_root directly

2026-03-13T09:21:31+00:00

Don't access of_root directly as it reduces the build test coverage for this driver with COMPILE_TEST=y and OF=n. Use existing helper functions to retrieve the relevant information. Suggested-by: Rob Herring Acked-by: Jernej Skrabec Signed-off-by: Bartosz Golaszewski Reviewed-by: Rob Herring (Arm) Link: https://patch.msgid.link/20260223-soc-of-root-v2-9-b45da45903c8@oss.qualcomm.com Signed-off-by: Greg Kroah-Hartman

soc: sunxi: sram: register regmap as syscon

2025-09-10T12:51:26+00:00

If the system controller had a ethernet controller glue layer control register, a limited access regmap would be registered and tied to the system controller struct device for the ethernet driver to use. Until now, for the ethernet driver to acquire this regmap, it had to do a of_parse_phandle() + find device + dev_get_regmap() sequence. Since the syscon framework allows a provider to register a custom regmap for its device node, and the ethernet driver already uses syscon for one platform, this provides a much more easier way to pass the regmap. Use of_syscon_register_regmap() to register our regmap with the syscon framework so that consumers can retrieve it that way. Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250908181059.1785605-5-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: add entry for a523

2025-09-10T12:51:25+00:00

The A523 has two Ethernet controllers. So in the system controller address space, there are two registers for Ethernet clock delays, one for each controller. Add a new entry for the A523 system controller that allows access to the second register. Acked-by: Jernej Skrabec Link: https://patch.msgid.link/20250908181059.1785605-4-wens@kernel.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: Constify struct regmap_config

2024-07-10T16:47:13+00:00

`sunxi_sram_regmap_config` is not modified and can be declared as const to move its data to a read-only section. Signed-off-by: Javier Carrasco Reviewed-by: Andre Przywara Link: https://lore.kernel.org/r/20240705-sunxi-sram-const-regmap_config-v1-1-1b997cd65d0f@gmail.com Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: Remove unused list 'claimed_sram'

2024-05-28T13:28:11+00:00

The list 'claimed_sram' seems unused, as far as I can tell it always has been. I think the 'list' member of sunxi_sram_data was intended to be used when it was on that list. Remove them. Build tested only. Signed-off-by: Dr. David Alan Gilbert Link: https://lore.kernel.org/r/20240504204401.198913-1-linux@treblig.org Signed-off-by: Chen-Yu Tsai

soc: sunxi: sram: export register 0 for THS on H616

2024-03-11T16:14:46+00:00

The Allwinner H616 SoC contains a mysterious bit at register offset 0x0 in the SRAM control block. If bit 16 is set (the reset value), the temperature readings of the THS are way off, leading to reports about 200C, at normal ambient temperatures. Clearing this bits brings the reported values down to the expected values. The BSP code clears this bit in firmware (U-Boot), and has an explicit comment about this, but offers no real explanation. Experiments in U-Boot show that register 0x0 has no effect on the SRAM C visibility: all tested bit settings still allow full read and write access by the CPU to the whole of SRAM C. Only bit 24 of the register at offset 0x4 makes all of SRAM C inaccessible by the CPU. So modelling the THS switch functionality as an SRAM region would not reflect reality. Since we should not rely on firmware settings, allow other code (the THS driver) to access this register, by exporting it through the already existing regmap. This mimics what we already do for the LDO control and the EMAC register. To avoid concurrent accesses to the same register at the same time, by the SRAM switch code and the regmap code, use the same lock to protect the access. The regmap subsystem allows to use an existing lock, so we just need to hook in there. Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-2-andre.przywara@arm.com