[PATCH 0/1] Introduce Monaco EVK Peripheral Mezzanine

[PATCH 0/1] Introduce Monaco EVK Peripheral Mezzanine

[Umang Chheda]

Introduce device tree support for the Mezzanine peripheral expansion
card used with the Qualcomm Monaco Evaluation Kit (EVK).

The Monaco Mezzanine is an additional add-on card which can be stacked
on top of monaco-evk board to extend peripheral capabilities of
monaco-evk used for industrial applications.

It connects via expansion headers on the monaco-evk and provides
following peripherals :
- 4x Type A USB ports in host mode.
- TC9563 PCIe switch, which has following three downstream ports (DSP) :
   - 1st DSP connects M.2 E-key connector for connecting WLAN endpoints.
   - 2nd DSP connect M.2 B-key connector for connecting cellular modems.
   - 3rd DSP with support for Dual Ethernet ports.
- EEPROM.
- LVDS Display.
- 2*mini DP.

Umang Chheda (1):
  arm64: dts: qcom: monaco-evk: Add Mezzanine

 arch/arm64/boot/dts/qcom/Makefile             |   4 +
 .../boot/dts/qcom/monaco-evk-mezzanine.dtso   | 189 ++++++++++++++++++
 2 files changed, 193 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso

--
2.34.1

[PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

The Mezzanine is an hardware expansion add-on board designed
to be stacked on top of Monaco EVK.

It has following peripherals :

- 4x Type A USB ports in host mode.
- TC9563 PCIe switch, which has following three downstream ports (DSP) :
   - 1st DSP connects M.2 E-key connector for connecting WLAN endpoints.
   - 2nd DSP connects M.2 B-key connector for connecting cellular
     modems.
   - 3rd DSP with support for Dual Ethernet ports.
- EEPROM.
- LVDS Display.
- 2*mini DP.

Add support for following peripherals :
- TC9563 PCIe Switch.
- EEPROM.

Written with inputs from :
    Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> - PCIe
    Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.

Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
---
 arch/arm64/boot/dts/qcom/Makefile             |   4 +
 .../boot/dts/qcom/monaco-evk-mezzanine.dtso   | 189 ++++++++++++++++++
 2 files changed, 193 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f80b5d9cf1e8..009e50c145e9 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -45,6 +45,10 @@ lemans-evk-el2-dtbs := lemans-evk.dtb lemans-el2.dtbo
 dtb-$(CONFIG_ARCH_QCOM)	+= lemans-evk-el2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= milos-fairphone-fp6.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk.dtb
+
+monaco-evk-mezzanine-dtbs	:= monaco-evk.dtb monaco-evk-mezzanine.dtbo
+
+dtb-$(CONFIG_ARCH_QCOM)	+= monaco-evk-mezzanine.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8216-samsung-fortuna3g.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-acer-a1-724.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= msm8916-alcatel-idol347.dtb
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
new file mode 100644
index 000000000000..7811bd9e7ea6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+	model = "Qualcomm Technologies, Inc. Monaco-EVK Mezzanine";
+
+	vreg_0p9: regulator-vreg-0p9 {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_0P9";
+
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_3p3>;
+	};
+
+	vreg_1p8: regulator-vreg-1p8 {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_1P8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_4p2>;
+	};
+
+	vreg_3p3: regulator-vreg-3p3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_3P3";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_4p2>;
+	};
+
+	vreg_4p2: regulator-vreg-4p2 {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_4P2";
+
+		regulator-min-microvolt = <4200000>;
+		regulator-max-microvolt = <4200000>;
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vreg_sys_pwr>;
+	};
+
+	vreg_sys_pwr: regulator-vreg-sys-pwr {
+		compatible = "regulator-fixed";
+		regulator-name = "VREG_SYS_PWR";
+
+		regulator-min-microvolt = <24000000>;
+		regulator-max-microvolt = <24000000>;
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&i2c15 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	status = "okay";
+
+	eeprom1: eeprom@52 {
+		compatible = "giantec,gt24c256c", "atmel,24c256";
+		reg = <0x52>;
+		pagesize = <64>;
+
+		nvmem-layout {
+			compatible = "fixed-layout";
+			#address-cells = <1>;
+			#size-cells = <1>;
+		};
+	};
+};
+
+&pcie0 {
+	iommu-map = <0x0   &pcie_smmu 0x0 0x1>,
+		    <0x100 &pcie_smmu 0x1 0x1>,
+		    <0x208 &pcie_smmu 0x2 0x1>,
+		    <0x210 &pcie_smmu 0x3 0x1>,
+		    <0x218 &pcie_smmu 0x4 0x1>,
+		    <0x300 &pcie_smmu 0x5 0x1>,
+		    <0x400 &pcie_smmu 0x6 0x1>,
+		    <0x500 &pcie_smmu 0x7 0x1>,
+		    <0x501 &pcie_smmu 0x8 0x1>;
+};
+
+&pcieport0 {
+	#address-cells = <3>;
+	#size-cells = <2>;
+
+	pcie@0,0 {
+		compatible = "pci1179,0623";
+		reg = <0x10000 0x0 0x0 0x0 0x0>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+
+		device_type = "pci";
+		ranges;
+		bus-range = <0x2 0xff>;
+
+		vddc-supply = <&vreg_0p9>;
+		vdd18-supply = <&vreg_1p8>;
+		vdd09-supply = <&vreg_0p9>;
+		vddio1-supply = <&vreg_1p8>;
+		vddio2-supply = <&vreg_1p8>;
+		vddio18-supply = <&vreg_1p8>;
+
+		i2c-parent = <&i2c15 0x77>;
+
+		resx-gpios = <&tlmm 124 GPIO_ACTIVE_LOW>;
+
+		pinctrl-0 = <&tc9563_resx_n>;
+		pinctrl-names = "default";
+
+		pcie@1,0 {
+			reg = <0x20800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x3 0xff>;
+		};
+
+		pcie@2,0 {
+			reg = <0x21000 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			device_type = "pci";
+			ranges;
+			bus-range = <0x4 0xff>;
+		};
+
+		pcie@3,0 {
+			reg = <0x21800 0x0 0x0 0x0 0x0>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			ranges;
+			bus-range = <0x5 0xff>;
+
+			pci@0,0 {
+				reg = <0x50000 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+
+			pci@0,1 {
+				reg = <0x50100 0x0 0x0 0x0 0x0>;
+				#address-cells = <3>;
+				#size-cells = <2>;
+				device_type = "pci";
+				ranges;
+			};
+		};
+	};
+};
+
+&tlmm {
+	tc9563_resx_n: tc9563-resx-state {
+		pins = "gpio124";
+		function = "gpio";
+
+		bias-disable;
+		input-disable;
+		output-enable;
+		power-source = <0>;
+	};
+};
--
2.34.1

Re: [PATCH 0/1] Introduce Monaco EVK Peripheral Mezzanine

[Dmitry Baryshkov]

On Tue, Feb 10, 2026 at 04:08:20PM +0530, Umang Chheda wrote:
> Introduce device tree support for the Mezzanine peripheral expansion
> card used with the Qualcomm Monaco Evaluation Kit (EVK).
> 
> The Monaco Mezzanine is an additional add-on card which can be stacked
> on top of monaco-evk board to extend peripheral capabilities of
> monaco-evk used for industrial applications.
> 
> It connects via expansion headers on the monaco-evk and provides
> following peripherals :
> - 4x Type A USB ports in host mode.
> - TC9563 PCIe switch, which has following three downstream ports (DSP) :
>    - 1st DSP connects M.2 E-key connector for connecting WLAN endpoints.
>    - 2nd DSP connect M.2 B-key connector for connecting cellular modems.
>    - 3rd DSP with support for Dual Ethernet ports.
> - EEPROM.
> - LVDS Display.
> - 2*mini DP.

You don't need cover letter for 1-patch series.

> 
> Umang Chheda (1):
>   arm64: dts: qcom: monaco-evk: Add Mezzanine
> 
>  arch/arm64/boot/dts/qcom/Makefile             |   4 +
>  .../boot/dts/qcom/monaco-evk-mezzanine.dtso   | 189 ++++++++++++++++++
>  2 files changed, 193 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
> 
> --
> 2.34.1
> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Dmitry Baryshkov]

