linux.git/drivers/remoteproc, branch master

Merge tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox

2024-09-29T16:53:04+00:00

Pull mailbox updates from Jassi Brar:

 - fix kconfig dependencies (mhu-v3, omap2+)

 - use devie name instead of genereic imx_mu_chan as interrupt name
   (imx)

 - enable sa8255p and qcs8300 ipc controllers (qcom)

 - Fix timeout during suspend mode (bcm2835)

 - convert to use use of_property_match_string (mailbox)

 - enable mt8188 (mediatek)

 - use devm_clk_get_enabled helpers (spreadtrum)

 - fix device-id typo (rockchip)

* tag 'mailbox-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox:
  mailbox, remoteproc: omap2+: fix compile testing
  dt-bindings: mailbox: qcom-ipcc: Document QCS8300 IPCC
  dt-bindings: mailbox: qcom-ipcc: document the support for SA8255p
  dt-bindings: mailbox: mtk,adsp-mbox: Add compatible for MT8188
  mailbox: Use of_property_match_string() instead of open-coding
  mailbox: bcm2835: Fix timeout during suspend mode
  mailbox: sprd: Use devm_clk_get_enabled() helpers
  mailbox: rockchip: fix a typo in module autoloading
  mailbox: imx: use device name in interrupt name
  mailbox: ARM_MHU_V3 should depend on ARM64

mailbox, remoteproc: omap2+: fix compile testing

2024-09-27T14:11:05+00:00

Selecting CONFIG_OMAP2PLUS_MBOX while compile testing
causes a build failure:

WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
  Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3)
  Selected by [m]:
  - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y])

Using 'select' to force-enable another subsystem is generally
a mistake and causes problems such as this one, so change the
three drivers that link against this driver to use 'depends on'
instead, and ensure the driver itself can be compile tested
regardless of the platform.

When compile-testing without CONFIG_TI_SCI_PROTOCOL=m, there
is a chance for a link failure, so add a careful dependency
on that.

arm-linux-gnueabi-ld: drivers/remoteproc/ti_k3_m4_remoteproc.o: in function `k3_m4_rproc_probe':
ti_k3_m4_remoteproc.c:(.text.k3_m4_rproc_probe+0x76): undefined reference to `devm_ti_sci_get_by_phandle'

Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Mathieu Poirier 
Reviewed-by: Andrew Davis 
Reviewed-by: Martyn Welch 
Signed-off-by: Jassi Brar

remoteproc: k3-m4: use the proper dependencies

2024-09-24T19:48:35+00:00

The TI_K3_M4_REMOTEPROC Kconfig entry selects OMAP2PLUS_MBOX, but that
driver in turn depends on other things, which the k4-m4 driver didn't.

This causes a Kconfig time warning:

  WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX
    Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3)
    Selected by [m]:
    - TI_K3_M4_REMOTEPROC [=m] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y])

because you can't select something that is unavailable.

Make the dependencies for TI_K3_M4_REMOTEPROC match those of the
OMAP2PLUS_MBOX driver that it needs.

Fixes: ebcf9008a895 ("remoteproc: k3-m4: Add a remoteproc driver for M4F subsystem")
Cc: Bjorn Andersson 
Cc: Martyn Welch 
Cc: Hari Nagalla 
Cc: Andrew Davis 
Cc: Mathieu Poirier 
Signed-off-by: Linus Torvalds

remoteporc: ingenic: Use devm_platform_ioremap_resource_byname()

2024-09-09T15:50:54+00:00

platform_get_resource_byname() and devm_ioremap_resource() can be
replaced by devm_platform_ioremap_resource_byname(), which can
simplify the code logic a bit, No functional change here.

Signed-off-by: Zhang Zekun 
Link: https://lore.kernel.org/r/20240906113405.92782-4-zhangzekun11@huawei.com
[Fixed patch title]
Signed-off-by: Mathieu Poirier

remoteproc: da8xx: Use devm_platform_ioremap_resource_byname()

2024-09-09T15:50:50+00:00

platform_get_resource_byname() and devm_ioremap_resource() can be
replaced by devm_platform_ioremap_resource_byname(), which can
simplify the code logic a bit, No functional change here.

Signed-off-by: Zhang Zekun 
Link: https://lore.kernel.org/r/20240906113405.92782-3-zhangzekun11@huawei.com
[Fixed patch title]
Signed-off-by: Mathieu Poirier

remoteproc: st_slim: Use devm_platform_ioremap_resource_byname()

2024-09-09T15:50:31+00:00

platform_get_resource_byname() and devm_ioremap_resource() can be
replaced by devm_platform_ioremap_resource_byname(), which can
simplify the code logic a bit, No functional change here.

Signed-off-by: Zhang Zekun 
Link: https://lore.kernel.org/r/20240906113405.92782-2-zhangzekun11@huawei.com
[Fixed patch title]
Signed-off-by: Mathieu Poirier

remoteproc: xlnx: Add sram support

2024-09-05T16:09:22+00:00

AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains. Platform management firmware is responsible
to operate these power-domains.

Signed-off-by: Tanmay Shah 
Link: https://lore.kernel.org/r/20240830173735.279432-1-tanmay.shah@amd.com
[Fixed dma_addr_t type cast when calling rproc_mem_entry_init()]
Signed-off-by: Mathieu Poirier

remoteproc: k3-r5: Fix error handling when power-up failed

2024-08-28T15:48:35+00:00

By simply bailing out, the driver was violating its rule and internal
assumptions that either both or no rproc should be initialized. E.g.,
this could cause the first core to be available but not the second one,
leading to crashes on its shutdown later on while trying to dereference
that second instance.

Fixes: 61f6f68447ab ("remoteproc: k3-r5: Wait for core0 power-up before powering up core1")
Signed-off-by: Jan Kiszka 
Acked-by: Beleswar Padhi 
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/9f481156-f220-4adf-b3d9-670871351e26@siemens.com
Signed-off-by: Mathieu Poirier

remoteproc: imx_rproc: Add support for poweroff and reboot

2024-08-26T16:25:15+00:00

On some NXP platforms (e.g i.MX7ULP) the poweroff and reboot operations
are done via a separate remote core.

Typically Linux needs to send a message to the remote core and requests
for poweroff or reboot.

By default the communication between Linux core and the remote core is
is done via a blocking mailbox mechanism but Linux doesn't allow blocking
operations in the system off (reboot, power off) handlers.

So, we need to make sure the mailbox message send operations do not block
for this specific operations. Fortunately, Linux allows us to register
handlers that are called in preparation of the system off operations.

Thus, before carrying the power off or reboot preparations, just destroy
the existing mailboxes and create them as non-blocking.

Note that power off and restart are totally different operations and are
not complementary.

We introduce a new flag in the imx remoteproc per device data which tells
us when a device needs this special setup. For now, only imx7ulp needs it.

Signed-off-by: Peng Fan 
Reviewed-by: Daniel Baluta 
Link: https://lore.kernel.org/r/20240822-imx_rproc-v3-2-6d943723945d@nxp.com
Signed-off-by: Mathieu Poirier

remoteproc: imx_rproc: Allow setting of the mailbox transmit mode

2024-08-26T16:25:15+00:00

Current mailbox is blocking by default, but there are cases where we don't
need to wait for a response.

Linux just needs to send data to the remote processor, so let's
allow tx_block mode to be set (true/false) depending on usecase.

No functional changes.

Signed-off-by: Peng Fan 
Reviewed-by: Daniel Baluta 
Link: https://lore.kernel.org/r/20240822-imx_rproc-v3-1-6d943723945d@nxp.com
Signed-off-by: Mathieu Poirier