History log of /rk3399_ARM-atf/plat/allwinner/sun50i_h616/sunxi_power.c (Results 1 – 11 of 11)
Revision Date Author Comments
# 11f03c2e 17-Nov-2025 Manish Pandey <manish.pandey2@arm.com>

Merge "fix(allwinner): avoid crash when running without DTB" into integration


# 69b4a591 15-Oct-2025 Andre Przywara <andre.przywara@arm.com>

fix(allwinner): avoid crash when running without DTB

For determining the PMIC type and the bus its connected to, we use the
DTB that is appended to the U-Boot binary, by looking for it in DRAM.
And

fix(allwinner): avoid crash when running without DTB

For determining the PMIC type and the bus its connected to, we use the
DTB that is appended to the U-Boot binary, by looking for it in DRAM.
And while we bail out correctly if we don't find it there, we later try
to use the DTB pointer - without checking.

Add a check in sunxi_pmic_setup(), to only proceed if we have found a
DTB before, and exit early otherwise.

This fixes more experimental setups, where TF-A is run without U-Boot.

Change-Id: I9a7677be057a84fe6bee093d098be758970eec81
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...


# d359a6d7 11-Jun-2025 André Przywara <andre.przywara@arm.com>

Merge "fix(allwinner): fix variable may be used uninitialized error" into integration


# ce750f16 15-May-2025 Boyan Karatotev <boyan.karatotev@arm.com>

fix(allwinner): fix variable may be used uninitialized error

When building with LTO, the compiler observes that i2c_read() can return
without writing val, declaring the variable may be used unnitial

fix(allwinner): fix variable may be used uninitialized error

When building with LTO, the compiler observes that i2c_read() can return
without writing val, declaring the variable may be used unnitialized.
However, there is a sufficient error check that will prevent an actual
use. So calm the compiler by giving a safe default.

Change-Id: I558618467ae324a6b5b495ec9d204935135f226d
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>

show more ...


# 55b4c5ce 29-Jul-2024 Manish Pandey <manish.pandey2@arm.com>

Merge changes from topic "h616_pmics" into integration

* changes:
feat(allwinner): adjust H616 L2 cache size in DTB
feat(allwinner): h616: add support for AXP717 PMIC
feat(allwinner): h616: ad

Merge changes from topic "h616_pmics" into integration

* changes:
feat(allwinner): adjust H616 L2 cache size in DTB
feat(allwinner): h616: add support for AXP717 PMIC
feat(allwinner): h616: add support for AXP313 PMIC
feat(allwinner): h616: add I2C PMIC support
refactor(allwinner): h616: prepare for more than one PMIC model

show more ...


# 646d06b2 21-Mar-2024 Andre Przywara <andre.przywara@arm.com>

feat(allwinner): h616: add support for AXP717 PMIC

On at least one new device we see an Allwinner H700 SoC paired with the
X-Powers AXP717 PMIC. In contrast to the small AXP313, this is a quite
comp

feat(allwinner): h616: add support for AXP717 PMIC

On at least one new device we see an Allwinner H700 SoC paired with the
X-Powers AXP717 PMIC. In contrast to the small AXP313, this is a quite
complete PMIC, with many voltage rails, battery and USB-C charging
support. It supports both RSB and I2C control options.

Add the compatible string to the list of checked devices. The AXP717
apparently does not feature a version ID register, but we read 0xff from
that address 0x3, so use this as an indication of its presence, since
this value differs from what we read from the other PMICs.
The register offset and bit position for the power off functionality is
again different, but easy to put into our switch/case.

Setting up regulators in TF-A is now somewhat obsolete, since U-Boot
does a much better job in this now, and can figure out which regulators
are actually needed. So we don't add the regulator setup code, and just
use the PMIC for the power-off functionality.

Change-Id: Ie6b4c91517014adcc79d9a3459c75545fa3a63e6
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...


# 03851367 21-Mar-2024 Andre Przywara <andre.przywara@arm.com>

feat(allwinner): h616: add support for AXP313 PMIC

Many newer boards with the H616 and its sibling H618 are now paired
with the X-Powers AXP313 PMIC. This is a simpler PMIC, with only a few
voltage

feat(allwinner): h616: add support for AXP313 PMIC

Many newer boards with the H616 and its sibling H618 are now paired
with the X-Powers AXP313 PMIC. This is a simpler PMIC, with only a few
voltage rails and no extra functionality except the power key support.
In contrast to the AXP305 it can only be controlled via I2C.

Add a check to look for the AXP313 compatible string in the devicetree,
and set the PMIC type and I2C address accordingly, if one is found.
With only very few voltage rails available, all of them are mostly in
use and are thus enabled at reset already, so we can skip the regulator
setup entirely.