On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
> The Mezzanine is an hardware expansion add-on board designed
> to be stacked on top of Monaco EVK.
> 
> It has following peripherals :
> 
> - 4x Type A USB ports in host mode.
> - TC9563 PCIe switch, which has following three downstream ports (DSP) :
>    - 1st DSP connects M.2 E-key connector for connecting WLAN endpoints.
>    - 2nd DSP connects M.2 B-key connector for connecting cellular
>      modems.

I hope to see these being described as soon as M.2 bindings land.

>    - 3rd DSP with support for Dual Ethernet ports.
> - EEPROM.
> - LVDS Display.
> - 2*mini DP.
> 
> Add support for following peripherals :
> - TC9563 PCIe Switch.
> - EEPROM.
> 
> Written with inputs from :
>     Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> - PCIe
>     Monish Chunara <monish.chunara@oss.qualcomm.com> - EEPROM.
> 
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
>  arch/arm64/boot/dts/qcom/Makefile             |   4 +
>  .../boot/dts/qcom/monaco-evk-mezzanine.dtso   | 189 ++++++++++++++++++
>  2 files changed, 193 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
> 

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

> 

-- 
With best wishes
Dmitry

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Konrad Dybcio]

On 2/10/26 11:38 AM, Umang Chheda wrote:
> The Mezzanine is an hardware expansion add-on board designed

There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
is there a better name for it?

[...]

> +&tlmm {
> +	tc9563_resx_n: tc9563-resx-state {
> +		pins = "gpio124";
> +		function = "gpio";
> +
> +		bias-disable;

please drop the empty line above

Konrad

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

Hi Konrad,

On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
> On 2/10/26 11:38 AM, Umang Chheda wrote:
>> The Mezzanine is an hardware expansion add-on board designed
> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
> is there a better name for it?

Does, Interface Plus (IFP) Mezz sounds good ?

>
> [...]
>
>> +&tlmm {
>> +	tc9563_resx_n: tc9563-resx-state {
>> +		pins = "gpio124";
>> +		function = "gpio";
>> +
>> +		bias-disable;
> please drop the empty line above

Ack

>
> Konrad

Thanks,
Umang

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Konrad Dybcio]

On 2/12/26 4:50 PM, Umang Chheda wrote:
> Hi Konrad,
> 
> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>> The Mezzanine is an hardware expansion add-on board designed
>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>> is there a better name for it?
> 
> Does, Interface Plus (IFP) Mezz sounds good ?

I don't know, does it stay Interface Plus on the silkscreen or similar?

Konrad

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Bjorn Andersson]

On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
[..]
> +&i2c15 {
> +	#address-cells = <1>;
> +	#size-cells = <0>;

Do we need to repeat this? It's in the top-level i2c15 definition
already?

> +
> +	status = "okay";

I presume this overlay is used on top of monaco-evk.dtb, which already
says that status is okay.


That said, I don't see a "clock-frequency" in either node, so I presume
you have an error/warning in your kernel log about this. But unless you
have reason to change that in your overlay, I think that's a unrelated
patch on the monaco-evk.dts - which I would like you to send, separately.

> +
> +	eeprom1: eeprom@52 {
> +		compatible = "giantec,gt24c256c", "atmel,24c256";
> +		reg = <0x52>;
> +		pagesize = <64>;
> +
> +		nvmem-layout {
> +			compatible = "fixed-layout";
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +		};
> +	};
> +};
> +
[..]
> +&tlmm {
> +	tc9563_resx_n: tc9563-resx-state {
> +		pins = "gpio124";
> +		function = "gpio";
> +
> +		bias-disable;
> +		input-disable;
> +		output-enable;
> +		power-source = <0>;

Does these properties really match the TLMM binding? Please double
check.

Regards,
Bjorn

> +	};
> +};
> --
> 2.34.1
> 

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

On 2/12/2026 9:59 PM, Konrad Dybcio wrote:
> On 2/12/26 4:50 PM, Umang Chheda wrote:
>> Hi Konrad,
>>
>> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>>> The Mezzanine is an hardware expansion add-on board designed
>>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>>> is there a better name for it?
>> Does, Interface Plus (IFP) Mezz sounds good ?
> I don't know, does it stay Interface Plus on the silkscreen or similar?


I checked the board - there is nothing written on the silkscreen. Internally we call this board Interface Plus (IFP) mezz.

>
> Konrad

Thanks,
Umang

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

Hello Bjorn,

On 2/13/2026 1:33 AM, Bjorn Andersson wrote:
> On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
> [..]
>> +&i2c15 {
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
> Do we need to repeat this? It's in the top-level i2c15 definition
> already?

Yes this is required to be repeated in case of DTSO -- else seeing DT binding error if these cells are not added here.
Seems the compiler is not looking at what is present in the Base DT first and is considering the default
values for address and size cells and throwing error. Had to add similarly add for PCIe node
as well to suppress binding errors.

>
>> +
>> +	status = "okay";
> I presume this overlay is used on top of monaco-evk.dtb, which already
> says that status is okay.

Ack

>
>
> That said, I don't see a "clock-frequency" in either node, so I presume
> you have an error/warning in your kernel log about this. But unless you
> have reason to change that in your overlay, I think that's a unrelated
> patch on the monaco-evk.dts - which I would like you to send, separately.


Ack, will share a separate patch to fix this issue.

>
>> +
>> +	eeprom1: eeprom@52 {
>> +		compatible = "giantec,gt24c256c", "atmel,24c256";
>> +		reg = <0x52>;
>> +		pagesize = <64>;
>> +
>> +		nvmem-layout {
>> +			compatible = "fixed-layout";
>> +			#address-cells = <1>;
>> +			#size-cells = <1>;
>> +		};
>> +	};
>> +};
>> +
> [..]
>> +&tlmm {
>> +	tc9563_resx_n: tc9563-resx-state {
>> +		pins = "gpio124";
>> +		function = "gpio";
>> +
>> +		bias-disable;
>> +		input-disable;
>> +		output-enable;
>> +		power-source = <0>;
> Does these properties really match the TLMM binding? Please double
> check.

Double checked on this -- all the properties match the TLMM bindings.

>
> Regards,
> Bjorn
>
>> +	};
>> +};
>> --
>> 2.34.1


Thanks,
Umang

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Konrad Dybcio]

On 2/16/26 9:04 AM, Umang Chheda wrote:
> 
> On 2/12/2026 9:59 PM, Konrad Dybcio wrote:
>> On 2/12/26 4:50 PM, Umang Chheda wrote:
>>> Hi Konrad,
>>>
>>> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>>>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>>>> The Mezzanine is an hardware expansion add-on board designed
>>>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>>>> is there a better name for it?
>>> Does, Interface Plus (IFP) Mezz sounds good ?
>> I don't know, does it stay Interface Plus on the silkscreen or similar?
> 
> 
> I checked the board - there is nothing written on the silkscreen. Internally we call this board Interface Plus (IFP) mezz.

Let's keep using that name then please

Konrad

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

On 2/16/2026 4:44 PM, Konrad Dybcio wrote:
> On 2/16/26 9:04 AM, Umang Chheda wrote:
>> On 2/12/2026 9:59 PM, Konrad Dybcio wrote:
>>> On 2/12/26 4:50 PM, Umang Chheda wrote:
>>>> Hi Konrad,
>>>>
>>>> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>>>>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>>>>> The Mezzanine is an hardware expansion add-on board designed
>>>>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>>>>> is there a better name for it?
>>>> Does, Interface Plus (IFP) Mezz sounds good ?
>>> I don't know, does it stay Interface Plus on the silkscreen or similar?
>>
>> I checked the board - there is nothing written on the silkscreen. Internally we call this board Interface Plus (IFP) mezz.
> Let's keep using that name then please


Ack, Should I also rename the DTSO filename to "monaco-evk-ifp-mezz.dtso" ? 

>
> Konrad


Thanks,
Umang

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Konrad Dybcio]

