Re: [Linux-stm32] [PATCH 1/5] ARM: dts: stm32: Add missing detach mailbox for emtrion emSBC-Argon

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/30/23 10:43, Arnaud POULIQUEN wrote:
Hello Marek,

Hi,

ST Restricted

-----Original Message-----
From: Linux-stm32 <linux-stm32-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Behalf Of Marek Vasut
Sent: Thursday, May 18, 2023 3:13 AM
To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: Marek Vasut <marex@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx; Conor
Dooley <conor+dt@xxxxxxxxxx>; Krzysztof Kozlowski
<krzysztof.kozlowski+dt@xxxxxxxxxx>; Richard Cochran
<richardcochran@xxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Maxime
Coquelin <mcoquelin.stm32@xxxxxxxxx>; linux-stm32@st-md-
mailman.stormreply.com; kernel@xxxxxxxxxxxxxxxxxx
Subject: [Linux-stm32] [PATCH 1/5] ARM: dts: stm32: Add missing detach
mailbox for emtrion emSBC-Argon

Add missing "detach" mailbox to this board to permit the CPU to inform the
remote processor on a detach. This signal allows the remote processor
firmware to stop IPC communication and to reinitialize the resources for a
re-attach.

Without this mailbox, detach is not possible and kernel log contains the
following warning to, so make sure all the STM32MP15xx platform DTs are in
sync regarding the mailboxes to fix the detach issue and the warning:
"
stm32-rproc 10000000.m4: mbox_request_channel_byname() could not
locate channel named "detach"
"

Fixes: 6257dfc1c412 ("ARM: dts: stm32: Add coprocessor detach mbox on
stm32mp15x-dkx boards")
Signed-off-by: Marek Vasut <marex@xxxxxxx>
---
Cc: Alexandre Torgue <alexandre.torgue@xxxxxxxxxxx>
Cc: Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>
Cc: Maxime Coquelin <mcoquelin.stm32@xxxxxxxxx>
Cc: Richard Cochran <richardcochran@xxxxxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: devicetree@xxxxxxxxxxxxxxx
Cc: kernel@xxxxxxxxxxxxxxxxxx
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: linux-stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
---
  arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi
b/arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi
index b01470a9a3d53..82061c9186338 100644
--- a/arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi
+++ b/arch/arm/boot/dts/stm32mp157c-emstamp-argon.dtsi
@@ -366,8 +366,8 @@ &iwdg2 {
  &m4_rproc {
  	memory-region = <&retram>, <&mcuram>, <&mcuram2>,
<&vdev0vring0>,
  			<&vdev0vring1>, <&vdev0buffer>;
-	mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>;
-	mbox-names = "vq0", "vq1", "shutdown";
+	mboxes = <&ipcc 0>, <&ipcc 1>, <&ipcc 2>, <&ipcc 3>;
+	mbox-names = "vq0", "vq1", "shutdown", "detach";

Why do you want to add the detach mailbox?
It looks to me here that you want to clean the warning message, right?

Yes

The detach is used in a particular usecase where the main processor
is  shutdown while the coprocessor is still running.
I would prefer to not enable it by default as it need a specific
coprocessor Firmware.

Why is it enabled by default on ST boards and left out on all other boards ?

Surely the ST evaluation boards can load and run both types of firmware, ones which do use the detach mailbox and ones which do not use the detach mailbox , right ?

I assume that if the firmware does not use the detach mailbox, then the detach mailbox is just ignored and unused, so there is no problem with having it described in the DT in any case ?

And if that's the case, then I would much rather prefer to have all the boards describe the same set of mailboxes, so they don't diverge . What do you think ?

Rather than adding unused optional mailbox, I will more in favor
of having a mbox_request_channel_byname_optional helper or
something similar

See above, I think it is better to have the mailbox described in DT always and not use it (the user can always remove it), than to not have it described on some boards and have it described on other boards (inconsistency).



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux