| Age | Commit message (Collapse) | Author |
|---|
|
The current memory region assign only supports a single
memory region.
But new platforms introduces more regions to make the
memory requirements more flexible for various use cases.
Those new platforms also shares the memory region between the
DSP and HLOS.
To handle this, make the region assign more generic in order
to support more than a single memory region and also permit
setting the regions permissions as shared.
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20240123-topic-sm8650-upstream-remoteproc-v7-2-61283f50162f@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Use device lifecycle managed devm_rproc_add() helper function. This helps
prevent mistakes like deleting out of order in cleanup functions and
forgetting to delete on all error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240205182753.36978-6-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use a device lifecycle managed ioremap helper function. This helps prevent
mistakes like unmapping out of order in cleanup functions and forgetting
to unmap on all error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240205182753.36978-5-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use a device lifecycle managed action to release tps ti_sci_proc handle.
This helps prevent mistakes like releasing out of order in cleanup
functions and forgetting to release on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240205182753.36978-4-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use device lifecycle managed devm_kzalloc() helper function. This helps
prevent mistakes like freeing out of order in cleanup functions and
forgetting to free on all error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240205182753.36978-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed TI-SCI get() function. This helps prevent
mistakes like not put()'ing in the wrong order in cleanup functions and
forgetting to put() on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240205182753.36978-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-9-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-8-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184632.725054-1-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use a device lifecycle managed action to free memory. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184913.725435-3-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use a device lifecycle managed action to release reserved memory. This
helps prevent mistakes like releasing out of order in cleanup functions
and forgetting to release on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184913.725435-2-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240123184913.725435-1-afd@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
stm32_rproc_get_loaded_rsc_tablef
The sparse tool complains about the remove of the _iomem attribute.
stm32_rproc.c:660:17: warning: cast removes address space '__iomem' of expression
Add '__force' to explicitly specify that the cast is intentional.
This conversion is necessary to cast to addresses pointer,
which are then managed by the remoteproc core as a pointer to a
resource_table structure.
Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops")
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20240117135312.3381936-3-arnaud.pouliquen@foss.st.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The sparse tool complains about the attribute conversion between
a _iomem void * and a void *:
stm32_rproc.c:122:12: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *va @@ got void [noderef] __iomem * @@
stm32_rproc.c:122:12: sparse: expected void *va
stm32_rproc.c:122:12: sparse: got void [noderef] __iomem *
Add '__force' to explicitly specify that the cast is intentional.
This conversion is necessary to cast to virtual addresses pointer,used,
by the remoteproc core.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202312150052.HCiNKlqB-lkp@intel.com/
Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver")
Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20240117135312.3381936-2-arnaud.pouliquen@foss.st.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Recovery remote processor failed when wdg irq received:
[ 0.842574] remoteproc remoteproc0: crash detected in cix-dsp-rproc: type watchdog
[ 0.842750] remoteproc remoteproc0: handling crash #1 in cix-dsp-rproc
[ 0.842824] remoteproc remoteproc0: recovering cix-dsp-rproc
[ 0.843342] remoteproc remoteproc0: stopped remote processor cix-dsp-rproc
[ 0.847901] rproc-virtio rproc-virtio.0.auto: Failed to associate buffer
[ 0.847979] remoteproc remoteproc0: failed to probe subdevices for cix-dsp-rproc: -16
The reason is that dma coherent mem would not be released when
recovering the remote processor, due to rproc_virtio_remove()
would not be called, where the mem released. It will fail when
it try to allocate and associate buffer again.
Releasing reserved memory from rproc_virtio_dev_release(), instead of
rproc_virtio_remove().
Fixes: 1d7b61c06dc3 ("remoteproc: virtio: Create platform device for the remoteproc_virtio")
Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231217053659.3245745-1-joakim.zhang@cixtech.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Add support for the ADSP, CDSP and WPSS remoteprocs found on the SC7280
SoC using the q6v5-pas driver.
This driver can be used on regular LA ("Linux Android") based releases,
however the SC7280 ChromeOS devices need different driver support due to
firmware differences.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-6-6aa394d33edf@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
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 ignored (apart
from emitting a warning) 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. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
There is no change in behaviour as .remove() already returned zero
unconditionally.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231123211657.518181-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The error message
failed to send mailbox message (-EINVAL)
is (for a human) more useful than
failed to send mailbox message, status = -22
Adapt all error messages to use the symbolic names instead of the
numeric constants. The error paths in .probe() make use of
dev_err_probe() which automatically handles EPROBE_DEFER.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231123211657.518181-7-u.kleine-koenig@pengutronix.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
When the remove callback returns non-zero, the driver core emits an
error message about the error value being ignored. As the driver already
emits an error message already, return zero. This has no effect apart
from suppressing the core's message. The platform device gets unbound
irrespective of the return value.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20231123211657.518181-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Add the .find_loaded_rsc_table operation for i.MX DSP.
We need it for inter-process communication between DSP
and main core.
This callback is used to find the resource table (defined
in remote processor linker script) where the address of the
vrings along with the other allocated resources (carveouts etc)
are stored.
If this is not found, the vrings are not allocated and
the IPC between cores will not work.
Signed-off-by: Iuliana Prodan <iuliana.prodan@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Link: https://lore.kernel.org/r/20231013152731.23471-2-iuliana.prodan@oss.nxp.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Clang warns (or errors with CONFIG_WERROR=y):
drivers/remoteproc/st_remoteproc.c:357:6: error: variable 'ret' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
357 | if (!ddata->config)
| ^~~~~~~~~~~~~~
drivers/remoteproc/st_remoteproc.c:442:9: note: uninitialized use occurs here
442 | return ret;
| ^~~
drivers/remoteproc/st_remoteproc.c:357:2: note: remove the 'if' if its condition is always false
357 | if (!ddata->config)
| ^~~~~~~~~~~~~~~~~~~
358 | goto free_rproc;
| ~~~~~~~~~~~~~~~
drivers/remoteproc/st_remoteproc.c:348:9: note: initialize the variable 'ret' to silence this warning
348 | int ret, i;
| ^
| = 0
1 error generated.
Set ret to -ENODEV, which seems to be a standard return code when
device_get_match_data() returns NULL.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1944
Fixes: 5c77ebcd05ac ("remoteproc: st: Use device_get_match_data()")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20231012-st_remoteproc-fix-sometimes-uninit-v1-1-f64d0f2d5b37@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20231009211356.3242037-10-robh@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Introduce device address in hardcode TCM table.
Device address is used for address translation.
Also, previous method(hack) to mask few bits from address
to achieve address translation is removed
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20230925172648.2339048-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
In older devicetrees we had the ChromeOS EC in a node called "cros-ec"
instead of the newer "cros-ec-rpmsg", but this driver is now checking
only for the latter, breaking compatibility with those.
Besides, we can check if the SCP is single or dual core by simply
walking through the children of the main SCP node and checking if
if there's more than one "mediatek,scp-core" compatible node.
Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Tested-by: Laura Nao <laura.nao@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230919092336.51007-1-angelogioacchino.delregno@collabora.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The PNoC clock is a clock for the entire PNoC bus, managed from
within the interconnect driver. Attaching it to MSS was a total hack.
Get rid of it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230721-topic-rpm_clk_cleanup-v2-10-1e506593b1bd@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add a config for the MPSS present on SM6375.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230725-topic-6375_rproc-v5-3-a8e9cde56a20@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Add a config for the ADSP&CDSP present on SM6375.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230725-topic-6375_rproc-v5-2-a8e9cde56a20@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
sc7180 has a dedicated ADSP similar to the one found in sm8250.
Add it's compatible to the driver reusing the existing config so
the devices that use the adsp can probe it.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20230907-sc7180-adsp-rproc-v3-2-6515c3fbe0a3@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
In lockstep mode following is TCM address map:
| *TCM* | *R5 View* | *Linux view* |
| R5_0 ATCM (128 KB) | 0x0000_0000 | 0xFFE0_0000 |
| R5_0 BTCM (128 KB) | 0x0002_0000 | 0xFFE2_0000 |
Current driver keeps single TCM carveout in lockstep mode
as ATCM and BTCM addresses form contiguous memory region.
Although the addresses are contiguous, it is not same type
of memory. ATCM typically holds interrupt or exception code
that must be accessed at high speed. BTCM typically holds
a block of data for intensive processing, such as audio or
video processing. As both are different types of memory,
they should be allocated as different carveout. This patch
is fixing TCM carveout allocation in lockstep mode.
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20230913024323.2768114-1-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The error message doesn't accurately reflect the cause of
the error. The error is due to a handler not being found,
not an invalid IPI ID.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-14-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
To ensure consistent behavior, the watchdog timeout handling of the
multi-core SCP should reset the whole SCP sub-system when watchdog
timeout. Triggering the rproc recovery flow on all instances will
ensure proper recovery of the SCP sub-system.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-13-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The MT8195 SCP core 1 watchdog timeout needs to be handled in the
SCP core 0 IRQ handler because the MT8195 SCP core 1 watchdog timeout
IRQ is wired on the same IRQ entry for core 0 watchdog timeout.
MT8195 SCP has a watchdog status register to identify the watchdog
timeout source when IRQ triggered.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-12-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Because MT8195 SCP core 0 and core 1 both boot from head of SRAM and
have the same viewpoint of SRAM, SCP has a "core 1 SRAM offset"
configuration to control the access destination of SCP core 1 to boot
core 1 from different SRAM location.
The "core 1 SRAM offset" configuration is composed by a range
and an offset. It works like a simple memory mapped mechanism.
When SCP core 1 accesses a SRAM address located in the range,
the SCP bus adds the configured offset to the address to
shift the physical destination address on SCP SRAM. This shifting is
transparent to the software running on SCP core 1.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-11-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
dual-core SCP
Previously, SCP core 0 controlled the power of L2TCM and dictated that
SCP core 1 could only boot after SCP core 0. To address this constraint,
extracted the power control flow of L2TCM and made it shared
between both cores, enabling support for arbitrary boot order.
The flow for controlling L2TCM power has been incorporated into the
mt8195_scp_before_load() and mt8195_scp_stop() APIs, which are
respectively invoked during the rproc->ops->start() and
rproc->ops->stop() operations. These APIs effectively serve the same
purpose as the rproc prepare()/unprepare() APIs."
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-10-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The difference of single-core SCP and multi-core SCP device tree is
the presence of child device nodes described SCP cores. The SCP
driver populates the platform device and checks the child nodes
to identify whether it's a single-core SCP or a multi-core SCP.
Add the remoteproc instances of multi-core SCP to the SCP cluster list.
When the SCP driver is removed, it cleanup resources by walking
through the cluster list.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-9-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
This is the 3rd preliminary step for probing multi-core SCP.
Rewrite the probing flow of single-core SCP to adapt with the 'cluster'
concept needed by the multi-core SCP. The SCP core object(s)
is maintained at the cluster list.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-8-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
This is the 2nd preliminary step for probing multi-core SCP.
Initialization of configuration and L1TCM registers is extracted
to only performed once on multi-core SCP. The rest of remoteproc
initialization procedure is similar for both single and multi-core
SCP and is applied to each core.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-7-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
This is the 1st preliminary steps for probing multi-core SCP.
The registers of config and l1tcm are common on single-core SCP
and multi-core SCP. Extract these registers out to reduce duplicated
fields in mtk_scp when multiple SCP instances are created.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-6-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
The SCP rproc driver has a set of chip dependent callbacks for
boot sequence and IRQ handling. Implement these callbacks for MT8195
SCP core 1.
Signed-off-by: Tinghan Shen <tinghan.shen@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230901080935.14571-5-tinghan.shen@mediatek.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Referring to platform_get_irq()'s definition, the return value has
already been checked if ret < 0, and printed via dev_err_probe().
Calling dev_err_probe() one more time outside platform_get_irq()
is obviously redundant. Removing outside dev_err_probe() to
clean it up.
Besides, switch to use platform_get_irq_optional() since the irq
is optional here.
Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20230817083336.404635-1-chenjiahao16@huawei.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux
Pull remoteproc updates from Bjorn Andersson:
"Support for booting the iMX remoteprocs using MMIO, instead of SMCCC
is added. The iMX driver is also extended to support delivering
interrupts from an arbitrary number of vdev.
Support is added to the TI PRU driver, to allow GPMUX to be controlled
from DeviceTree.
The Qualcomm coredump collector is extended to fall back to generating
a full coredump, in the case that the loaded firmware doesn't support
generating minidump. The overly terse MD abbreviation of "MINIDUMP" is
expanded, to make the code easier on the eye.
The list of Qualcomm Sensor Low Power Island (SLPI) instances
supported is cleaned up, and SDM845 is added. SDM630/636/660 support
for the modem subsystem (mss) is added.
All the Qualcomm drivers are transitioned to of_reserved_mem_lookup()
instead of open coding the resolution of reserved-memory regions, to
gain handling of error cases. A couple of drivers are transitioned to
use devm_platform_ioremap_resource_byname().
The stm32 remoteproc driver's PM operations are updated to modern
macros, to avoid the "unused variable"-warning in some configurations.
Drivers are transitioned away from directly including of_device.h"
* tag 'rproc-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux: (23 commits)
remoteproc: pru: add support for configuring GPMUX based on client setup
remoteproc: stm32: fix incorrect optional pointers
remoteproc: imx_rproc: Switch iMX8MN/MP from SMCCC to MMIO
dt-bindings: remoteproc: imx_rproc: Support i.MX8MN/P MMIO
dt-bindings: remoteproc: qcom,msm8996-mss-pil: Fix 8996 clocks
remoteproc: qcom: pas: add SDM845 SLPI compatible
remoteproc: qcom: q6v5-mss: Add support for SDM630/636/660
dt-bindings: remoteproc: qcom,msm8996-mss-pil: Add SDM660 compatible
remoteproc: qcom: Expand MD_* as MINIDUMP_*
remoteproc: qcom: pas: refactor SLPI remoteproc init
dt-bindings: remoteproc: qcom: adsp: add qcom,sdm845-slpi-pas compatible
remoteproc: qcom: wcnss: use devm_platform_ioremap_resource_byname()
remoteproc: qcom: q6v5: use devm_platform_ioremap_resource_byname()
dt-bindings: remoteproc: qcom: sm6115-pas: Add QCM2290
remoteproc: qcom: Add full coredump fallback mechanism
remoteproc: core: Export the rproc coredump APIs
remoteproc: qcom: Use of_reserved_mem_lookup()
remoteproc: imx_rproc: iterate all notifiyids in rx callback
dt-bindings: remoteproc: qcom,adsp: bring back firmware-name
dt-bindings: remoteproc: qcom,sm8550-pas: require memory-region
...
|
|
The GPMUX config value for a PRU device can now be configured by client
by specifying it in the device node ti,pruss-gp-mux-sel.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20230802064925.1895750-1-danishanwar@ti.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Compile-testing without CONFIG_OF shows that the of_match_ptr() macro
was used incorrectly here:
drivers/remoteproc/stm32_rproc.c:662:34: warning: unused variable 'stm32_rproc_match' [-Wunused-const-variable]
As in almost every driver, the solution is simply to remove the
use of this macro. The same thing happened with the deprecated
SIMPLE_DEV_PM_OPS(), but the corresponding warning was already shut
up with __maybe_unused annotations, so fix those as well by using the
correct DEFINE_SIMPLE_DEV_PM_OPS() macros and removing the extraneous
__maybe_unused modifiers. For completeness, also add a pm_ptr() to let
the PM ops be eliminated completely when CONFIG_PM is turned off.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202307242300.ia82qBTp-lkp@intel.com
Fixes: 03bd158e1535 ("remoteproc: stm32: use correct format strings on 64-bit")
Fixes: 410119ee29b6 ("remoteproc: stm32: wakeup the system by wdg irq")
Fixes: 13140de09cc2 ("remoteproc: stm32: add an ST stm32_rproc driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
Link: https://lore.kernel.org/r/20230724195704.2432382-1-arnd@kernel.org
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
With qmp_send() handling variable length messages and string formatting
he callers of qmp_send() can be cleaned up to not care about these
things.
Drop the QMP_MSG_LEN sized buffers and use the message formatting, as
appropriate.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Link: https://lore.kernel.org/r/20230811205839.727373-5-quic_bjorande@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The existing implementation of qmp_send() requires the caller to provide
a buffer which is of word-aligned. The underlying reason for this is
that message ram only supports word accesses, but pushing this
requirement onto the clients results in the same boiler plate code
sprinkled in every call site.
By using a temporary buffer in qmp_send() we can hide the underlying
hardware limitations from the clients and allow them to pass their
NUL-terminates C string directly.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230811205839.727373-2-quic_bjorande@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
The MX8M CM7 boot via SMC call is problematic, since not all versions
of ATF support this interface. Extend the MMIO support so it can boot
the CM7 on MX8MN/MP instead and discern the two alternatives using DT
compatible strings.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20230724222418.163220-2-marex@denx.de
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Add a compatible for the SDM845 SLPI to the Qualcomm remoteproc q6v5_pas
driver. The SLPI is the same as in SM8150, SM8250, SM8350, and SM8450,
so use the same resource in the driver.
Signed-off-by: Dylan Van Assche <me@dylanvanassche.be>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230330164633.117335-4-me@dylanvanassche.be
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Snapdragon 630/660 modem subsystem is similar to one in MSM8998
and can almost reuse it's reset sequence.
Downstream sources call this q6v5 version "qdsp6v62-1-5" and its
code path has additional checks for QDSP6v55_BHS_EN_REST_ACK
status [2].
Inspiration is taken from Konrad Dybcio's work in [1], but reworked
to use common code path with MSM8996/8998, instead of completely
separate "if" block for SDM660.
[1] https://github.com/SoMainline/linux/commit/7dd6dd9b936dc8d6c1f1abe299e5b065c33741e8
[2] https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/lavender-q-oss/drivers/soc/qcom/pil-q6v5.c#L393
Co-developed-by: Konrad Dybcio <konradybcio@gmail.com>
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230621175046.61521-2-alexeymin@postmarketos.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
|
Expand MD_* as MINIDUMP_* which makes more sense than the
abbreviation.
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
Link: https://lore.kernel.org/r/1683133352-10046-2-git-send-email-quic_mojha@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