Change-Id: I01962854109e43793b4f56553c1ca9e1f752e30d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...


# 04445898 21-Mar-2024 Andre Przywara <andre.przywara@arm.com>

feat(allwinner): h616: add I2C PMIC support

The X-Powers AXP305 PMIC can be controlled via both I2C or RSB (an
Allwinner specific bus similar to I2C), but we chose to use only RSB,
because that's ea

feat(allwinner): h616: add I2C PMIC support

The X-Powers AXP305 PMIC can be controlled via both I2C or RSB (an
Allwinner specific bus similar to I2C), but we chose to use only RSB,
because that's easier to program and also used by Linux. The AXP313a
PMIC however supports only I2C, so we need to support both buses, and
need to decide which to use at runtime.

Prepare the PMIC code to add (back) I2C support. We initially used I2C
on the H6/AXP805 combination, but replaced that later with RSB. So this
patch is bringing some of that older code back.

The decision whether to use I2C or RSB is made by the devicetree, since
on some boards even RSB capable PMICs are controlled via I2C, since they
share the bus with only I2C capable devices, for instance RTCs.

At the moment this will still use RSB to drive the AXP305, but the
(dynamic) I2C code will be used shortly to support the AXP313.

This increases the code size by one 4K page, but with 80K out of the
reserved 256K we are still very far away from our limit.

Change-Id: I65c1e7df93dbd2dcd171b3fc486533a2948cc75b
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...


# a0597ba2 21-Mar-2024 Andre Przywara <andre.przywara@arm.com>

refactor(allwinner): h616: prepare for more than one PMIC model

Most devices based on Allwinner SoCs come with a certain fixed
combination of Power Management ICs (PMICs) and SoC, for instance the
A

refactor(allwinner): h616: prepare for more than one PMIC model

Most devices based on Allwinner SoCs come with a certain fixed
combination of Power Management ICs (PMICs) and SoC, for instance the
A64 with the AXP803, or the H6 with the AXP805. This allowed us to
include the respective PMIC support code into each build target at build
time.

Similarly on H616 devices we initially saw only the AXP305, but for a
while now the simpler (and cheaper) AXP313a is a popular companion to
the H616 on many new boards. On at least one new device the AXP717 is
used as well.
With some rudimentary AXP version check in place we at least detected
the case of an unsupported SoC, but threw an error message, and lost
support for powering off the device.

Refactor the existing PMIC code to be able to support more than one
PMIC model, detected at runtime. For this we use a variable for the RSB
runtime address instead of hardcoding the address used on the AXP305,
and read the hardware bus address from the devicetree.
Also we look up the used PMIC in the devicetree, and set the PMIC model
accordingly. To be on the safe side, we also confirm the real PMIC used
by checking its version register and comparing that with the expected
value. Finally the register offset and value to power off the PMIC is
moved direclty into the platform code, as those values differ between
the different PMICs.

This is just refactoring and better error report, we still only support
the AXP305 on RSB at the moment.

Change-Id: I00b26ce4d30bb570ee1cd4979d0cdc9d6c020729
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...


# 8078b5c5 30-Mar-2021 André Przywara <andre.przywara@arm.com>

Merge changes from topic "allwinner_h616" into integration

* changes:
allwinner: H616: Add reserved-memory node to DT
allwinner: Add Allwinner H616 SoC support
allwinner: Add H616 SoC ID
all

Merge changes from topic "allwinner_h616" into integration

* changes:
allwinner: H616: Add reserved-memory node to DT
allwinner: Add Allwinner H616 SoC support
allwinner: Add H616 SoC ID
allwinner: Express memmap more dynamically
allwinner: Move sunxi_cpu_power_off_self() into platforms
allwinner: Move SEPARATE_NOBITS_REGION to platforms
doc: allwinner: Reorder sections, document memory mapping

show more ...


# 26123ca3 28-Nov-2020 Andre Przywara <andre.przywara@arm.com>

allwinner: Add Allwinner H616 SoC support

The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DR

allwinner: Add Allwinner H616 SoC support

The new Allwinner H616 SoC lacks the management controller and the secure
SRAM A2, so we need to tweak the memory map quite substantially:
We run BL31 in DRAM. Since the DRAM starts at 1GB, we cannot use our
compressed virtual address space (max 256MB) anymore, so we revert to
the full 32bit VA space and use a flat mapping throughout all of it.

The missing controller also means we need to always use the native PSCI
ops, using the CPUIDLE hardware, as SCPI and suspend depend on the ARISC.

Change-Id: I77169b452cb7f5dc2ef734f3fc6e5d931749141d
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...