Re: [PATCH v2 2/5] arm64: dts: qcom: Add AYN QCS8550 Common

[Konrad Dybcio]

On 3/19/26 11:31 PM, Aaron Kling wrote:
> On Wed, Mar 11, 2026 at 7:49 PM Val Packett <val@xxxxxxxxxxxx> wrote:
>>
>> On 3/11/26 2:44 PM, Aaron Kling wrote:
>>
>>> From: Teguh Sobirin <teguh@xxxxxxxx>
>>>
>>> This adds a base dtb of everything common between the AYN QCS8550
>>> devices. It is intended to be extended by device specific overlays.
>>>
>>> Signed-off-by: Teguh Sobirin <teguh@xxxxxxxx>
>>> Co-developed-by: Aaron Kling <webgeek1234@xxxxxxxxx>
>>> Signed-off-by: Aaron Kling <webgeek1234@xxxxxxxxx>
>>> ---
>>>   arch/arm64/boot/dts/qcom/Makefile                  |    1 +
>>>   arch/arm64/boot/dts/qcom/qcs8550-ayntec-common.dts | 1777 ++++++++++++++++++++
>>>   2 files changed, 1778 insertions(+)
>>> […]
>>> +/ {
>>> +     model = "AYN QCS8550 Common";
>>> +     compatible = "ayntec,qcs8550-common", "qcom,qcs8550", "qcom,sm8550";
>>
>> Huh?.. All existing -common files are .dtsi includes without their own
>> model/compatible, and the compile-time "dtbo" support is only used for
>> EL2 where we want to apply the same thing to many many devices without
>> polluting the tree with extra glue files. I don't see why this should be
>> a "common device" with its own compatible string, and not just a dtsi.
>>
>>> […]
>>> +&gpu {
>>> +     status = "okay";
>>> +
>>> +     zap-shader {
>>> +             firmware-name = "qcom/sm8550/a740_zap.mbn";
>>> +     };
>>> +};
>>
>> Please use the &gpu_zap_shader label.
>>
>> And does the generic zap actually just work?
>>
>>> […]
>>> +&i2c0 {
>>> +     clock-frequency = <400000>;
>>> +     status = "okay";
>>> +};
>>> +
>>> +&i2c4 {
>>> +     clock-frequency = <400000>;
>>> +     status = "okay";
>>> +};
>>> +
>>> +&i2c12 {
>>> +     clock-frequency = <400000>;
>>> +     status = "okay";
>>> +};
>> If the individual devices actually use these busses, better to enable
>> them inside of their .dts as well I think?
>>> +&iris {
>>> +     status = "okay";
>>> +};
>> Works with generic firmware?
>>> […]
>>> +&pcie0 {
>>> +     wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
>>> +     perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
>> Current binding is to put these inside of the &pcieportN (renaming
>> 'perst' to 'reset' which I just noticed I failed to do for one of my own
>> files :D), see x1e78100-lenovo-thinkpad-t14s.dtsi for an example.
> 
> I tried making this change, but the pcie port failed to probe. I also
> notice that all existing sm8550 devices still use the 'old' syntax.

There's a ""feature"" in the parsing code that will only let this work if
both 'phys' and 'xxx-gpios' are under the same node (i.e. both under PCIe
OR both under the root port), I think this may be changed by a single big
change later on

Konrad