Re: [PATCH v5 2/3] arm64: dts: qcom: Introduce sa8255p SoC

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/17/26 12:58 AM, Deepti Jaggi wrote:
> 
> On 3/11/2026 6:41 AM, Konrad Dybcio wrote:
>> On 3/5/26 5:28 AM, Deepti Jaggi wrote:
>>> From: Nikunj Kela <quic_nkela@quicinc.com>
>>>
>>> Introduce base device tree support for sa8255p Qualcomm's automotive
>>> infotainment SoC. The base dt file describes core SoC components- CPUs,
>>> CPU map, ipcc, QUP,  geni UART, interrupt controller, TLMM, reserved
>>> memory, SMMU, firmware scm, scmi, watchdog, SRAM, PSCI, ufs, pcie, pmu
>>> nodes and enable booting to shell with ramdisk.
>>>
>>> The Qualcomm automotive sa8255p SoC utilizes firmware to configure
>>> platform resources such as clocks, interconnects, and TLMM. Device drivers
>>> request these resources through the SCMI power,reset and performance
>>> protocols. Assign each device driver a dedicated SCMI channel and Tx/Rx
>>> doorbells to support parallel resource requests and aggregation in the
>>> SCMI platform server. Operate the SCMI server stack in an SMP-enabled VM,
>>> using the Qualcomm SMC/HVC transport driver for communication.
>>>
>>> Group resource operations to improve abstraction and reduce the number of
>>> SCMI requests. Follow the SCMI-based resource management approach
>>> demonstrated by Qualcomm at LinaroConnect 2024.[1]
>>>
>>> Limit initial support to basic platform resources, serial console, ufs
>>> and pcie.Defer enabling USB, and Ethernet to subsequent updates.
>>>
>>> [1]: https://resources.linaro.org/en/resource/wfnfEwBhRjLV1PEAJoDDte
>>>
>>> Co-developed-by: Shazad Hussain <shazad.hussain@oss.qualcomm.com>
>>> Signed-off-by: Shazad Hussain <shazad.hussain@oss.qualcomm.com>
>>> Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
>>> Co-developed-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>> Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
>>> ---
>> [...]
> 
> Thanks for reviewing the series .
> 
>>> +		tsens2: thermal-sensor@c251000 {
>>> +			compatible = "qcom,sa8255p-tsens", "qcom,tsens-v2";
>>> +			reg = <0x0 0x0c251000 0x0 0x1ff>,
>>> +			      <0x0 0x0c224000 0x0 0x8>;
>> All TSENS regions are 0x1000-long
>>
>> [...]
> 
> Ack
> 
>>
>>> +		tlmm: pinctrl@f000000 {
>>> +			compatible = "qcom,sa8255p-tlmm", "qcom,sa8775p-tlmm";
>>> +			reg = <0x0 0x0f000000 0x0 0x1000000>;
>>> +			interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
>>> +			gpio-controller;
>>> +			#gpio-cells = <2>;
>>> +			interrupt-controller;
>>> +			#interrupt-cells = <2>;
>>> +			gpio-ranges = <&tlmm 0 0 149>;
>>> +			wakeup-parent = <&pdc>;
>>> +		};
>> Praveen suggested GPIOs are not controlled by Linux:
>>
>> https://lore.kernel.org/linux-arm-msm/12063990-70fe-4faf-89fa-c74c7bd97f42@oss.qualcomm.com/
>>
>> Could you comment on this?
>>
>> [...]
> 
> For buses,FW is handling, but for PCIe and ethernet , pin configuration is controlled by Linux.

Okay, does the firmware synchronize/access-control access based on the
pin index, so that e.g. the gpioset utility won't be able to mess with
the desired state? Or do we need something like gpio-reserved-ranges for
the FW-managed ones?

Konrad