On 2/17/26 7:43 AM, Umang Chheda wrote:
> 
> On 2/16/2026 4:44 PM, Konrad Dybcio wrote:
>> On 2/16/26 9:04 AM, Umang Chheda wrote:
>>> On 2/12/2026 9:59 PM, Konrad Dybcio wrote:
>>>> On 2/12/26 4:50 PM, Umang Chheda wrote:
>>>>> Hi Konrad,
>>>>>
>>>>> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>>>>>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>>>>>> The Mezzanine is an hardware expansion add-on board designed
>>>>>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>>>>>> is there a better name for it?
>>>>> Does, Interface Plus (IFP) Mezz sounds good ?
>>>> I don't know, does it stay Interface Plus on the silkscreen or similar?
>>>
>>> I checked the board - there is nothing written on the silkscreen. Internally we call this board Interface Plus (IFP) mezz.
>> Let's keep using that name then please
> 
> 
> Ack, Should I also rename the DTSO filename to "monaco-evk-ifp-mezz.dtso" ? 

Please do!

Konrad

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

On 2/17/2026 3:10 PM, Konrad Dybcio wrote:
> On 2/17/26 7:43 AM, Umang Chheda wrote:
>> On 2/16/2026 4:44 PM, Konrad Dybcio wrote:
>>> On 2/16/26 9:04 AM, Umang Chheda wrote:
>>>> On 2/12/2026 9:59 PM, Konrad Dybcio wrote:
>>>>> On 2/12/26 4:50 PM, Umang Chheda wrote:
>>>>>> Hi Konrad,
>>>>>>
>>>>>> On 2/12/2026 7:10 PM, Konrad Dybcio wrote:
>>>>>>> On 2/10/26 11:38 AM, Umang Chheda wrote:
>>>>>>>> The Mezzanine is an hardware expansion add-on board designed
>>>>>>> There's normally multiple mezzanine boards (e.g. a "vision mezzanine"),
>>>>>>> is there a better name for it?
>>>>>> Does, Interface Plus (IFP) Mezz sounds good ?
>>>>> I don't know, does it stay Interface Plus on the silkscreen or similar?
>>>> I checked the board - there is nothing written on the silkscreen. Internally we call this board Interface Plus (IFP) mezz.
>>> Let's keep using that name then please
>>
>> Ack, Should I also rename the DTSO filename to "monaco-evk-ifp-mezz.dtso" ? 
> Please do!

Ack

>
> Konrad

Thanks,

Umang

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Bjorn Andersson]

On Mon, Feb 16, 2026 at 01:44:40PM +0530, Umang Chheda wrote:
> Hello Bjorn,
> 
> On 2/13/2026 1:33 AM, Bjorn Andersson wrote:
> > On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
> >> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
> > [..]
> >> +&i2c15 {
> >> +	#address-cells = <1>;
> >> +	#size-cells = <0>;
> > Do we need to repeat this? It's in the top-level i2c15 definition
> > already?
> 
> Yes this is required to be repeated in case of DTSO -- else seeing DT
> binding error if these cells are not added here. Seems the compiler is
> not looking at what is present in the Base DT first and is considering
> the default values for address and size cells and throwing error. Had
> to add similarly add for PCIe node as well to suppress binding errors.
> 

Understood, no concerns then. Thanks for helping me understand.

> >
> >> +
> >> +	status = "okay";
> > I presume this overlay is used on top of monaco-evk.dtb, which already
> > says that status is okay.
> 
> Ack
> 
> >
> >
> > That said, I don't see a "clock-frequency" in either node, so I presume
> > you have an error/warning in your kernel log about this. But unless you
> > have reason to change that in your overlay, I think that's a unrelated
> > patch on the monaco-evk.dts - which I would like you to send, separately.
> 
> 
> Ack, will share a separate patch to fix this issue.
> 
> >
> >> +
> >> +	eeprom1: eeprom@52 {
> >> +		compatible = "giantec,gt24c256c", "atmel,24c256";
> >> +		reg = <0x52>;
> >> +		pagesize = <64>;
> >> +
> >> +		nvmem-layout {
> >> +			compatible = "fixed-layout";
> >> +			#address-cells = <1>;
> >> +			#size-cells = <1>;
> >> +		};
> >> +	};
> >> +};
> >> +
> > [..]
> >> +&tlmm {
> >> +	tc9563_resx_n: tc9563-resx-state {
> >> +		pins = "gpio124";
> >> +		function = "gpio";
> >> +
> >> +		bias-disable;
> >> +		input-disable;
> >> +		output-enable;
> >> +		power-source = <0>;
> > Does these properties really match the TLMM binding? Please double
> > check.
> 
> Double checked on this -- all the properties match the TLMM bindings.
> 

I do believe the logic is binary, so input-disable == output-enable (in
contrast to the SPMI gpio binding, where those two are configured
separately). It's not listed among the valid properties for a
qcom-tlmm-state object, but perhaps I'm misremembering how the
dt-validator uses those properties.

But there's no "power-source" for TLMM, you should see an "Unsupported
config parameter" in the kernel log when you try to apply this setting.

Regards,
Bjorn

> >
> > Regards,
> > Bjorn
> >
> >> +	};
> >> +};
> >> --
> >> 2.34.1
> 
> 
> Thanks,
> Umang
> 

