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

[Umang Chheda <umang.chheda@oss.qualcomm.com>]

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