Re: [PATCH v2 2/2] arm64: dts: qcom: eliza-evk: Add PCIe1 with TC9563 PCIe switch

[Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>]

On 7/21/2026 11:52 AM, Manivannan Sadhasivam wrote:
> On Tue, Jul 21, 2026 at 10:56:20AM +0530, Krishna Chaitanya Chundru wrote:
>>
>> On 7/9/2026 6:37 PM, Manivannan Sadhasivam wrote:
>>> On Wed, Jul 08, 2026 at 11:47:17AM +0530, Krishna Chaitanya Chundru wrote:
>>>> The Eliza EVK board connects PCIe1 (8GT/s x2) to a Toshiba TC9563
>>>> PCIe switch. Enable PCIe1 and its QMP PHY nodes.
>>>>
>>>> TC9563 uses I2C (at address 0x77 on I2C4) for its management interface.
>>>>
>>>> Override the base iommu-map with the expanded set covering all the
>>>> switch's downstream ports (0x1400-0x1408 SID range).
>>>>
>>>> The TC9563 RESX# and PERST# are OR-ed internally to assert reset on the
>>>> switch. Use TC9563 RESX# pin via a TLMM GPIO and skip wiring PERST#
>>>> from the PCIe controller.
>>>>
>>>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/eliza-evk.dtsi | 112 ++++++++++++++++++++++++++++++++
>>>>  arch/arm64/boot/dts/qcom/eliza.dtsi     |   1 +
>>>>  2 files changed, 113 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/eliza-evk.dtsi b/arch/arm64/boot/dts/qcom/eliza-evk.dtsi
>>>> index 6d76715ccffb..e099b7c8c371 100644
>>>> --- a/arch/arm64/boot/dts/qcom/eliza-evk.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/eliza-evk.dtsi
>>>> @@ -12,6 +12,26 @@ chosen {
>>>>  		stdout-path = "serial0:115200n8";
>>>>  	};
>>>>  
>>>> +	vreg_0p9: regulator-0v9 {
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "VREG_0P9";
>>>> +
>>>> +		regulator-min-microvolt = <900000>;
>>>> +		regulator-max-microvolt = <900000>;
>>>> +		regulator-always-on;
>>>> +		regulator-boot-on;
>>>> +	};
>>>> +
>>>> +	vreg_1p8: regulator-1v8 {
>>>> +		compatible = "regulator-fixed";
>>>> +		regulator-name = "VREG_1P8";
>>>> +
>>>> +		regulator-min-microvolt = <1800000>;
>>>> +		regulator-max-microvolt = <1800000>;
>>>> +		regulator-always-on;
>>>> +		regulator-boot-on;
>>>> +	};
>>>> +
>>>>  	vreg_pcie_m_3p3: regulator-3p3 {
>>>>  		compatible = "regulator-fixed";
>>>>  
>>>> @@ -99,6 +119,98 @@ pcieport0_ep: endpoint {
>>>>  	};
>>>>  };
>>>>  
>>>> +&pcie1 {
>>>> +	iommu-map = <0x0 &apps_smmu 0x1400 0x1>,
>>>> +		    <0x100 &apps_smmu 0x1401 0x1>,
>>>> +		    <0x208 &apps_smmu 0x1402 0x1>,
>>>> +		    <0x210 &apps_smmu 0x1403 0x1>,
>>>> +		    <0x218 &apps_smmu 0x1404 0x1>,
>>>> +		    <0x300 &apps_smmu 0x1405 0x1>,
>>>> +		    <0x400 &apps_smmu 0x1406 0x1>,
>>>> +		    <0x500 &apps_smmu 0x1407 0x1>,
>>>> +		    <0x501 &apps_smmu 0x1408 0x1>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&pcie1_phy {
>>>> +	vdda-phy-supply = <&vreg_l1k>;
>>>> +	vdda-pll-supply = <&vreg_l3k>;
>>>> +
>>>> +	status = "okay";
>>>> +};
>>>> +
>>>> +&pcie1port0 {
>>>> +	wake-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>;
>>> No reset-gpios?
>> RESX & PERST are ORed in this platform, as we can declare at only
>> one place we declared it in the tc9563 node as resx-gpios
>>
> So this means, if both are defined, the assert/deassert sequence causes issue?
> If so, this should be mentioned in the comment here.
we can't claim the same gpio in two different drivers. the probe of the driver
probing
2nd will fail as the gpio is already requested by the first driver.

I will update the commit text while re-spining.

- Krishna Chaitanya.
>
> - Mani
>