Re: [PATCH 1/1] arm64: dts: qcom: monaco-evk: Add Mezzanine

[Umang Chheda]

On 2/18/2026 2:26 AM, Bjorn Andersson wrote:
> On Mon, Feb 16, 2026 at 01:44:40PM +0530, Umang Chheda wrote:
>> Hello Bjorn,
>>
>> On 2/13/2026 1:33 AM, Bjorn Andersson wrote:
>>> On Tue, Feb 10, 2026 at 04:08:21PM +0530, Umang Chheda wrote:
>>>> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-mezzanine.dtso
>>> [..]
>>>> +&i2c15 {
>>>> +	#address-cells = <1>;
>>>> +	#size-cells = <0>;
>>> Do we need to repeat this? It's in the top-level i2c15 definition
>>> already?
>> Yes this is required to be repeated in case of DTSO -- else seeing DT
>> binding error if these cells are not added here. Seems the compiler is
>> not looking at what is present in the Base DT first and is considering
>> the default values for address and size cells and throwing error. Had
>> to add similarly add for PCIe node as well to suppress binding errors.
>>
> Understood, no concerns then. Thanks for helping me understand.
>
>>>> +
>>>> +	status = "okay";
>>> I presume this overlay is used on top of monaco-evk.dtb, which already
>>> says that status is okay.
>> Ack
>>
>>>
>>> That said, I don't see a "clock-frequency" in either node, so I presume
>>> you have an error/warning in your kernel log about this. But unless you
>>> have reason to change that in your overlay, I think that's a unrelated
>>> patch on the monaco-evk.dts - which I would like you to send, separately.
>>
>> Ack, will share a separate patch to fix this issue.
>>
>>>> +
>>>> +	eeprom1: eeprom@52 {
>>>> +		compatible = "giantec,gt24c256c", "atmel,24c256";
>>>> +		reg = <0x52>;
>>>> +		pagesize = <64>;
>>>> +
>>>> +		nvmem-layout {
>>>> +			compatible = "fixed-layout";
>>>> +			#address-cells = <1>;
>>>> +			#size-cells = <1>;
>>>> +		};
>>>> +	};
>>>> +};
>>>> +
>>> [..]
>>>> +&tlmm {
>>>> +	tc9563_resx_n: tc9563-resx-state {
>>>> +		pins = "gpio124";
>>>> +		function = "gpio";
>>>> +
>>>> +		bias-disable;
>>>> +		input-disable;
>>>> +		output-enable;
>>>> +		power-source = <0>;
>>> Does these properties really match the TLMM binding? Please double
>>> check.
>> Double checked on this -- all the properties match the TLMM bindings.
>>
> I do believe the logic is binary, so input-disable == output-enable (in
> contrast to the SPMI gpio binding, where those two are configured
> separately). It's not listed among the valid properties for a
> qcom-tlmm-state object, but perhaps I'm misremembering how the
> dt-validator uses those properties


Apologize for the earlier comment, I agree it applies for the SPMI GPIO.

I will remove input-disable and output-enable properties and add

output-high which aligns with the bindings.

>
> But there's no "power-source" for TLMM, you should see an "Unsupported
> config parameter" in the kernel log when you try to apply this setting.

Ack, This property is valid only for the SPMI GPIO and not for the TLMM GPIO.

will remove this property.

>
> Regards,
> Bjorn
>
>>> Regards,
>>> Bjorn
>>>
>>>> +	};
>>>> +};
>>>> --
>>>> 2.34.1
>>
>> Thanks,
>> Umang


Thanks,
Umang