Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH 2/2] arm64: dts: qcom: Add basic support for LG G4 (H815)
From: Petr Vorel @ 2024-04-03 17:59 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Alexander Reimelt, andersson, konrad.dybcio, robh+dt,
	krzysztof.kozlowski+dt, conor+dt, linux-arm-msm, devicetree,
	linux-kernel
In-Reply-To: <10f02618-f16c-47d4-a27f-074b1ecffaa1@linaro.org>

Hi all,

> On 03/04/2024 12:43, Alexander Reimelt wrote:
> > To make it easier for downstream projects and avoid duplication of work.
> > Makes the device bootable and enables all buttons, most regulators, hall sensor, eMMC and SD-Card.

> > Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> > ---
> >  arch/arm64/boot/dts/qcom/Makefile            |   1 +
> >  arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts | 422 +++++++++++++++++++
> >  2 files changed, 423 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts


> Please use subject prefixes matching the subsystem. You can get them for
> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
> your patch is touching.

@Alexander arm: would be for 32bit. Correct subject prefix is:
arm64: dts: qcom: msm8992-lg-h815:

Krzysztof's comments are obviously correct.
Please Cc me on v2 to my gmail private mail. Thanks!

Kind regards,
Petr

^ permalink raw reply

* Re: [PATCH 1/7] dt-bindings: clock: Add PCIe pipe related clocks for IPQ9574
From: mr.nuke.me @ 2024-04-03 17:58 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio,
	Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: ansuelsmth, robimarko, linux-arm-msm, linux-clk, devicetree,
	linux-kernel
In-Reply-To: <e392a1dd-20bc-447c-82ab-f6256bf2be69@linaro.org>

On 4/3/24 02:10, Krzysztof Kozlowski wrote:
> On 02/04/2024 21:25, Alexandru Gagniuc wrote:
>> Add defines for the missing PCIe PIPE clocks.
>>
>> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>> ---
>>   include/dt-bindings/clock/qcom,ipq9574-gcc.h | 4 ++++
>>   1 file changed, 4 insertions(+)
> 
> I did not get half of this patchset. Are you sure you are CC-ing everyone?

The other changes are driver code that implements these DT bindings. I 
used --cc-cmd of git send-email to find the maintainers. I'll manually 
CC you to the other patches in V2.

Alex

> For this one:
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> 
> 
> 
> Best regards,
> Krzysztof
> 

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add LG G4 (h815)
From: Petr Vorel @ 2024-04-03 17:55 UTC (permalink / raw)
  To: Rob Herring
  Cc: Alexander Reimelt, konrad.dybcio, devicetree, andersson,
	krzysztof.kozlowski+dt, conor+dt, linux-arm-msm, robh+dt,
	linux-kernel, Petr Vorel
In-Reply-To: <171216461463.4018435.3466905061314737419.robh@kernel.org>

Hi all,

> On Wed, 03 Apr 2024 10:43:29 +0000, Alexander Reimelt wrote:
> > International variant of the LG G4 from 2015.

> > Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> > ---
> >  Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
> >  1 file changed, 1 insertion(+)


> Acked-by: Rob Herring <robh@kernel.org>

Reviewed-by: Petr Vorel <petr.vorel@gmail.com>

Kind regards,
Petr

^ permalink raw reply

* Re: [PATCH v3 22/25] dt-bindings: media: imx258: Add binding for powerdown-gpio
From: Krzysztof Kozlowski @ 2024-04-03 17:38 UTC (permalink / raw)
  To: git, linux-media
  Cc: dave.stevenson, jacopo.mondi, mchehab, robh,
	krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
	festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
	linux-kernel, pavel, phone-devel, Ondrej Jirman
In-Reply-To: <20240403150355.189229-23-git@luigi311.com>

On 03/04/2024 17:03, git@luigi311.com wrote:
> From: Luis Garcia <git@luigi311.com>
> 
> Add powerdown-gpio binding as it is required for some boards
> 
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> Signed-off-by: Luis Garcia <git@luigi311.com>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH 2/2] arm64: dts: qcom: Add basic support for LG G4 (H815)
From: Krzysztof Kozlowski @ 2024-04-03 17:37 UTC (permalink / raw)
  To: Alexander Reimelt, andersson, pvorel, konrad.dybcio, robh+dt,
	krzysztof.kozlowski+dt, conor+dt
  Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240403104415.30636-3-alexander.reimelt@posteo.de>

On 03/04/2024 12:43, Alexander Reimelt wrote:
> To make it easier for downstream projects and avoid duplication of work.
> Makes the device bootable and enables all buttons, most regulators, hall sensor, eMMC and SD-Card.
> 
> Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> ---
>  arch/arm64/boot/dts/qcom/Makefile            |   1 +
>  arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts | 422 +++++++++++++++++++
>  2 files changed, 423 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> 

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 7d40ec5e7d21..5b7f8741006f 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -62,6 +62,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= msm8956-sony-xperia-loire-kugo.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8956-sony-xperia-loire-suzu.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-lg-bullhead-rev-10.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-lg-bullhead-rev-101.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-lg-h815.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-msft-lumia-octagon-talkman.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8992-xiaomi-libra.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= msm8994-huawei-angler-rev-101.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts b/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> new file mode 100644
> index 000000000000..b7fa48337e25
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8992-lg-h815.dts
> @@ -0,0 +1,422 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/*
> + * MSM8992 LG G4 (h815) device tree.
> + *
> + * Copyright (c) 2024, Alexander Reimelt <alexander.reimelt@posteo.de>
> + */
> +
> +/dts-v1/;
> +
> +#include "msm8992.dtsi"
> +#include "pm8994.dtsi"
> +#include "pmi8994.dtsi"
> +#include <dt-bindings/leds/common.h>
> +
> +/* different mapping */
> +/delete-node/ &cont_splash_mem;
> +
> +/* disabled downstream */
> +/delete-node/ &dfps_data_mem;
> +
> +&CPU0 {
> +	enable-method = "spin-table";
> +};
> +
> +&CPU1 {
> +	enable-method = "spin-table";
> +};
> +
> +&CPU2 {
> +	enable-method = "spin-table";
> +};
> +
> +&CPU3 {
> +	enable-method = "spin-table";
> +};
> +
> +&CPU4 {
> +	enable-method = "spin-table";
> +};
> +
> +&CPU5 {
> +	enable-method = "spin-table";
> +};

That's wrong order. Top level nodes goes after node deletions. Please
observe DTS coding style.

> +
> +/ {
> +	model = "LG G4 (International)";
> +	compatible = "lg,h815", "qcom,msm8992";
> +	chassis-type = "handset";
> +
> +	qcom,msm-id = <251 0>;
> +	qcom,pmic-id = <0x10009 0x1000a 0x00 0x00>;
> +	qcom,board-id = <0xb64 0>;
> +
> +	/* psci is broken */
> +	/delete-node/ psci;
> +
> +	chosen {
> +		bootargs = "earlycon=tty0 console=tty0";

Drop

> +	};
> +
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		spin-table@6000000 {
> +			reg = <0 0x6000000 0 0x1000>;
> +			no-map;
> +		};
> +
> +		ramoops@ff00000 {
> +			compatible = "ramoops";
> +			reg = <0x0 0xff00000 0x0 0x100000>;
> +			console-size = <0x20000>;
> +			pmsg-size = <0x20000>;
> +			record-size = <0x10000>;
> +			ecc-size = <0x10>;
> +		};
> +
> +		cont_splash_mem: fb@3400000 {
> +			compatible = "framebuffer";
> +			reg = <0 0x3400000 0 0xc00000>;
> +			no-map;
> +		};
> +
> +		crash_fb_mem: crash_fb@4000000 {

No undercores in node names. Please open DTS coding style and follow it.

....

> +
> +&pm8994_resin {
> +	status = "okay";

status is the last property.



Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH] dt-bindings: omap-mcpdm: Convert to DT schema
From: Krzysztof Kozlowski @ 2024-04-03 17:33 UTC (permalink / raw)
  To: Mighty
  Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, alsa-devel, devicetree, linux-kernel
In-Reply-To: <20240403165950.75-1-bavishimithil@gmail.com>

On 03/04/2024 18:59, Mighty wrote:
> Convert the OMAP4+ McPDM bindings to DT schema.
> 

Please use subject prefixes matching the subsystem. You can get them for
example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
your patch is touching.

> Signed-off-by: Mighty <bavishimithil@gmail.com>

Is it your full name?


> ---
>  .../devicetree/bindings/sound/omap-mcpdm.txt  | 30 ----------
>  .../devicetree/bindings/sound/omap-mcpdm.yaml | 58 +++++++++++++++++++
>  2 files changed, 58 insertions(+), 30 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.txt
>  create mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.yaml
> 
> diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
> deleted file mode 100644
> index ff98a0cb5..000000000
> --- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
> +++ /dev/null
> @@ -1,30 +0,0 @@
> -* Texas Instruments OMAP4+ McPDM
> -

...

> diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml b/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml
> new file mode 100644
> index 000000000..8c9ff9d90
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml

Filename like compatible.

> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/omap-mcpdm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP McPDM
> +
> +maintainers:
> +  - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> +
> +description:
> +  OMAP ALSA SoC DAI driver using McPDM port used by TWL6040
> +
> +properties:
> +  compatible:
> +    const: ti,omap4-mcpdm
> +
> +  reg:
> +    description: 'Register location and size as an array:
> +       <MPU access base address, size>,
> +       <L3 interconnect address, size>;'

Please open existing bindings and look how it is done there.

> +
> +  interrupts:
> +    description: Interrupt number for McPDM

Same problem. Drop useless description but provide maxItems.

> +
> +  ti,hwmods:
> +    description: Name of the hwmod associated to the McPDM

It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.

Sorry, this was neither tested nor done in a way matching anything
already in the tree. Please do not invent your own style, but open
existing binding and look how is it done.

Because of above, I did not perform full review.

> +
> +  clocks:
> +    description: phandle for the pdmclk provider, likely <&twl6040>
> +
> +  clock-names:
> +    description: Must be "pdmclk"
> +
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - ti,hwmods
> +  - clocks
> +  - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    mcpdm: mcpdm@40132000 {

Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation



Best regards,
Krzysztof


^ permalink raw reply

* Re: [PATCH v14 01/18] irqchip/sifive-plic: Convert PLIC driver into a platform driver
From: Anup Patel @ 2024-04-03 17:19 UTC (permalink / raw)
  To: Lad, Prabhakar
  Cc: Anup Patel, Geert Uytterhoeven, Palmer Dabbelt, Paul Walmsley,
	Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Frank Rowand,
	Conor Dooley, Marc Zyngier, Björn Töpel, Atish Patra,
	Andrew Jones, Sunil V L, Saravana Kannan, linux-riscv,
	linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <CA+V-a8ser=hDmst6+XSeOWaEoOd+iY3Ys6bYBWDa5UYPfT+Pug@mail.gmail.com>

On Wed, Apr 3, 2024 at 9:19 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Wed, Apr 3, 2024 at 3:17 PM Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, Apr 3, 2024 at 2:01 PM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Thu, Feb 22, 2024 at 9:41 AM Anup Patel <apatel@ventanamicro.com> wrote:
> > > >
> > > > The PLIC driver does not require very early initialization so convert
> > > > it into a platform driver.
> > > >
> > > > After conversion, the PLIC driver is probed after CPUs are brought-up
> > > > so setup cpuhp state after context handler of all online CPUs are
> > > > initialized otherwise PLIC driver crashes for platforms with multiple
> > > > PLIC instances.
> > > >
> > > > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> > > > ---
> > > >  drivers/irqchip/irq-sifive-plic.c | 101 ++++++++++++++++++------------
> > > >  1 file changed, 61 insertions(+), 40 deletions(-)
> > > >
> > > This patch seems to have broken things on RZ/Five SoC, after reverting
> > > this patch I get to boot it back again on v6.9-rc2. Looks like there
> > > is some probe order issue after switching to platform driver?
> >
> > Yes, this is most likely related to probe ordering based on your DT.
> >
> > Can you share the failing boot log and DT ?
>
> non working case, https://paste.debian.net/1312947/
> after reverting, https://paste.debian.net/1312948/
> (attached is the DTB)

One potential problem is that
drivers/clocksource/renesas-ostm.c is probed early
using TIMER_OF_DECLARE() but the timer interrupt
is connected to PLIC which is probed late hence the
timer probe will fail.

We have two possible options:
1) Disable OSTM nodes
2) Improve the OSTM driver to probe like a
    regular platform device on RISC-V

Regards,
Anup

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add LG G4 (h815)
From: Rob Herring @ 2024-04-03 17:16 UTC (permalink / raw)
  To: Alexander Reimelt
  Cc: konrad.dybcio, devicetree, pvorel, andersson,
	krzysztof.kozlowski+dt, conor+dt, linux-arm-msm, robh+dt,
	linux-kernel
In-Reply-To: <20240403104415.30636-2-alexander.reimelt@posteo.de>


On Wed, 03 Apr 2024 10:43:29 +0000, Alexander Reimelt wrote:
> International variant of the LG G4 from 2015.
> 
> Signed-off-by: Alexander Reimelt <alexander.reimelt@posteo.de>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v6 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Rob Herring @ 2024-04-03 17:15 UTC (permalink / raw)
  To: Tan Chun Hau
  Cc: Andrew Halaney, Maxime Coquelin, Simon Horman, netdev,
	Ley Foon Tan, David S . Miller, Jakub Kicinski, linux-arm-kernel,
	Jisheng Zhang, Russell King, Emil Renner Berthing, Rob Herring,
	Bartosz Golaszewski, Jee Heng Sia, Paolo Abeni, linux-riscv,
	linux-stm32, Alexandre Torgue, Eric Dumazet, devicetree,
	Uwe Kleine-König, linux-kernel, Conor Dooley,
	Krzysztof Kozlowski
In-Reply-To: <20240403100549.78719-2-chunhau.tan@starfivetech.com>


On Wed, 03 Apr 2024 03:05:49 -0700, Tan Chun Hau wrote:
> Add StarFive JH8100 dwmac support.
> The JH8100 dwmac shares the same driver code as the JH7110 dwmac
> and has only one reset signal.
> 
> Please refer to below:
> 
>   JH8100: reset-names = "stmmaceth";
>   JH7110: reset-names = "stmmaceth", "ahb";
>   JH7100: reset-names = "ahb";
> 
> Example usage of JH8100 in the device tree:
> 
> gmac0: ethernet@16030000 {
>         compatible = "starfive,jh8100-dwmac",
>                      "starfive,jh7110-dwmac",
>                      "snps,dwmac-5.20";
>         ...
> };
> 
> Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> ---
>  .../bindings/net/starfive,jh7110-dwmac.yaml   | 28 +++++++++++++++----
>  1 file changed, 23 insertions(+), 5 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* [PATCH v2 2/2] mailbox: arm_mhuv3: Add driver
From: Cristian Marussi @ 2024-04-03 17:13 UTC (permalink / raw)
  To: linux-kernel, linux-arm-kernel, devicetree
  Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
	krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240403171346.3173843-1-cristian.marussi@arm.com>

Add support for ARM MHUv3 mailbox controller.

Support is limited to the MHUv3 Doorbell extension using only the PBX/MBX
combined interrupts.

Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v1 -> v2
- fixed checkpatch warnings about side-effects
- fixed sparse errors as reported
  | Reported-by: kernel test robot <lkp@intel.com>
  | Closes: https://lore.kernel.org/oe-kbuild-all/202403290015.tCLXudqC-lkp@intel.com/
---
 MAINTAINERS                 |    9 +
 drivers/mailbox/Kconfig     |   11 +
 drivers/mailbox/Makefile    |    2 +
 drivers/mailbox/arm_mhuv3.c | 1063 +++++++++++++++++++++++++++++++++++
 4 files changed, 1085 insertions(+)
 create mode 100644 drivers/mailbox/arm_mhuv3.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa3b947fb080..e957b9d9e32a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12998,6 +12998,15 @@ F:	Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
 F:	drivers/mailbox/arm_mhuv2.c
 F:	include/linux/mailbox/arm_mhuv2_message.h
 
+MAILBOX ARM MHUv3
+M:	Sudeep Holla <sudeep.holla@arm.com>
+M:	Cristian Marussi <cristian.marussi@arm.com>
+L:	linux-kernel@vger.kernel.org
+L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S:	Maintained
+F:	Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
+F:	drivers/mailbox/arm_mhuv3.c
+
 MAN-PAGES: MANUAL PAGES FOR LINUX -- Sections 2, 3, 4, 5, and 7
 M:	Alejandro Colomar <alx@kernel.org>
 L:	linux-man@vger.kernel.org
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 42940108a187..d20cdae65cfe 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -23,6 +23,17 @@ config ARM_MHU_V2
 	  Say Y here if you want to build the ARM MHUv2 controller driver,
 	  which provides unidirectional mailboxes between processing elements.
 
+config ARM_MHU_V3
+	tristate "ARM MHUv3 Mailbox"
+	depends on ARM64 || COMPILE_TEST
+	help
+	  Say Y here if you want to build the ARM MHUv3 controller driver,
+	  which provides unidirectional mailboxes between processing elements.
+
+	  ARM MHUv3 controllers can implement a varying number of extensions
+	  that provides different means of transports: supported extensions
+	  will be discovered and possibly managed at probe-time.
+
 config IMX_MBOX
 	tristate "i.MX Mailbox"
 	depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 18793e6caa2f..5cf2f54debaf 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -9,6 +9,8 @@ obj-$(CONFIG_ARM_MHU)	+= arm_mhu.o arm_mhu_db.o
 
 obj-$(CONFIG_ARM_MHU_V2)	+= arm_mhuv2.o
 
+obj-$(CONFIG_ARM_MHU_V3)	+= arm_mhuv3.o
+
 obj-$(CONFIG_IMX_MBOX)	+= imx-mailbox.o
 
 obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)	+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm_mhuv3.c b/drivers/mailbox/arm_mhuv3.c
