History log of /linux-master/drivers/remoteproc/meson_mx_ao_arc.c
Revision Date Author Comments
# ad123059 04-May-2023 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

remoteproc: meson_mx_ao_arc: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20230504194453.1150368-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>


# faf88ed1 04-Oct-2021 Dan Carpenter <dan.carpenter@oracle.com>

remoteproc: meson-mx-ao-arc: fix a bit test

The MESON_AO_RPROC_SRAM_USABLE_BITS macro is used like this:

if (priv->sram_pa & ~MESON_AO_RPROC_SRAM_USABLE_BITS) {
dev_err(dev, "SRAM address contains unusable bits\n");

The problem is that "->sram_pa" is type phys_addr_t which is potentially
64 bits. That means the MESON_AO_RPROC_SRAM_USABLE_BITS macro needs to
be a 64 bit type as well to ensure that high 32 bits are cleared.

Fixes: 6cb58ea897dd ("remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211004105257.GA27301@kili


# 6cb58ea8 21-Sep-2021 Martin Blumenstingl <martin.blumenstingl@googlemail.com>

remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor

Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for waking up the
ARM cores after system suspend.

The configuration is spread across three different registers:
- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
is unknown. There is a second remap register which is not used in the
vendor kernel (which served as reference for this driver).
- AO_CPU_CNTL is used to start and stop the ARC core.
- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.

To boot the ARC core we also need to enable it's gate clock and trigger
a reset.

The actual code for this ARC core can come from an ELF binary, for
example by building the Zephyr RTOS for an ARC EM4 core and then taking
"zephyr.elf" as firmware. This executable does not have any "rsc table"
so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210921192557.1610709-3-martin.blumenstingl@googlemail.com
[Fixed header file order]
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>