new file mode 100644
index 000000000000..e4125568bec0
--- /dev/null
+++ b/drivers/mailbox/arm_mhuv3.c
@@ -0,0 +1,1063 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ARM Message Handling Unit Version 3 (MHUv3) driver.
+ *
+ * Copyright (C) 2024 ARM Ltd.
+ *
+ * Based on ARM MHUv2 driver.
+ */
+
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/mailbox_controller.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/types.h>
+
+/* ====== MHUv3 Registers ====== */
+
+/* Maximum number of Doorbell channel windows */
+#define MHUV3_DBCW_MAX			128
+/* Number of DBCH combined interrupt status registers */
+#define MHUV3_DBCH_CMB_INT_ST_REG_CNT	4
+#define MHUV3_INVALID_DOORBELL		0xFFFFFFFFUL
+
+/* Number of FFCH combined interrupt status registers */
+#define MHUV3_FFCH_CMB_INT_ST_REG_CNT	2
+
+#define MHUV3_STAT_BYTES		(sizeof(u32))
+#define MHUV3_STAT_BITS			(MHUV3_STAT_BYTES * __CHAR_BIT__)
+
+/* Not a typo ... */
+#define MHUV3_MAJOR_VERSION		2
+
+enum {
+	MHUV3_MBOX_CELL_TYPE,
+	MHUV3_MBOX_CELL_CHWN,
+	MHUV3_MBOX_CELL_PARAM,
+	MHUV3_MBOX_CELLS
+};
+
+/* CTRL_Page */
+
+struct blk_id {
+	u32 blk_id : 4;
+	u32 pad : 28;
+} __packed;
+
+struct feat_spt0 {
+	u32 dbe_spt : 4;
+	u32 fe_spt : 4;
+	u32 fce_spt : 4;
+	u32 tze_spt : 4;
+	u32 rme_spt : 4;
+	u32 rase_spt : 4;
+	u32 pad: 8;
+} __packed;
+
+struct feat_spt1 {
+	u32 auto_op_spt : 4;
+	u32 pad: 28;
+} __packed;
+
+struct dbch_cfg0 {
+	u32 num_dbch : 8;
+	u32 pad: 24;
+} __packed;
+
+struct ffch_cfg0 {
+	u32 num_ffch : 8;
+	u32 x8ba_spt : 1;
+	u32 x16ba_spt : 1;
+	u32 x32ba_spt : 1;
+	u32 x64ba_spt : 1;
+	u32 pad : 4;
+	u32 ffch_depth : 10;
+	u32 pad2 : 6;
+} __packed;
+
+struct fch_cfg0 {
+	u32 num_fch : 10;
+	/* MBX only registers */
+	u32 fcgi_spt : 1;
+	/* ------------------ */
+	u32 num_fcg : 5;
+	u32 num_fch_per_grp : 5;
+	u32 fch_ws : 8;
+	u32 pad : 3;
+} __packed;
+
+struct ctrl {
+	u32 op_req : 1;
+	u32 ch_op_mask : 1;
+	u32 pad : 30;
+} __packed;
+
+struct fch_ctrl {
+	u32 pad : 2;
+	u32 int_en : 1;
+	u32 pad2 : 29;
+} __packed;
+
+struct iidr {
+	u32 implementer : 12;
+	u32 revision : 4;
+	u32 variant : 4;
+	u32 product_id : 12;
+} __packed;
+
+struct aidr {
+	u32 arch_minor_rev : 4;
+	u32 arch_major_rev : 4;
+	u32 pad : 24;
+} __packed;
+
+struct ctrl_page {
+	struct blk_id blk_id;
+	u8 pad[0x10 - 0x4];
+	struct feat_spt0 feat_spt0;
+	struct feat_spt1 feat_spt1;
+	u8 pad1[0x20 - 0x18];
+	struct dbch_cfg0 dbch_cfg0;
+	u8 pad2[0x30 - 0x24];
+	struct ffch_cfg0 ffch_cfg0;
+	u8 pad3[0x40 - 0x34];
+	struct fch_cfg0 fch_cfg0;
+	u8 pad4[0x100 - 0x44];
+	struct ctrl ctrl;
+	/* MBX only registers */
+	u8 pad5[0x140 - 0x104];
+	struct fch_ctrl fch_ctrl;
+	u32 fcg_int_en;
+	u8 pad6[0x400 - 0x148];
+	/* ------------------ */
+	u32 dbch_int_st[MHUV3_DBCH_CMB_INT_ST_REG_CNT];
+	u32 ffch_int_st[MHUV3_FFCH_CMB_INT_ST_REG_CNT];
+	/* MBX only registers */
+	u8 pad7[0x470 - 0x418];
+	u32 fcg_int_st;
+	u8 pad8[0x480 - 0x474];
+	u32 fcg_grp_int_st[32];
+	u8 pad9[0xFC8 - 0x500];
+	/* ------------------ */
+	struct iidr iidr;
+	struct aidr aidr;
+	u32 imp_def_id[12];
+} __packed;
+
+/* DBCW_Page */
+
+struct xbcw_ctrl {
+	u32 comb_en : 1;
+	u32 pad : 31;
+} __packed;
+
+struct pdbcw_int {
+	u32 tfr_ack : 1;
+	u32 pad : 31;
+} __packed;
+
+struct pdbcw_page {
+	u32 st;
+	u8 pad[0xC - 0x4];
+	u32 set;
+	struct pdbcw_int int_st;
+	struct pdbcw_int int_clr;
+	struct pdbcw_int int_en;
+	struct xbcw_ctrl ctrl;
+} __packed;
+
+struct mdbcw_page {
+	u32 st;
+	u32 st_msk;
+	u32 clr;
+	u8 pad[0x10 - 0xC];
+	u32 msk_st;
+	u32 msk_set;
+	u32 msk_clr;
+	struct xbcw_ctrl ctrl;
+} __packed;
+
+struct dummy_page {
+	u8 pad[0x1000];
+} __packed;
+
+struct mhu3_pbx_frame_reg {
+	struct ctrl_page ctrl;
+	struct pdbcw_page dbcw[MHUV3_DBCW_MAX];
+	struct dummy_page ffcw;
+	struct dummy_page fcw;
+	u8 pad[0xF000 - 0x4000];
+	struct dummy_page impdef;
+} __packed;
+
+struct mhu3_mbx_frame_reg {
+	struct ctrl_page ctrl;
+	struct mdbcw_page dbcw[MHUV3_DBCW_MAX];
+	struct dummy_page ffcw;
+	struct dummy_page fcw;
+	u8 pad[0xF000 - 0x4000];
+	struct dummy_page impdef;
+} __packed;
+
+/* Macro for reading a bitfield within a physically mapped packed struct */
+#define readl_relaxed_bitfield(_regptr, _field)				\
+	({								\
+		u32 _rval;						\
+		typeof(_regptr) _rptr = _regptr;			\
+		_rval = readl_relaxed(_rptr);				\
+		((typeof(*_rptr) __force *)(&_rval))->_field;		\
+	})
+
+/* Macro for writing a bitfield within a physically mapped packed struct */
+#define writel_relaxed_bitfield(_value, _regptr, _field)		\
+	({								\
+		u32 _rval;						\
+		typeof(_regptr) _rptr = _regptr;			\
+		_rval = readl_relaxed(_rptr);				\
+		((typeof(*_rptr) __force *)(&_rval))->_field = _value;	\
+		writel_relaxed(_rval, _rptr);				\
+	})
+
+/* ====== MHUv3 data structures ====== */
+
+enum mhuv3_frame {
+	PBX_FRAME,
+	MBX_FRAME
+};
+
+static char *mhuv3_str[] = {
+	"PBX",
+	"MBX"
+};
+
+enum mhuv3_extension_type {
+	FIRST_EXT = 0,
+	DBE_EXT = FIRST_EXT,
+	FCE_EXT,
+	FE_EXT,
+	MAX_EXT
+};
+
+struct mhuv3;
+
+/**
+ * struct mhuv3_protocol_ops - MHUv3 operations
+ *
+ * @rx_startup: Receiver startup callback.
+ * @rx_shutdown: Receiver shutdown callback.
+ * @read_data: Read available Sender in-band LE data (if any).
+ * @rx_complete: Acknowledge data reception to the Sender. Any out-of-band data
+ *		 has to have been already retrieved before calling this.
+ * @tx_startup: Sender startup callback.
+ * @tx_shutdown: Sender shutdown callback.
+ * @last_tx_done: Report back to the Sender if the last transfer has completed.
+ * @send_data: Send data to the receiver.
+ *
+ * Each supported transport protocol provides its own implementation of
+ * these operations.
+ */
+struct mhuv3_protocol_ops {
+	int (*rx_startup)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	void (*rx_shutdown)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	void *(*read_data)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	void (*rx_complete)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	void (*tx_startup)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	void (*tx_shutdown)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	int (*last_tx_done)(struct mhuv3 *mhu, struct mbox_chan *chan);
+	int (*send_data)(struct mhuv3 *mhu, struct mbox_chan *chan, void *arg);
+};
+
+/**
+ * struct mhuv3_mbox_chan_priv - MHUv3 channel private information
+ *
+ * @ch_idx: Channel window index associated to this mailbox channel.
+ * @doorbell: Doorbell bit number within the @ch_idx window.
+ *	      Only relevant to Doorbell transport.
+ * @ops: Transport protocol specific operations for this channel.
+ *
+ * Transport specific data attached to mmailbox channel priv data.
+ */
+struct mhuv3_mbox_chan_priv {
+	u32 ch_idx;
+	u32 doorbell;
+	const struct mhuv3_protocol_ops *ops;
+};
+
+/**
+ * struct mhuv3_extension - MHUv3 extension descriptor
+ *
+ * @type: Type of extension
+ * @max_chans: Max number of channels found for this extension.
+ * @base_ch_idx: First channel number assigned to this extension, picked from
+ *		 the set of all mailbox channels descriptors created.
+ * @mbox_of_xlate: Extension specific helper to parse DT and lookup associated
+ *		   channel from the related 'mboxes' property.
+ * @combined_irq_setup: Extension specific helper to setup the combined irq.
+ * @channels_init: Extension specific helper to initialize channels.
+ * @chan_from_comb_irq_get: Extension specific helper to lookup which channel
+ *			    triggered the combined irq.
+ * @pending_db: Array of per-channel pending doorbells.
+ * @pending_lock: Protect access to pending_db.
+ */
+struct mhuv3_extension {
+	enum mhuv3_extension_type type;
+	unsigned int max_chans;
+	unsigned int base_ch_idx;
+	struct mbox_chan *(*mbox_of_xlate)(struct mhuv3 *mhu,
+					   unsigned int channel,
+					   unsigned int param);
+	void (*combined_irq_setup)(struct mhuv3 *mhu);
+	int (*channels_init)(struct mhuv3 *mhu);
+	struct mbox_chan *(*chan_from_comb_irq_get)(struct mhuv3 *mhu);
+	u32 pending_db[MHUV3_DBCW_MAX];
+	/* Protect access to pending_db */
+	spinlock_t pending_lock;
+};
+
+/**
+ * struct mhuv3 - MHUv3 mailbox controller data
+ *
+ * @frame:	Frame type: MBX_FRAME or PBX_FRAME.
+ * @auto_op_full: Flag to indicate if the MHU supports AutoOp full mode.
+ * @major: MHUv3 controller architectural major version.
+ * @minor: MHUv3 controller architectural minor version.
+ * @tot_chans: The total number of channnels discovered across all extensions.
+ * @cmb_irq: Combined IRQ number if any found defined.
+ * @ctrl: A reference to the MHUv3 control page for this block.
+ * @pbx: Base address of the PBX register mapping region.
+ * @mbx: Base address of the MBX register mapping region.
+ * @ext: Array holding descriptors for any found implemented extension.
+ * @mbox: Mailbox controller belonging to the MHU frame.
+ */
+struct mhuv3 {
+	enum mhuv3_frame frame;
+	bool auto_op_full;
+	unsigned int major;
+	unsigned int minor;
+	unsigned int tot_chans;
+	int cmb_irq;
+	struct ctrl_page __iomem *ctrl;
+	union {
+		struct mhu3_pbx_frame_reg __iomem *pbx;
+		struct mhu3_mbx_frame_reg __iomem *mbx;
+	};
+	struct mhuv3_extension *ext[MAX_EXT];
+	struct mbox_controller mbox;
+};
+
+#define mhu_from_mbox(_mbox) container_of(_mbox, struct mhuv3, mbox)
+
+typedef int (*mhuv3_extension_initializer)(struct mhuv3 *mhu);
+
+/* =================== Doorbell transport protocol operations =============== */
+
+static void mhuv3_doorbell_tx_startup(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	/* Enable Transfer Acknowledgment events */
+	writel_relaxed_bitfield(0x1, &mhu->pbx->dbcw[priv->ch_idx].int_en, tfr_ack);
+}
+
+static void mhuv3_doorbell_tx_shutdown(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+	unsigned long flags;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	/* Disable Channel Transfer Ack events */
+	writel_relaxed_bitfield(0x0, &mhu->pbx->dbcw[priv->ch_idx].int_en, tfr_ack);
+
+	/* Clear Channel Transfer Ack and pending doorbells */
+	writel_relaxed_bitfield(0x1, &mhu->pbx->dbcw[priv->ch_idx].int_clr, tfr_ack);
+	spin_lock_irqsave(&e->pending_lock, flags);
+	e->pending_db[priv->ch_idx] = 0;
+	spin_unlock_irqrestore(&e->pending_lock, flags);
+}
+
+static int mhuv3_doorbell_rx_startup(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	/* Unmask Channel Transfer events */
+	writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].msk_clr);
+
+	return 0;
+}
+
+static void mhuv3_doorbell_rx_shutdown(struct mhuv3 *mhu,
+				       struct mbox_chan *chan)
+{
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	/* Mask Channel Transfer events */
+	writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].msk_set);
+}
+
+static void mhuv3_doorbell_rx_complete(struct mhuv3 *mhu, struct mbox_chan *chan)
+{
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	/* Clearing the pending transfer generates the Channel Transfer Ack */
+	writel_relaxed(BIT(priv->doorbell), &mhu->mbx->dbcw[priv->ch_idx].clr);
+}
+
+static int mhuv3_doorbell_last_tx_done(struct mhuv3 *mhu,
+				       struct mbox_chan *chan)
+{
+	int done;
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	done = !(readl_relaxed(&mhu->pbx->dbcw[priv->ch_idx].st) &
+		 BIT(priv->doorbell));
+	if (done) {
+		unsigned long flags;
+		struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+		/* Take care to clear the pending doorbell also when polling */
+		spin_lock_irqsave(&e->pending_lock, flags);
+		e->pending_db[priv->ch_idx] &= ~BIT(priv->doorbell);
+		spin_unlock_irqrestore(&e->pending_lock, flags);
+	}
+
+	return done;
+}
+
+static int mhuv3_doorbell_send_data(struct mhuv3 *mhu, struct mbox_chan *chan,
+				    void *arg)
+{
+	int ret = 0;
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+	unsigned long flags;
+
+	spin_lock_irqsave(&e->pending_lock, flags);
+	/* Only one in-flight Transfer is allowed per-doorbell */
+	if (!(e->pending_db[priv->ch_idx] & BIT(priv->doorbell))) {
+		e->pending_db[priv->ch_idx] |= BIT(priv->doorbell);
+		writel_relaxed(BIT(priv->doorbell),
+			       &mhu->pbx->dbcw[priv->ch_idx].set);
+	} else {
+		ret = -EBUSY;
+	}
+	spin_unlock_irqrestore(&e->pending_lock, flags);
+
+	return ret;
+}
+
+static const struct mhuv3_protocol_ops mhuv3_doorbell_ops = {
+	.tx_startup = mhuv3_doorbell_tx_startup,
+	.tx_shutdown = mhuv3_doorbell_tx_shutdown,
+	.rx_startup = mhuv3_doorbell_rx_startup,
+	.rx_shutdown = mhuv3_doorbell_rx_shutdown,
+	.rx_complete = mhuv3_doorbell_rx_complete,
+	.last_tx_done = mhuv3_doorbell_last_tx_done,
+	.send_data = mhuv3_doorbell_send_data,
+};
+
+/* Sender and receiver mailbox ops */
+static bool mhuv3_sender_last_tx_done(struct mbox_chan *chan)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	return priv->ops->last_tx_done(mhu, chan);
+}
+
+static int mhuv3_sender_send_data(struct mbox_chan *chan, void *data)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	if (!priv->ops->last_tx_done(mhu, chan))
+		return -EBUSY;
+
+	return priv->ops->send_data(mhu, chan, data);
+}
+
+static int mhuv3_sender_startup(struct mbox_chan *chan)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	if (priv->ops->tx_startup)
+		priv->ops->tx_startup(mhu, chan);
+
+	return 0;
+}
+
+static void mhuv3_sender_shutdown(struct mbox_chan *chan)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	if (priv->ops->tx_shutdown)
+		priv->ops->tx_shutdown(mhu, chan);
+}
+
+static const struct mbox_chan_ops mhuv3_sender_ops = {
+	.send_data = mhuv3_sender_send_data,
+	.startup = mhuv3_sender_startup,
+	.shutdown = mhuv3_sender_shutdown,
+	.last_tx_done = mhuv3_sender_last_tx_done,
+};
+
+static int mhuv3_receiver_startup(struct mbox_chan *chan)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	return priv->ops->rx_startup(mhu, chan);
+}
+
+static void mhuv3_receiver_shutdown(struct mbox_chan *chan)
+{
+	struct mhuv3 *mhu = mhu_from_mbox(chan->mbox);
+	struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+	priv->ops->rx_shutdown(mhu, chan);
+}
+
+static int mhuv3_receiver_send_data(struct mbox_chan *chan, void *data)
+{
+	dev_err(chan->mbox->dev,
+		"Trying to transmit on a MBX MHUv3 frame\n");
+	return -EIO;
+}
+
+static bool mhuv3_receiver_last_tx_done(struct mbox_chan *chan)
+{
+	dev_err(chan->mbox->dev, "Trying to Tx poll on a MBX MHUv3 frame\n");
+	return true;
+}
+
+static const struct mbox_chan_ops mhuv3_receiver_ops = {
+	.send_data = mhuv3_receiver_send_data,
+	.startup = mhuv3_receiver_startup,
+	.shutdown = mhuv3_receiver_shutdown,
+	.last_tx_done = mhuv3_receiver_last_tx_done,
+};
+
+static struct mbox_chan *mhuv3_dbe_mbox_of_xlate(struct mhuv3 *mhu,
+						 unsigned int channel,
+						 unsigned int doorbell)
+{
+	struct mbox_controller *mbox = &mhu->mbox;
+	struct mbox_chan *chans = mbox->chans;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+	if (channel >= e->max_chans || doorbell >= MHUV3_STAT_BITS) {
+		dev_err(mbox->dev, "Couldn't xlate to a valid channel (%d: %d)\n",
+			channel, doorbell);
+		return ERR_PTR(-ENODEV);
+	}
+
+	return &chans[e->base_ch_idx + channel * MHUV3_STAT_BITS + doorbell];
+}
+
+static void mhuv3_dbe_combined_irq_setup(struct mhuv3 *mhu)
+{
+	int i;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+
+	if (mhu->frame == PBX_FRAME) {
+		struct pdbcw_page __iomem *dbcw = mhu->pbx->dbcw;
+
+		for (i = 0; i < e->max_chans; i++) {
+			writel_relaxed_bitfield(0x1, &dbcw[i].int_clr, tfr_ack);
+			writel_relaxed_bitfield(0x0, &dbcw[i].int_en, tfr_ack);
+			writel_relaxed_bitfield(0x1, &dbcw[i].ctrl, comb_en);
+		}
+	} else {
+		struct mdbcw_page __iomem *dbcw = mhu->mbx->dbcw;
+
+		for (i = 0; i < e->max_chans; i++) {
+			writel_relaxed(0xFFFFFFFF, &dbcw[i].clr);
+			writel_relaxed(0xFFFFFFFF, &dbcw[i].msk_set);
+			writel_relaxed_bitfield(0x1, &dbcw[i].ctrl, comb_en);
+		}
+	}
+}
+
+static int mhuv3_dbe_channels_init(struct mhuv3 *mhu)
+{
+	int i;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+	struct mbox_controller *mbox = &mhu->mbox;
+	struct mbox_chan *chans;
+
+	chans = mbox->chans + mbox->num_chans;
+	e->base_ch_idx = mbox->num_chans;
+	for (i = 0; i < e->max_chans; i++) {
+		int k;
+		struct mhuv3_mbox_chan_priv *priv;
+
+		for (k = 0; k < MHUV3_STAT_BITS; k++) {
+			priv = devm_kmalloc(mbox->dev, sizeof(*priv), GFP_KERNEL);
+			if (!priv)
+				return -ENOMEM;
+
+			priv->ch_idx = i;
+			priv->ops = &mhuv3_doorbell_ops;
+			priv->doorbell = k;
+			chans++->con_priv = priv;
+			mbox->num_chans++;
+		}
+	}
+
+	spin_lock_init(&e->pending_lock);
+
+	return 0;
+}
+
+static struct mbox_chan *mhuv3_dbe_chan_from_comb_irq_get(struct mhuv3 *mhu)
+{
+	int i;
+	struct mhuv3_extension *e = mhu->ext[DBE_EXT];
+	struct device *dev = mhu->mbox.dev;
+
+	for (i = 0; i < MHUV3_DBCH_CMB_INT_ST_REG_CNT; i++) {
+		unsigned int channel, db = MHUV3_INVALID_DOORBELL;
+		u32 cmb_st, st;
+
+		cmb_st = readl_relaxed(&mhu->ctrl->dbch_int_st[i]);
+		if (!cmb_st)
+			continue;
+
+		channel = i * MHUV3_STAT_BITS + __builtin_ctz(cmb_st);
+		if (channel >= e->max_chans) {
+			dev_err(dev, "Invalid %s channel:%d\n",
+				mhuv3_str[mhu->frame], channel);
+			break;
+		}
+
+		if (mhu->frame == PBX_FRAME) {
+			unsigned long flags;
+			u32 active_dbs, fired_dbs;
+
+			st = readl_relaxed_bitfield(&mhu->pbx->dbcw[channel].int_st,
+						    tfr_ack);
+			if (!st) {
+				dev_warn(dev, "Spurios IRQ on %s channel:%d\n",
+					 mhuv3_str[mhu->frame], channel);
+				continue;
+			}
+
+			active_dbs = readl_relaxed(&mhu->pbx->dbcw[channel].st);
+			spin_lock_irqsave(&e->pending_lock, flags);
+			fired_dbs = e->pending_db[channel] & ~active_dbs;
+			if (fired_dbs) {
+				db = __builtin_ctz(fired_dbs);
+				e->pending_db[channel] &= ~BIT(db);
+				fired_dbs &= ~BIT(db);
+			}
+			spin_unlock_irqrestore(&e->pending_lock, flags);
+
+			/* Clear TFR Ack if no more doorbells pending */
+			if (!fired_dbs)
+				writel_relaxed_bitfield(0x1,
+							&mhu->pbx->dbcw[channel].int_clr,
+							tfr_ack);
+		} else {
+			st = readl_relaxed(&mhu->mbx->dbcw[channel].st_msk);
+			if (!st) {
+				dev_warn(dev, "Spurios IRQ on %s channel:%d\n",
+					 mhuv3_str[mhu->frame], channel);
+				continue;
+			}
+			db = __builtin_ctz(st);
+		}
+
+		if (db != MHUV3_INVALID_DOORBELL) {
+			dev_dbg(dev, "Found %s ch[%d]/db[%d]\n",
+				mhuv3_str[mhu->frame], channel, db);
+
+			return &mhu->mbox.chans[channel * MHUV3_STAT_BITS + db];
+		}
+	}
+
+	return ERR_PTR(-EIO);
+}
+
+static int mhuv3_dbe_init(struct mhuv3 *mhu)
+{
+	struct mhuv3_extension *e;
+	struct device *dev = mhu->mbox.dev;
+
+	if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, dbe_spt))
+		return 0;
+
+	dev_dbg(dev, "%s: Initializing DBE Extension.\n", mhuv3_str[mhu->frame]);
+
+	e = devm_kzalloc(dev, sizeof(*e), GFP_KERNEL);
+	if (!e)
+		return -ENOMEM;
+
+	e->type = DBE_EXT;
+	/* Note that, by the spec, the number of channels is (num_dbch + 1) */
+	e->max_chans =
+		readl_relaxed_bitfield(&mhu->ctrl->dbch_cfg0, num_dbch) + 1;
+	e->mbox_of_xlate = mhuv3_dbe_mbox_of_xlate;
+	e->combined_irq_setup = mhuv3_dbe_combined_irq_setup;
+	e->channels_init = mhuv3_dbe_channels_init;
+	e->chan_from_comb_irq_get = mhuv3_dbe_chan_from_comb_irq_get;
+
+	mhu->tot_chans += e->max_chans * MHUV3_STAT_BITS;
+	mhu->ext[DBE_EXT] = e;
+
+	dev_info(dev, "%s: found %d DBE channels.\n",
+		 mhuv3_str[mhu->frame], e->max_chans);
+
+	return 0;
+}
+
+static int mhuv3_fce_init(struct mhuv3 *mhu)
+{
+	struct device *dev = mhu->mbox.dev;
+
+	if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, fce_spt))
+		return 0;
+
+	dev_dbg(dev, "%s: FCE Extension not supported by driver.\n",
+		mhuv3_str[mhu->frame]);
+
+	return 0;
+}
+
+static int mhuv3_fe_init(struct mhuv3 *mhu)
+{
+	struct device *dev = mhu->mbox.dev;
+
+	if (!readl_relaxed_bitfield(&mhu->ctrl->feat_spt0, fe_spt))
+		return 0;
+
+	dev_dbg(dev, "%s: FE Extension not supported by driver.\n",
+		mhuv3_str[mhu->frame]);
+
+	return 0;
+}
+
+static mhuv3_extension_initializer mhuv3_extension_init[MAX_EXT] = {
+	mhuv3_dbe_init,
+	mhuv3_fce_init,
+	mhuv3_fe_init,
+};
+
+static int mhuv3_initialize_channels(struct device *dev, struct mhuv3 *mhu)
+{
+	int i, ret = 0;
+	struct mbox_controller *mbox = &mhu->mbox;
+
+	mbox->chans = devm_kcalloc(dev, mhu->tot_chans,
+				   sizeof(*mbox->chans), GFP_KERNEL);
+	if (!mbox->chans)
+		return -ENOMEM;
+
+	for (i = FIRST_EXT; i < MAX_EXT && !ret; i++)
+		if (mhu->ext[i])
+			ret = mhu->ext[i]->channels_init(mhu);
+
+	return ret;
+}
+
+static struct mbox_chan *mhuv3_mbox_of_xlate(struct mbox_controller *mbox,
+					     const struct of_phandle_args *pa)
+{
+	unsigned int type, channel, param;
+	struct mhuv3 *mhu = mhu_from_mbox(mbox);
+
+	if (pa->args_count != MHUV3_MBOX_CELLS)
+		return ERR_PTR(-EINVAL);
+
+	type = pa->args[MHUV3_MBOX_CELL_TYPE];
+	if (type >= MAX_EXT)
+		return ERR_PTR(-EINVAL);
+
+	channel = pa->args[MHUV3_MBOX_CELL_CHWN];
+	param = pa->args[MHUV3_MBOX_CELL_PARAM];
+
+	return mhu->ext[type]->mbox_of_xlate(mhu, channel, param);
+}
+
+static int mhuv3_frame_init(struct mhuv3 *mhu, void __iomem *regs)
+{
+	int i, ret = 0;
+	struct device *dev = mhu->mbox.dev;
+
+	mhu->ctrl = regs;
+	mhu->frame = readl_relaxed_bitfield(&mhu->ctrl->blk_id, blk_id);
+	if (mhu->frame > MBX_FRAME) {
+		dev_err(dev, "Invalid Frame type- %d\n", mhu->frame);
+		return -EINVAL;
+	}
+
+	mhu->major = readl_relaxed_bitfield(&mhu->ctrl->aidr, arch_major_rev);
+	mhu->minor = readl_relaxed_bitfield(&mhu->ctrl->aidr, arch_minor_rev);
+	if (mhu->major != MHUV3_MAJOR_VERSION) {
+		dev_warn(dev, "Unsupported MHU %s block - major:%d  minor:%d\n",
+			 mhuv3_str[mhu->frame], mhu->major, mhu->minor);
+		return -EINVAL;
+	}
+	mhu->auto_op_full = !!readl_relaxed_bitfield(&mhu->ctrl->feat_spt1,
+						     auto_op_spt);
+	/* Request the PBX/MBX to remain operational */
+	if (mhu->auto_op_full)
+		writel_relaxed_bitfield(0x1, &mhu->ctrl->ctrl, op_req);
+
+	dev_dbg(dev, "Found MHU %s block - major:%d  minor:%d\n",
+		mhuv3_str[mhu->frame], mhu->major, mhu->minor);
+
+	if (mhu->frame == PBX_FRAME)
+		mhu->pbx = regs;
+	else
+		mhu->mbx = regs;
+
+	for (i = FIRST_EXT; i < MAX_EXT && !ret; i++)
+		ret = mhuv3_extension_init[i](mhu);
+
+	return ret;
+}
+
+static irqreturn_t mhuv3_pbx_comb_interrupt(int irq, void *arg)
+{
+	int ret = IRQ_NONE;
+	unsigned int i, found = 0;
+	struct mhuv3 *mhu = arg;
+	struct device *dev = mhu->mbox.dev;
+	struct mbox_chan *chan;
+
+	for (i = FIRST_EXT; i < MAX_EXT; i++) {
+		/* FCE does not participate to the PBX combined */
+		if (i == FCE_EXT || !mhu->ext[i])
+			continue;
+
+		chan = mhu->ext[i]->chan_from_comb_irq_get(mhu);
+		if (!IS_ERR(chan)) {
+			struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+			found++;
+			if (chan->cl) {
+				mbox_chan_txdone(chan, 0);
+				ret = IRQ_HANDLED;
+			} else {
+				dev_warn(dev,
+					 "TX Ack on UNBOUND channel (%u)\n",
+					 priv->ch_idx);
+			}
+		}
+	}
+
+	if (!found)
+		dev_warn_once(dev, "Failed to find channel for the TX interrupt\n");
+
+	return ret;
+}
+
+static irqreturn_t mhuv3_mbx_comb_interrupt(int irq, void *arg)
+{
+	int ret = IRQ_NONE;
+	unsigned int i, found = 0;
+	struct mhuv3 *mhu = arg;
+	struct device *dev = mhu->mbox.dev;
+	struct mbox_chan *chan;
+
+	for (i = FIRST_EXT; i < MAX_EXT; i++) {
+		if (!mhu->ext[i])
+			continue;
+
+		/* Process any extension which could be source of the IRQ */
+		chan = mhu->ext[i]->chan_from_comb_irq_get(mhu);
+		if (!IS_ERR(chan)) {
+			void *data = NULL;
+			struct mhuv3_mbox_chan_priv *priv = chan->con_priv;
+
+			found++;
+			/* Read and acknowledge optional in-band LE data first. */
+			if (priv->ops->read_data)
+				data = priv->ops->read_data(mhu, chan);
+
+			if (chan->cl && !IS_ERR(data)) {
+				mbox_chan_received_data(chan, data);
+				ret = IRQ_HANDLED;
+			} else if (!chan->cl) {
+				dev_warn(dev,
+					 "RX Data on UNBOUND channel (%u)\n",
+					 priv->ch_idx);
+			} else {
+				dev_err(dev, "Failed to read data: %lu\n",
+					PTR_ERR(data));
+			}
+
+			if (!IS_ERR(data))
+				kfree(data);
+
+			/*
+			 * Acknowledge transfer after any possible optional
+			 * out-of-band data has also been retrieved via
+			 * mbox_chan_received_data().
+			 */
+			if (priv->ops->rx_complete)
+				priv->ops->rx_complete(mhu, chan);
+		}
+	}
+
+	if (!found)
+		dev_warn_once(dev, "Failed to find channel for the RX interrupt\n");
+
+	return ret;
+}
+
+static int mhuv3_setup_pbx(struct mhuv3 *mhu)
+{
+	struct device *dev = mhu->mbox.dev;
+
+	mhu->mbox.ops = &mhuv3_sender_ops;
+
+	if (mhu->cmb_irq > 0) {
+		int ret;
+
+		ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
+						mhuv3_pbx_comb_interrupt,
+						IRQF_ONESHOT, "mhuv3-pbx", mhu);
+		if (!ret) {
+			int i;
+
+			mhu->mbox.txdone_irq = true;
+			mhu->mbox.txdone_poll = false;
+
+			for (i = FIRST_EXT; i < MAX_EXT; i++)
+				if (mhu->ext[i])
+					mhu->ext[i]->combined_irq_setup(mhu);
+
+			dev_dbg(dev, "MHUv3 PBX IRQs initialized.\n");
+
+			return 0;
+		}
+
+		dev_err(dev, "Failed to request PBX IRQ - ret:%d", ret);
+	}
+
+	dev_info(dev, "Using PBX in Tx polling mode.\n");
+	mhu->mbox.txdone_irq = false;
+	mhu->mbox.txdone_poll = true;
+	mhu->mbox.txpoll_period = 1;
+
+	return 0;
+}
+
+static int mhuv3_setup_mbx(struct mhuv3 *mhu)
+{
+	int ret, i;
+	struct device *dev = mhu->mbox.dev;
+
+	mhu->mbox.ops = &mhuv3_receiver_ops;
+
+	if (mhu->cmb_irq <= 0) {
+		dev_err(dev, "Missing MBX combined IRQ !\n");
+		return -EINVAL;
+	}
+
+	ret = devm_request_threaded_irq(dev, mhu->cmb_irq, NULL,
+					mhuv3_mbx_comb_interrupt, IRQF_ONESHOT,
+					"mhuv3-mbx", mhu);
+	if (ret) {
+		dev_err(dev, "Failed to request MBX IRQ - ret:%d\n", ret);
+		return ret;
+	}
+
+	for (i = FIRST_EXT; i < MAX_EXT; i++)
+		if (mhu->ext[i])
+			mhu->ext[i]->combined_irq_setup(mhu);
+
+	dev_dbg(dev, "MHUv3 MBX IRQs initialized.\n");
+
+	return ret;
+}
+
+static int mhuv3_irqs_init(struct mhuv3 *mhu, struct platform_device *pdev)
+{
+	int ret;
+
+	dev_dbg(mhu->mbox.dev, "Initializing %s block.\n", mhuv3_str[mhu->frame]);
+
+	if (mhu->frame == PBX_FRAME) {
+		mhu->cmb_irq = platform_get_irq_byname_optional(pdev, "combined");
+		ret = mhuv3_setup_pbx(mhu);
+	} else {
+		mhu->cmb_irq = platform_get_irq_byname(pdev, "combined");
+		ret = mhuv3_setup_mbx(mhu);
+	}
+
+	return ret;
+}
+
+static int mhuv3_probe(struct platform_device *pdev)
+{
+	int ret;
+	struct mhuv3 *mhu;
+	void __iomem *regs;
+	struct device *dev = &pdev->dev;
+
+	mhu = devm_kzalloc(dev, sizeof(*mhu), GFP_KERNEL);
+	if (!mhu)
+		return -ENOMEM;
+
+	regs = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(regs))
+		return PTR_ERR(regs);
+
+	mhu->mbox.dev = dev;
+	ret = mhuv3_frame_init(mhu, regs);
+	if (ret)
+		return ret;
+
+	ret = mhuv3_irqs_init(mhu, pdev);
+	if (ret)
+		return ret;
+
+	mhu->mbox.of_xlate = mhuv3_mbox_of_xlate;
+	ret = mhuv3_initialize_channels(dev, mhu);
+	if (ret)
+		return ret;
+
+	ret = devm_mbox_controller_register(dev, &mhu->mbox);
+	if (ret)
+		dev_err(dev, "failed to register ARM MHUv3 driver %d\n", ret);
+
+	platform_set_drvdata(pdev, mhu);
+
+	return ret;
+}
+
+static int mhuv3_remove(struct platform_device *pdev)
+{
+	struct mhuv3 *mhu = platform_get_drvdata(pdev);
+
+	if (mhu->auto_op_full)
+		writel_relaxed_bitfield(0x0, &mhu->ctrl->ctrl, op_req);
+
+	return 0;
+}
+
+static const struct of_device_id mhuv3_of_match[] = {
+	{ .compatible = "arm,mhuv3", .data = NULL },
+	{}
+};
+MODULE_DEVICE_TABLE(of, mhuv3_of_match);
+
+static struct platform_driver mhuv3_driver = {
+	.driver = {
+		.name = "arm-mhuv3-mailbox",
+		.of_match_table = mhuv3_of_match,
+	},
+	.probe = mhuv3_probe,
+	.remove = mhuv3_remove,
+};
+module_platform_driver(mhuv3_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ARM MHUv3 Driver");
+MODULE_AUTHOR("Cristian Marussi <cristian.marussi@arm.com>");
-- 
2.34.1


^ permalink raw reply related

* [PATCH v2 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Cristian Marussi @ 2024-04-03 17:13 UTC (permalink / raw)
  To: linux-kernel, linux-arm-kernel, devicetree
  Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
	krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240403171346.3173843-1-cristian.marussi@arm.com>

Add bindings for the ARM MHUv3 Mailbox controller.

Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
---
v1 -> v2
- clarified extension descriptions around configurability and discoverability
- removed unused labels from the example
- using pattern properties to define interrupt-names
- bumped interrupt maxItems to 74 (allowing uo to 8 channels per extension)
---
 .../bindings/mailbox/arm,mhuv3.yaml           | 217 ++++++++++++++++++
 1 file changed, 217 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml

diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
new file mode 100644
index 000000000000..d781045521da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm,mhuv3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM MHUv3 Mailbox Controller
+
+maintainers:
+  - Sudeep Holla <sudeep.holla@arm.com>
+  - Cristian Marussi <cristian.marussi@arm.com>
+
+description: |
+  The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that
+  enables unidirectional communications with remote processors through various
+  possible transport protocols.
+  The controller can optionally support a varying number of extensions that, in
+  turn, enable different kinds of transport to be used for communication.
+  Number, type and characteristics of each supported extension can be discovered
+  dynamically at runtime.
+
+  Given the unidirectional nature of the controller, an MHUv3 mailbox controller
+  is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU
+  Receiver (MHUR) containing a MailBox (MBX) block, where
+
+   PBX is used to
+      - Configure the MHU
+      - Send Transfers to the Receiver
+      - Optionally receive acknowledgment of a Transfer from the Receiver
+
+   MBX is used to
+      - Configure the MHU
+      - Receive Transfers from the Sender
+      - Optionally acknowledge Transfers sent by the Sender
+
+  Both PBX and MBX need to be present and defined in the DT description if you
+  need to establish a bidirectional communication, since you will have to
+  acquire two distinct unidirectional channels, one for each block.
+
+  As a consequence both blocks needs to be represented separately and specified
+  as distinct DT nodes in order to properly describe their resources.
+
+  Note that, though, thanks to the runtime discoverability, there is no need to
+  identify the type of blocks with distinct compatibles.
+
+  Following are the MHUv3 possible extensions.
+
+  - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell
+    Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
+    Sender to Receiver. The Transfer indicates that an event has occurred.
+    When DBE is implemented, the number of DBCHs that an implementation of the
+    MHU can support is between 1 and 128, numbered starting from 0 in ascending
+    order and discoverable at run-time.
+    Each DBCH contains 32 individual fields, referred to as flags, each of which
+    can be used independently. It is possible for the Sender to send multiple
+    Transfers at once using a single DBCH, so long as each Transfer uses
+    a different flag in the DBCH.
+    Optionally, data may be transmitted through an out-of-band shared memory
+    region, wherein the MHU Doorbell is used strictly as an interrupt generation
+    mechanism, but this is out of the scope of these bindings.
+
+  - FastChannel Extension (FCE): FCE defines a type of channel called a Fast
+    Channel (FCH). FCH is intended for lower overhead communication between
+    Sender and Receiver at the expense of determinism. An FCH allows the Sender
+    to update the channel value at any time, regardless of whether the previous
+    value has been seen by the Receiver. When the Receiver reads the channel's
+    content it gets the last value written to the channel.
+    FCH is considered lossy in nature, and means that the Sender has no way of
+    knowing if, or when, the Receiver will act on the Transfer.
+    FCHs are expected to behave as RAM which generates interrupts when writes
+    occur to the locations within the RAM.
+    When FCE is implemented, the number of FCHs that an implementation of the
+    MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,
+    or between 1-512, when the FastChannel word-size is 64-bits.
+    FCHs are numbered from 0 in ascending order.
+    Note that the number of FCHs and the word-size are implementation defined,
+    not configurable but discoverable at run-time.
+    Optionally, data may be transmitted through an out-of-band shared memory
+    region, wherein the MHU FastChannel is used as an interrupt generation
+    mechanism which carries also a pointer to such out-of-band data, but this
+    is out of the scope of these bindings.
+
+  - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).
+    FFCH allows a Sender to send
+       - Multiple Transfers to the Receiver without having to wait for the
+	 previous Transfer to be acknowledged by the Receiver, as long as the
+	 FIFO has room for the Transfer.
+       - Transfers which require the Receiver to provide acknowledgment.
+       - Transfers which have in-band payload.
+    In all cases, the data is guaranteed to be observed by the Receiver in the
+    same order which the Sender sent it.
+    When FE is implemented, the number of FFCHs that an implementation of the
+    MHU can support is between 1 and 64, numbered starting from 0 in ascending
+    order. The number of FFCHs, their depth (same for all implemented FFCHs) and
+    the access-granularity are implementation defined, not configurable but
+    discoverable at run-time.
+    Optionally, additional data may be transmitted through an out-of-band shared
+    memory region, wherein the MHU FIFO is used to transmit, in order, a small
+    part of the payload (like a header) and a reference to the shared memory
+    area holding the remaining, bigger, chunk of the payload, but this is out of
+    the scope of these bindings.
+
+properties:
+  compatible:
+    const: arm,mhuv3
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    minItems: 1
+    maxItems: 74
+
+  interrupt-names:
+    description: |
+      The MHUv3 controller generates a number of events some of which are used
+      to generate interrupts; as a consequence it can expose a varying number of
+      optional PBX/MBX interrupts, representing the events generated during the
+      operation of the various transport protocols associated with different
+      extensions. All interrupts of the MHU are level-sensitive.
+      Some of these optional interrupts are defined per-channel, where the
+      number of channels effectively available is implementation defined and
+      run-time discoverable.
+      In the following names are enumerated using patterns, with per-channel
+      interrupts implicitly capped at the maximum channels allowed by the
+      specification for each extension type.
+      For the sake of simplicity maxItems is anyway capped to a most plausible
+      number, assuming way less channels would be implemented than actually
+      possible.
+
+      The only mandatory interrupts on the MHU are:
+        - combined
+        - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.
+
+    minItems: 1
+    maxItems: 74
+    items:
+      oneOf:
+        - const: combined
+          description: PBX/MBX Combined interrupt
+        - const: combined-ffch
+          description: PBX/MBX FIFO Combined interrupt
+        - pattern: '^ffch-low-tide-[0-9]+$'
+          description: PBX/MBX FIFO Channel <N> Low Tide interrupt
+        - pattern: '^ffch-high-tide-[0-9]+$'
+          description: PBX/MBX FIFO Channel <N> High Tide interrupt
+        - pattern: '^ffch-flush-[0-9]+$'
+          description: PBX/MBX FIFO Channel <N> Flush interrupt
+        - pattern: '^mbx-dbch-xfer-[0-9]+$'
+          description: MBX Doorbell Channel <N> Transfer interrupt
+        - pattern: '^mbx-fch-xfer-[0-9]+$'
+          description: MBX FastChannel <N> Transfer interrupt
+        - pattern: '^mbx-fchgrp-xfer-[0-9]+$'
+          description: MBX FastChannel <N> Group Transfer interrupt
+        - pattern: '^mbx-ffch-xfer-[0-9]+$'
+          description: MBX FIFO Channel <N> Transfer interrupt
+        - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'
+          description: PBX Doorbell Channel <N> Transfer Ack interrupt
+        - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'
+          description: PBX FIFO Channel <N> Transfer Ack interrupt
+
+  '#mbox-cells':
+    description: |
+      The first argument in the consumers 'mboxes' property represents the
+      extension type, the second is for the channel number while the third
+      depends on extension type.
+
+      Extension type for DBE is 0 and the third parameter represents the
+      doorbell flag number to use.
+      Extension type for FCE is 1, third parameter unused.
+      Extension type for FE is 2, third parameter unused.
+
+      mboxes = <&mhu 0 0 5>; // DBE, Doorbell Channel Window 0, doorbell flag 5.
+      mboxes = <&mhu 0 1 7>; // DBE, Doorbell Channel Window 1, doorbell flag 7.
+      mboxes = <&mhu 1 0 0>; // FCE, FastChannel Window 0.
+      mboxes = <&mhu 1 3 0>; // FCE, FastChannel Window 3.
+      mboxes = <&mhu 2 1 0>; // FE, FIFO Channel Window 1.
+      mboxes = <&mhu 2 7 0>; // FE, FIFO Channel Window 7.
+    const: 3
+
+  clocks:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - interrupt-names
+  - '#mbox-cells'
+
+additionalProperties: false
+
+examples:
+  - |
+    soc {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        mailbox@2aaa0000 {
+            compatible = "arm,mhuv3";
+            #mbox-cells = <3>;
+            reg = <0 0x2aaa0000 0 0x10000>;
+            clocks = <&clock 0>;
+            interrupt-names = "combined", "pbx-dbch-xfer-ack-1",
+                               "ffch-high-tide-0";
+            interrupts = <0 36 4>, <0 37 4>;
+        };
+
+        mailbox@2ab00000 {
+            compatible = "arm,mhuv3";
+            #mbox-cells = <3>;
+            reg = <0 0x2aab0000 0 0x10000>;
+            clocks = <&clock 0>;
+            interrupt-names = "combined", "mbx-dbch-xfer-1", "ffch-low-tide-0";
+            interrupts = <0 35 4>, <0 38 4>, <0 39 4>;
+        };
+    };
-- 
2.34.1


^ permalink raw reply related

* [PATCH v2 0/2] Add initial ARM MHUv3 mailbox support
From: Cristian Marussi @ 2024-04-03 17:13 UTC (permalink / raw)
  To: linux-kernel, linux-arm-kernel, devicetree
  Cc: sudeep.holla, cristian.marussi, jassisinghbrar, robh+dt,
	krzysztof.kozlowski+dt, conor+dt

Hi,

This series adds support for the new ARM Message Handling Unit v3 mailbox
controller [1].

The ARM MHUv3 can optionally support various extensions, enabling the
usage of different transport protocols.

Patch [2/2] adds a platform driver which, as of now, provides support only
for the Doorbell extension using the combined interrupt.

On the other side, bindings in [1/2] are introduced for all the extensions
described by the specification, as long as they are of interest to an
entity running from Normal world, like Linux: as such, Doorbell, FIFO and
FastChannel extensions are documented.

In these regards, note that the ARM MHUv3 controller can optionally
implement a considerable number of interrupts to express a great deal of
events and many of such interrupts are defined as being per-channel: with
the total maximum amount of possibly implemented channels across all
extensions being 1216 (1024+128+64), it would mean *a lot* of
interrupt-names to enumerate in the bindings.

For the sake of simplicity the binding as of now only introduces interrupt
names for a mere 8-channels in the range (0,7) for each per-channel
interrupt type: the idea is to leave open the possibility to add more to
this list of numbered items only when (and if) new real HW appears that
effectively needs more than 8 channels. (like AMBA, where the maximum
number of IRQ was progressively increased when needed, AFAIU).

Based on v6.9-rc1, tested on ARM TCS23 [2]
(TCS23 reference SW stack is still to be made fully publicly available)

Thanks,
Cristian

[1]: https://developer.arm.com/documentation/aes0072/aa/?lang=en
[2]: https://community.arm.com/arm-community-blogs/b/tools-software-ides-blog/posts/total-compute-solutions-platform-software-stack-and-fvp


---
v1 -> v2
 - clarified DT bindings extension descriptions around configurability
   and discoverability
 - removed unused labels from the DT example
 - using pattern properties to define DT interrupt-names
 - bumped DT interrupt maxItems to 74 (allowing uo to 8 channels per extension)
 - fixed checkpatch warnings about side-effects on write/read bitfield macros
 - fixed sparse errors as reported
   | Reported-by: kernel test robot <lkp@intel.com>
   | Closes: https://lore.kernel.org/oe-kbuild-all/202403290015.tCLXudqC-lkp@intel.com/

Cristian Marussi (2):
  dt-bindings: mailbox: arm,mhuv3: Add bindings
  mailbox: arm_mhuv3: Add driver

 .../bindings/mailbox/arm,mhuv3.yaml           |  217 ++++
 MAINTAINERS                                   |    9 +
 drivers/mailbox/Kconfig                       |   11 +
 drivers/mailbox/Makefile                      |    2 +
 drivers/mailbox/arm_mhuv3.c                   | 1063 +++++++++++++++++
 5 files changed, 1302 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
 create mode 100644 drivers/mailbox/arm_mhuv3.c

-- 
2.34.1


^ permalink raw reply

* Re: [PATCH v2] dt-bindings: watchdog: aspeed,ast2400-wdt: Convert to DT schema
From: Rob Herring @ 2024-04-03 17:13 UTC (permalink / raw)
  To: Andrew Jeffery
  Cc: wim, linux, krzysztof.kozlowski+dt, conor+dt, joel, zev,
	linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
	linux-kernel
In-Reply-To: <20240403020439.418788-1-andrew@codeconstruct.com.au>

On Wed, Apr 03, 2024 at 12:34:39PM +1030, Andrew Jeffery wrote:
> Squash warnings such as:
> 
> ```
> arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-galaxy100.dtb: /ahb/apb@1e600000/watchdog@1e785000: failed to match any schema with compatible: ['aspeed,ast2400-wdt']
> ```
> 
> The schema binding additionally defines the clocks property over the
> prose binding to align with use of the node in the DTS files.
> 
> Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
> ---
> v2: Address feedback from Rob and Zev
> 
>     - Rob: https://lore.kernel.org/linux-watchdog/20240402180718.GA358505-robh@kernel.org/
>     - Zev: https://lore.kernel.org/linux-watchdog/65722a59-2e94-4616-81e1-835615b0e600@hatter.bewilderbeest.net/
> 
> v1: https://lore.kernel.org/linux-watchdog/20240402120118.282035-1-andrew@codeconstruct.com.au/
> 
>  .../bindings/watchdog/aspeed,ast2400-wdt.yaml | 142 ++++++++++++++++++
>  .../bindings/watchdog/aspeed-wdt.txt          |  73 ---------
>  2 files changed, 142 insertions(+), 73 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
>  delete mode 100644 Documentation/devicetree/bindings/watchdog/aspeed-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> new file mode 100644
> index 000000000000..be78a9865584
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/aspeed,ast2400-wdt.yaml
> @@ -0,0 +1,142 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/aspeed,ast2400-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Aspeed watchdog timer controllers
> +
> +maintainers:
> +  - Andrew Jeffery <andrew@codeconstruct.com.au>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - aspeed,ast2400-wdt
> +      - aspeed,ast2500-wdt
> +      - aspeed,ast2600-wdt
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +    description: >

You don't need '>' either. I guess it is equivalent here as there are no 
double newlines. Drop these if you respin, otherwise:

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply

* [PATCH] arm64: dts: qcom: sm8150-hdk: enable WiFI support
From: Dmitry Baryshkov @ 2024-04-03 17:10 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: linux-arm-msm, devicetree, linux-kernel, Kalle Valo, Jeff Johnson,
	ath10k

Enable modem DSP and WiFI devices on the SM8150 HDK device. The HDK is
manufactured by Lantronix, but it attributed to Qualcomm, so the
calibration string uses Qualcomm as manufacturer.

For reference:

ath10k_snoc 18800000.wifi: qmi chip_id 0x30224 chip_family 0x4001 board_id 0x55 soc_id 0x40060000
ath10k_snoc 18800000.wifi: qmi fw_version 0x32040163 fw_build_timestamp 2019-10-08 05:42 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.3.2.0-00355-QCAHLSWMTPLZ-1
ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 0 tracing 0 dfs 0 testmode 0
ath10k_snoc 18800000.wifi: firmware ver  api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
ath10k_snoc 18800000.wifi: htt-ver 3.73 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
ath10k_snoc 18800000.wifi: invalid MAC address; choosing random

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Note the device also uses updated wlanmdsp, so it will be updated with
firmware-name for WiFi once [1] is merged.

[   68.236220] ath10k_snoc 18800000.wifi: chan info: invalid frequency 0 (idx 41 out of bounds)
[   69.426700] ath10k_snoc 18800000.wifi: chan info: invalid frequency 0 (idx 41 out of bounds)o

[1] https://lore.kernel.org/ath10k/20240306-wcn3990-firmware-path-v2-0-f89e98e71a57@linaro.org/
---
 arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
index de670b407ef1..6cb6f503fdac 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
@@ -609,6 +609,11 @@ &remoteproc_cdsp {
 	firmware-name = "qcom/sm8150/cdsp.mbn";
 };
 
+&remoteproc_mpss {
+	firmware-name = "qcom/sm8150/modem.mbn";
+	status = "okay";
+};
+
 &remoteproc_slpi {
 	status = "okay";
 
@@ -713,3 +718,14 @@ &usb_1_dwc3_ss {
 &usb_2_dwc3 {
 	dr_mode = "host";
 };
+
+&wifi {
+	status = "okay";
+
+	vdd-0.8-cx-mx-supply = <&vreg_l1a_0p75>;
+	vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
+	vdd-1.3-rfa-supply = <&vreg_l2c_1p3>;
+	vdd-3.3-ch0-supply = <&vreg_l11c_3p3>;
+
+	qcom,ath10k-calibration-variant = "Qualcomm_sm8150hdk";
+};

---
base-commit: abfb54bc2d2b925336c6ea9ae2b335e3867ceb89
change-id: 20240403-sm8150-hdk-wifi-74deaecaaecb

Best regards,
-- 
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>


^ permalink raw reply related

* Re: [PATCH v3 24/25] drivers: media: i2c: imx258: Add support for reset gpio
From: Ondřej Jirman @ 2024-04-03 17:03 UTC (permalink / raw)
  To: Sakari Ailus
  Cc: git, linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
	krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
	festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
	phone-devel
In-Reply-To: <Zg2Dy2QBguXQoR3P@kekkonen.localdomain>

Hi,

On Wed, Apr 03, 2024 at 04:28:59PM GMT, Sakari Ailus wrote:
> Hi Luis,
> 
> Could you unify the subject prefix for the driver patches, please? E.g.
> "media: imx258: " would be fine.
> 
> On Wed, Apr 03, 2024 at 09:03:53AM -0600, git@luigi311.com wrote:
> > From: Luis Garcia <git@luigi311.com>
> > 
> > It was documented in DT, but not implemented.
> > 
> > Signed-off-by: Ondrej Jirman <megous@megous.com>
> > Signed-off-by: Luis Garcia <git@luigi311.com>
> > ---
> >  drivers/media/i2c/imx258.c | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index 163f04f6f954..4c117c4829f1 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -680,6 +680,7 @@ struct imx258 {
> >  	unsigned int csi2_flags;
> >  
> >  	struct gpio_desc *powerdown_gpio;
> > +	struct gpio_desc *reset_gpio;
> >  
> >  	/*
> >  	 * Mutex for serialized access:
> > @@ -1232,7 +1233,11 @@ static int imx258_power_on(struct device *dev)
> >  		regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >  	}
> >  
> > -	return ret;
> > +	gpiod_set_value_cansleep(imx258->reset_gpio, 0);
> > +
> > +	usleep_range(400, 500);
> 
> You could mention this at least in the commit message.

This is T6 in the datasheet: https://megous.com/dl/tmp/92c9223ce877216e.png


> > +
> > +	return 0;
> >  }
> >  
> >  static int imx258_power_off(struct device *dev)
> > @@ -1243,6 +1248,7 @@ static int imx258_power_off(struct device *dev)
> >  	clk_disable_unprepare(imx258->clk);
> >  	regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >  
> > +	gpiod_set_value_cansleep(imx258->reset_gpio, 1);
> 
> Same question than on the other GPIO: does this belong here?

No, this should be before the regulator_bulk_disable.

See: https://megous.com/dl/tmp/c96180b23d7ce63a.png

kind regards,
	o.

> >  	gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> >  
> >  	return 0;
> > @@ -1554,6 +1560,12 @@ static int imx258_probe(struct i2c_client *client)
> >  	if (IS_ERR(imx258->powerdown_gpio))
> >  		return PTR_ERR(imx258->powerdown_gpio);
> >  
> > +	/* request optional reset pin */
> > +	imx258->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> > +						    GPIOD_OUT_HIGH);
> > +	if (IS_ERR(imx258->reset_gpio))
> > +		return PTR_ERR(imx258->reset_gpio);
> > +
> >  	/* Initialize subdev */
> >  	v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
> >  
> 
> -- 
> Regards,
> 
> Sakari Ailus

^ permalink raw reply

* Re: [PATCH v1 1/2] dt-bindings: mtd: amlogic,meson-nand: support fields for boot ROM code
From: Rob Herring @ 2024-04-03 17:02 UTC (permalink / raw)
  To: Arseniy Krasnov
  Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
	Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
	Jerome Brunet, Martin Blumenstingl, linux-mtd, devicetree,
	linux-arm-kernel, linux-amlogic, linux-kernel, oxffffaa, kernel
In-Reply-To: <20240402202705.2355326-2-avkrasnov@salutedevices.com>

On Tue, Apr 02, 2024 at 11:27:04PM +0300, Arseniy Krasnov wrote:
> Boot ROM code on Meson requires that some pages on NAND must be written
> in special mode: "short" ECC mode where each block is 384 bytes and
> scrambling mode is on. Such pages located with the specified interval
> within specified offset. Both interval and offset are located in the
> device tree and used by driver if 'nand-is-boot-medium' is set for
> NAND chip.
> 
> Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
> ---
>  .../bindings/mtd/amlogic,meson-nand.yaml         | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> index 57b6957c8415..f49819ee76b8 100644
> --- a/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> +++ b/Documentation/devicetree/bindings/mtd/amlogic,meson-nand.yaml
> @@ -64,11 +64,27 @@ patternProperties:
>          items:
>            maximum: 0
>  
> +      meson,boot-page-last:

'meson' is not a valid vendor.

> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          The NFC driver needs this information to select ECC
> +          algorithms supported by the boot ROM.
> +          Only used in combination with 'nand-is-boot-medium'.

No need to state what's captured with constraints.

> +
> +      meson,boot-page-step:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        description:
> +          The NFC driver needs this information to select ECC
> +          algorithms supported by the boot ROM.
> +          Only used in combination with 'nand-is-boot-medium'.

step is in blocks/pages/bytes?

> +
>      unevaluatedProperties: false
>  
>      dependencies:
>        nand-ecc-strength: [nand-ecc-step-size]
>        nand-ecc-step-size: [nand-ecc-strength]
> +      meson,boot-page-last: [nand-is-boot-medium]
> +      meson,boot-page-step: [nand-is-boot-medium]

I assume both properties must be present? If so:

meson,boot-page-last: ['meson,boot-page-step']
meson,boot-page-step: ['meson,boot-page-last']

Rob

^ permalink raw reply

* [PATCH] dt-bindings: omap-mcpdm: Convert to DT schema
From: Mighty @ 2024-04-03 16:59 UTC (permalink / raw)
  Cc: bavishimithil, Liam Girdwood, Mark Brown, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, alsa-devel, devicetree,
	linux-kernel

Convert the OMAP4+ McPDM bindings to DT schema.

Signed-off-by: Mighty <bavishimithil@gmail.com>
---
 .../devicetree/bindings/sound/omap-mcpdm.txt  | 30 ----------
 .../devicetree/bindings/sound/omap-mcpdm.yaml | 58 +++++++++++++++++++
 2 files changed, 58 insertions(+), 30 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.txt
 create mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.yaml

diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
deleted file mode 100644
index ff98a0cb5..000000000
--- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Texas Instruments OMAP4+ McPDM
-
-Required properties:
-- compatible: "ti,omap4-mcpdm"
-- reg: Register location and size as an array:
-       <MPU access base address, size>,
-       <L3 interconnect address, size>;
-- interrupts: Interrupt number for McPDM
-- ti,hwmods: Name of the hwmod associated to the McPDM
-- clocks:  phandle for the pdmclk provider, likely <&twl6040>
-- clock-names: Must be "pdmclk"
-
-Example:
-
-mcpdm: mcpdm@40132000 {
-	compatible = "ti,omap4-mcpdm";
-	reg = <0x40132000 0x7f>, /* MPU private access */
-	      <0x49032000 0x7f>; /* L3 Interconnect */
-	interrupts = <0 112 0x4>;
-	interrupt-parent = <&gic>;
-	ti,hwmods = "mcpdm";
-};
-
-In board DTS file the pdmclk needs to be added:
-
-&mcpdm {
-	clocks = <&twl6040>;
-	clock-names = "pdmclk";
-	status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml b/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml
new file mode 100644
index 000000000..8c9ff9d90
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/omap-mcpdm.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/omap-mcpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP McPDM
+
+maintainers:
+  - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+  OMAP ALSA SoC DAI driver using McPDM port used by TWL6040
+
+properties:
+  compatible:
+    const: ti,omap4-mcpdm
+
+  reg:
+    description: 'Register location and size as an array:
+       <MPU access base address, size>,
+       <L3 interconnect address, size>;'
+
+  interrupts:
+    description: Interrupt number for McPDM
+
+  ti,hwmods:
+    description: Name of the hwmod associated to the McPDM
+
+  clocks:
+    description: phandle for the pdmclk provider, likely <&twl6040>
+
+  clock-names:
+    description: Must be "pdmclk"
+
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - ti,hwmods
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+    mcpdm: mcpdm@40132000 {
+      compatible = "ti,omap4-mcpdm";
+      reg = <0x40132000 0x7f>, /* MPU private access */
+            <0x49032000 0x7f>; /* L3 Interconnect */
+      interrupts = <0 112 0x4>;
+      interrupt-parent = <&gic>;
+      ti,hwmods = "mcpdm";
+      clocks = <&twl6040>;
+      clock-names = "pdmclk";
+    };
-- 
2.34.1


^ permalink raw reply related

* Re: [PATCH v1 3/4] dt-bindings: arm: fsl: Add Colibri iMX8DX
From: Rob Herring @ 2024-04-03 16:58 UTC (permalink / raw)
  To: Hiago De Franco
  Cc: Sascha Hauer, imx, Conor Dooley, Shawn Guo, linux-kernel,
	Fabio Estevam, Pengutronix Kernel Team, devicetree,
	linux-arm-kernel, Krzysztof Kozlowski, Hiago De Franco
In-Reply-To: <20240402193512.240417-4-hiagofranco@gmail.com>


On Tue, 02 Apr 2024 16:35:11 -0300, Hiago De Franco wrote:
> From: Hiago De Franco <hiago.franco@toradex.com>
> 
> Add support for Toradex Colibri iMX8DX SoM. As the i.MX8QXP variant is
> already supported, update the description with i.MX8DX and add
> 'fsl,imx8dx' item as well.
> 
> Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v3 23/25] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Ondřej Jirman @ 2024-04-03 16:57 UTC (permalink / raw)
  To: Sakari Ailus
  Cc: git, linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
	krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
	festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
	phone-devel
In-Reply-To: <Zg2DBasC501hMQSS@kekkonen.localdomain>

Hi Sakari and Luis,

On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
> Hi Luis, Ondrej,
> 
> On Wed, Apr 03, 2024 at 09:03:52AM -0600, git@luigi311.com wrote:
> > From: Luis Garcia <git@luigi311.com>
> > 
> > On some boards powerdown signal needs to be deasserted for this
> > sensor to be enabled.
> > 
> > Signed-off-by: Ondrej Jirman <megi@xff.cz>
> > Signed-off-by: Luis Garcia <git@luigi311.com>
> > ---
> >  drivers/media/i2c/imx258.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index 30352c33f63c..163f04f6f954 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -679,6 +679,8 @@ struct imx258 {
> >  	unsigned int lane_mode_idx;
> >  	unsigned int csi2_flags;
> >  
> > +	struct gpio_desc *powerdown_gpio;
> > +
> >  	/*
> >  	 * Mutex for serialized access:
> >  	 * Protect sensor module set pad format and start/stop streaming safely.
> > @@ -1213,6 +1215,8 @@ static int imx258_power_on(struct device *dev)
> >  	struct imx258 *imx258 = to_imx258(sd);
> >  	int ret;
> >  
> > +	gpiod_set_value_cansleep(imx258->powerdown_gpio, 0);
> 
> What does the spec say? Should this really happen before switching on the
> supplies below?

There's no powerdown input in the IMX258 manual. The manual only mentions
that XCLR (reset) should be held low during power on.

https://megous.com/dl/tmp/15b0992a720ab82d.png

https://megous.com/dl/tmp/f2cc991046d97641.png

   This sensor doesn’t have a built-in “Power ON Reset” function. The XCLR pin
   is set to “LOW” and the power supplies are brought up. Then the XCLR pin
   should be set to “High” after INCK supplied.

So this input is some feature on camera module itself outside of the
IMX258 chip, which I think is used to gate power to the module. Eg. on Pinephone
Pro, there are two modules with shared power rails, so enabling supply to
one module enables it to the other one, too. So this input becomes the only way
to really enable/disable power to the chip when both are used at once at some
point, because regulator_bulk_enable/disable becomes ineffective at that point.

Luis, maybe you saw some other datasheet that mentions this input? IMO,
it just gates the power rails via some mosfets on the module itself, since
there's not power down input to the chip itself.

kind regards,
	o.

> > +
> >  	ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
> >  				    imx258->supplies);
> >  	if (ret) {
> > @@ -1224,6 +1228,7 @@ static int imx258_power_on(struct device *dev)
> >  	ret = clk_prepare_enable(imx258->clk);
> >  	if (ret) {
> >  		dev_err(dev, "failed to enable clock\n");
> > +		gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> >  		regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >  	}
> >  
> > @@ -1238,6 +1243,8 @@ static int imx258_power_off(struct device *dev)
> >  	clk_disable_unprepare(imx258->clk);
> >  	regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> >  
> > +	gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> > +
> >  	return 0;
> >  }
> >  
> > @@ -1541,6 +1548,12 @@ static int imx258_probe(struct i2c_client *client)
> >  	if (!imx258->variant_cfg)
> >  		imx258->variant_cfg = &imx258_cfg;
> >  
> > +	/* request optional power down pin */
> > +	imx258->powerdown_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> > +						    GPIOD_OUT_HIGH);
> > +	if (IS_ERR(imx258->powerdown_gpio))
> > +		return PTR_ERR(imx258->powerdown_gpio);
> > +
> >  	/* Initialize subdev */
> >  	v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
> >  
> 
> -- 
> Regards,
> 
> Sakari Ailus

^ permalink raw reply

* Re: [PATCH v1 2/4] dt-bindings: arm: fsl: remove reduntant toradex,colibri-imx8x
From: Rob Herring @ 2024-04-03 16:57 UTC (permalink / raw)
  To: Hiago De Franco
  Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
	Krzysztof Kozlowski, Conor Dooley, Hiago De Franco, imx,
	linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240402193512.240417-3-hiagofranco@gmail.com>

On Tue, Apr 02, 2024 at 04:35:10PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco <hiago.franco@toradex.com>
> 
> 'toradex,colibri-imx8x' is already present as a constant value for
> 'i.MX8QP Board with Toradex Colibri iMX8X Modules', so there is no need
> to keep it twice as a enum value for 'i.MX8QXP based Boards'.

If the module can operate on its own, then it would be valid to have 
just "toradex,colibri-imx8x". If not, then:

Acked-by: Rob Herring <robh@kernel.org>

> 
> Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
> ---
>  Documentation/devicetree/bindings/arm/fsl.yaml | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 0027201e19f8..6fdfa10af43c 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -1218,7 +1218,6 @@ properties:
>            - enum:
>                - einfochips,imx8qxp-ai_ml  # i.MX8QXP AI_ML Board
>                - fsl,imx8qxp-mek           # i.MX8QXP MEK Board
> -              - toradex,colibri-imx8x     # Colibri iMX8X Modules
>            - const: fsl,imx8qxp
>  
>        - description: i.MX8DXL based Boards
> -- 
> 2.39.2
> 

^ permalink raw reply

* Re: [PATCH v4 2/2] media: dt-bindings: ovti,ov2680: Document link-frequencies
From: Rob Herring @ 2024-04-03 16:52 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Fabio Estevam, rmfrfs, laurent.pinchart, linux-media, conor+dt,
	sakari.ailus, krzysztof.kozlowski+dt, devicetree, hansg
In-Reply-To: <20240402174028.205434-2-festevam@gmail.com>


On Tue, 02 Apr 2024 14:40:28 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> Document the link-frequencies property as recommended by the following
> document:
> 
> https://www.kernel.org/doc/html/v6.9-rc1/driver-api/media/camera-sensor.html#handling-clocks
> 
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Changes since v3:
> - Only document link-frequencies.
> 
>  .../bindings/media/i2c/ovti,ov2680.yaml         | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 1/2] media: dt-bindings: ovti,ov2680: Fix the power supply names
From: Rob Herring @ 2024-04-03 16:51 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Fabio Estevam, krzysztof.kozlowski+dt, laurent.pinchart,
	devicetree, linux-media, hansg, sakari.ailus, conor+dt, rmfrfs
In-Reply-To: <20240402174028.205434-1-festevam@gmail.com>


On Tue, 02 Apr 2024 14:40:27 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
> 
> The original .txt bindings had the OV2680 power supply names correct,
> but the transition from .txt to yaml spelled them incorrectly.
> 
> Fix the OV2680 power supply names as the original .txt bindings
> as these are the names used by the OV2680 driver and in devicetree.
> 
> Fixes: 57226cd8c8bf ("media: dt-bindings: ov2680: convert bindings to yaml")
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Changes since v3:
> - Newly introduced.
> 
>  .../bindings/media/i2c/ovti,ov2680.yaml        | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 

Reviewed-by: Rob Herring <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v14 01/18] irqchip/sifive-plic: Convert PLIC driver into a platform driver
From: Anup Patel @ 2024-04-03 16:42 UTC (permalink / raw)
  To: Lad, Prabhakar
  Cc: Anup Patel, Geert Uytterhoeven, Palmer Dabbelt, Paul Walmsley,
	Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Frank Rowand,
	Conor Dooley, Marc Zyngier, Björn Töpel, Atish Patra,
	Andrew Jones, Sunil V L, Saravana Kannan, linux-riscv,
	linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <CA+V-a8ser=hDmst6+XSeOWaEoOd+iY3Ys6bYBWDa5UYPfT+Pug@mail.gmail.com>

On Wed, Apr 3, 2024 at 9:19 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
>
> On Wed, Apr 3, 2024 at 3:17 PM Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, Apr 3, 2024 at 2:01 PM Lad, Prabhakar
> > <prabhakar.csengg@gmail.com> wrote:
> > >
> > > Hi Anup,
> > >
> > > On Thu, Feb 22, 2024 at 9:41 AM Anup Patel <apatel@ventanamicro.com> wrote:
> > > >
> > > > The PLIC driver does not require very early initialization so convert
> > > > it into a platform driver.
> > > >
> > > > After conversion, the PLIC driver is probed after CPUs are brought-up
> > > > so setup cpuhp state after context handler of all online CPUs are
> > > > initialized otherwise PLIC driver crashes for platforms with multiple
> > > > PLIC instances.
> > > >
> > > > Signed-off-by: Anup Patel <apatel@ventanamicro.com>
> > > > ---
> > > >  drivers/irqchip/irq-sifive-plic.c | 101 ++++++++++++++++++------------
> > > >  1 file changed, 61 insertions(+), 40 deletions(-)
> > > >
> > > This patch seems to have broken things on RZ/Five SoC, after reverting
> > > this patch I get to boot it back again on v6.9-rc2. Looks like there
> > > is some probe order issue after switching to platform driver?
> >
> > Yes, this is most likely related to probe ordering based on your DT.
> >
> > Can you share the failing boot log and DT ?
>
> non working case, https://paste.debian.net/1312947/

> after reverting, https://paste.debian.net/1312948/
> (attached is the DTB)

Can you add "console=ttySC0,115200" to kernel parameters and
share updated boot logs ?

Regards,
Anup

^ permalink raw reply

* Re: [PATCH 6/6] iio: adc: ad7173: Add support for AD411x devices
From: David Lechner @ 2024-04-03 16:37 UTC (permalink / raw)
  To: Ceclan, Dumitru
  Cc: dumitru.ceclan, Lars-Peter Clausen, Michael Hennerich,
	Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	linux-iio, devicetree, linux-kernel
In-Reply-To: <c7c26d36-ab08-420c-b634-8eb6d9cee9b5@gmail.com>

On Wed, Apr 3, 2024 at 4:53 AM Ceclan, Dumitru <mitrutzceclan@gmail.com> wrote:
>
>
> On 01/04/2024 22:45, David Lechner wrote:
> > On Mon, Apr 1, 2024 at 10:10 AM Dumitru Ceclan via B4 Relay
> > <devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
> >>
> >> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
> >>
>
> ...
>
> >>  #define AD7175_2_ID                    0x0cd0
> >>  #define AD7172_4_ID                    0x2050
> >>  #define AD7173_ID                      0x30d0
> >> +#define AD4111_ID                      0x30d0
> >> +#define AD4112_ID                      0x30d0
> >> +#define AD4114_ID                      0x30d0
> >
> > It might make it a bit more obvious that not all chips have a unique
> > ID if we rename AD7173_ID to AD7173_AD4111_AD4112_AD4114_ID rather
> > than introducing multiple macros with the same value.
> >
> > Or leave it as AD7173_ID to keep it short and add a comment where it
> > is used with 411x chips in ad7173_device_info[].
> >
>
> Sure
>
> >> +#define AD4116_ID                      0x34d0
> >> +#define AD4115_ID                      0x38d0
> >>  #define AD7175_8_ID                    0x3cd0
> >>  #define AD7177_ID                      0x4fd0
> >>  #define AD7173_ID_MASK                 GENMASK(15, 4)
>
> ...
>
> >>  struct ad7173_device_info {
> >>         const unsigned int *sinc5_data_rates;
> >>         unsigned int num_sinc5_data_rates;
> >>         unsigned int odr_start_value;
> >> +       unsigned int num_inputs_with_divider;
> >>         unsigned int num_channels;
> >>         unsigned int num_configs;
> >>         unsigned int num_inputs;
> >
> > Probably a good idea to change num_inputs to num_voltage_inputs so it
> > isn't confused with the total number of inputs.
> >
> > Similarly num_voltage_inputs_with_divider instead of num_inputs_with_divider.
> >
> > Also could use a comment to make it clear if num_voltage_inputs
> > includes num_voltage_inputs_with_divider or not. And that it doesn't
> > include VINCOM.
> >
>
> Alright for these 3 statements above.
>
> > Probably also need some flag here to differentiate ADCINxx voltage
> > inputs on AD4116.
> >
>
> That is the purpose of num_inputs_with_divider. Mangled some changes
> when splitting into individual patches. Will include in V2.
> "
> if (ain[1] == AD411X_VCOM_INPUT &&
>                     ain[0] >= st->info->num_inputs_with_divider)
>                         return dev_err_probe(dev, -EINVAL,
>                 "VCOM must be paired with inputs having divider.\n");
> "
>
> ...
>
> >>
> >> +static unsigned int ad4111_current_channel_config[] = {
> >> +       [AD4111_CURRENT_IN0P_IN0N] = 0x1E8,
> >> +       [AD4111_CURRENT_IN1P_IN1N] = 0x1C9,
> >> +       [AD4111_CURRENT_IN2P_IN2N] = 0x1AA,
> >> +       [AD4111_CURRENT_IN3P_IN3N] = 0x18B,
> >> +};
> >
> > As mentioned in the DT bindings review, it would make more sense to
> > just use the datasheet numbers for the current input channels in the
> > diff-channels DT property, then we don't need this lookup table.
> >
> Yet, the datasheet does not specify the numbers, just a single bitfield
> for each pair. It is too much of a churn to need to decode that bitfield
> into individual values when the user just wants to select a single pair.
>
> ...
>
> >> +               case IIO_CURRENT:
> >> +                       *val = ad7173_get_ref_voltage_milli(st, ch->cfg.ref_sel);
> >> +                       *val /= AD4111_SHUNT_RESISTOR_OHM;
> >> +                       *val2 = chan->scan_type.realbits - !!(ch->cfg.bipolar);
> >
> > Static analysis tools like to complain about using bool as int.
> > Probably more clear to write it as (ch->cfg.bipolar ? 1 : 0) anyway.
> >
> Maybe it does not apply here, but i followed this advice:
>
> Andy Shevchenko V1 of AD7173 (named initially ad717x)
> "
> > +     return (bool)(value & mask);
>
> This is weird. You have int which you get from bool, wouldn't be better
> to use
> !!(...) as other GPIO drivers do?

As long as the build bots don't complain, there isn't a reason to
change it. It is just a matter of personal preference at that point.

I got a sparse warning for something like this recently [1], but maybe
that case was just because it was inside of a FIELD_PREP() using it as
bit logic instead of addition and we won't get any warnings here.

[1]: https://lore.kernel.org/linux-iio/20240129195611.701611-3-dlechner@baylibre.com/

>
> "
>
>
> >> +               case IIO_CURRENT:
> >>                         *val = -BIT(chan->scan_type.realbits - 1);
> >
> > Expecting a special case here, at least when ADCIN15 is configured for
> > pseudo-differential inputs.
> >
>
> And what configuration would that be?
> The only configurable part is the BI_UNIPOLARx bit in the channel
> register, which is addressed here.
>
> There seems to be a confusion similar to what we had with single-ended
> channels. The ADC is differential. Pseudo-differential in this datasheet
> just means that you wired a fixed voltage(higher than 0) to the negative
> analog input.
>
>  Which you can also do on the other inputs with a divider.
>

As discussed elsewhere, you can disregard this suggestion.

> ...
>
> >> -               chan_st_priv->ain = AD7173_CH_ADDRESS(ain[0], ain[1]);
> >> +               if (reg >= AD4111_CURRENT_CHAN_CUTOFF) {
> >> +                       chan->type = IIO_CURRENT;
> >> +                       chan->channel = ain[0];
> >> +                       chan_st_priv->ain = ad4111_current_channel_config[ain[0]];
> >> +               } else {
> >> +                       chan->channel = ain[0];
> >> +                       chan->channel2 = ain[1];
> >> +                       chan->differential = true;
> >
> > Expecting chan->differential = false when ADCIN15 is configured for
> > pseudo-differential inputs.
> >
> > Also, perhaps missed in previous reviews, I would expect
> > chan->differential = false when channels are used as single-ended.
> >
> Why?
> Also, how would one detect if you are using single-ended channels?
>
> The ADC is still differential. Single ended is represented as connecting
> AVSS(or another fixed voltage) and only letting the AIN+ input to fluctuate.
>
> In the IIO framework the only difference this makes is in the naming of
> the channel:
>  voltage0-voltage1 vs just voltage0
>
> All channels are differential. Pseudo differential: still differential.

In the discussions on the AD7380 patch series, we came to the
conclusion that pseduo-differential is technically not differential in
the context of the .differential flag in IIO.

But as mentioned in my follow up, for this driver it is going to make
things far simpler if we just ignore that and treat
pseudo-differential the same as fully differential.

^ permalink raw reply

* Re: [PATCH v3 24/25] drivers: media: i2c: imx258: Add support for reset gpio
From: Sakari Ailus @ 2024-04-03 16:28 UTC (permalink / raw)
  To: git
  Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
	krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
	festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
	phone-devel, Ondrej Jirman
In-Reply-To: <20240403150355.189229-25-git@luigi311.com>

Hi Luis,

Could you unify the subject prefix for the driver patches, please? E.g.
"media: imx258: " would be fine.

On Wed, Apr 03, 2024 at 09:03:53AM -0600, git@luigi311.com wrote:
> From: Luis Garcia <git@luigi311.com>
> 
> It was documented in DT, but not implemented.
> 
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> Signed-off-by: Luis Garcia <git@luigi311.com>
> ---
>  drivers/media/i2c/imx258.c | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 163f04f6f954..4c117c4829f1 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -680,6 +680,7 @@ struct imx258 {
>  	unsigned int csi2_flags;
>  
>  	struct gpio_desc *powerdown_gpio;
> +	struct gpio_desc *reset_gpio;
>  
>  	/*
>  	 * Mutex for serialized access:
> @@ -1232,7 +1233,11 @@ static int imx258_power_on(struct device *dev)
>  		regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>  	}
>  
> -	return ret;
> +	gpiod_set_value_cansleep(imx258->reset_gpio, 0);
> +
> +	usleep_range(400, 500);

You could mention this at least in the commit message.

> +
> +	return 0;
>  }
>  
>  static int imx258_power_off(struct device *dev)
> @@ -1243,6 +1248,7 @@ static int imx258_power_off(struct device *dev)
>  	clk_disable_unprepare(imx258->clk);
>  	regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
>  
> +	gpiod_set_value_cansleep(imx258->reset_gpio, 1);

Same question than on the other GPIO: does this belong here?

>  	gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
>  
>  	return 0;
> @@ -1554,6 +1560,12 @@ static int imx258_probe(struct i2c_client *client)
>  	if (IS_ERR(imx258->powerdown_gpio))
>  		return PTR_ERR(imx258->powerdown_gpio);
>  
> +	/* request optional reset pin */
> +	imx258->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> +						    GPIOD_OUT_HIGH);
> +	if (IS_ERR(imx258->reset_gpio))
> +		return PTR_ERR(imx258->reset_gpio);
> +
>  	/* Initialize subdev */
>  	v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
>  

-- 
Regards,

Sakari Ailus

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox