Re: [PATCH v5 3/3] arm64: dts: qcom: sc8280xp-blackrock: dt definition for WDK2023

[Jens Glathe]

On 30.10.24 08:36, Johan Hovold wrote:
> On Wed, Oct 30, 2024 at 08:09:21AM +0100, Jens Glathe via B4 Relay wrote:
>
> > +&pcie2a {
> > +	aspm-no-l0s;
> There is no such property in the binding (or driver) and L0s is disabled
> for all controllers on sc8280xp.
>
> (I think I used a property like this in an early version of the patches
> that ultimately disabled L0s however).

will remove (all of them)

> > +	max-link-speed = <16>;
> That's pretty fast. And not supported as this would indicate PCIe
> Gen16...

oh oops. Future-oriented ;) Will change to <4>

> > +
> > +	perst-gpios = <&tlmm 143 GPIO_ACTIVE_LOW>;
> > +	wake-gpios = <&tlmm 145 GPIO_ACTIVE_LOW>;
> > +
> > +	vddpe-3v3-supply = <&vreg_nvme>;
> > +	vdda-supply = <&vreg_l7d>;
> > +
> > +	pinctrl-0 = <&pcie2a_default>;
> > +	pinctrl-names = "default";
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie2a_phy {
> > +	vdda-phy-supply = <&vreg_l4d>;
> > +	vdda-pll-supply = <&vreg_l6d>;
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie4 {
> > +	aspm-no-l0s;
> As above.
>
> > +	max-link-speed = <2>;
> > +
> > +	perst-gpios = <&tlmm 141 GPIO_ACTIVE_LOW>;
> > +	wake-gpios = <&tlmm 139 GPIO_ACTIVE_LOW>;
> > +
> > +	vddpe-3v3-supply = <&vreg_wlan>;
> > +	vdda-supply = <&vreg_l7d>;
> > +
> > +	pinctrl-0 = <&pcie4_default>;
> > +	pinctrl-names = "default";
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie4_port0 {
> > +	wifi@0 {
> > +		compatible = "pci17cb,1103";
> > +		reg = <0x10000 0x0 0x0 0x0 0x0>;
> > +
> > +		vddrfacmn-supply = <&vreg_pmu_rfa_cmn_0p8>;
> > +		vddaon-supply = <&vreg_pmu_aon_0p8>;
> > +		vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
> > +		vddwlmx-supply = <&vreg_pmu_wlmx_0p8>;
> > +		vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
> > +		vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
> > +		vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
> > +		vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
> > +		vddrfa1p8-supply = <&vreg_pmu_rfa_1p7>;
> > +
> > +		qcom,ath11k-calibration-variant = "volterra";
> IIRC the other calibration variants use all upper case here. And is
> Volterra sufficient? No vendor prefix or similar needed?

Yes they are of the pattern VV_Mmmmm

V = Vendor (uppercase)

M = Model (Model name mixed case, no pattern visible)

> I think you need to get this acked by the ath11k maintainer (Kalle Valo)
> first.

I will cc him.

The current (?) behaviour of the ath11k driver is that when a board
string with a variant is not found, it will search again without the
variant and take the one it finds. So it will work with degraded
performance, but it will work.

> > +	};
> > +};
> > +&remoteproc_adsp {
> > +	firmware-name = "qcom/sc8280xp/microsoft/blackrock/qcadsp8280.mbn";
> Shouldn't these paths reflect the DMI values as on the X13s?

Will check. Names were changed in the last iterations of the patch.

dmidecode says:

Handle 0x0009, DMI type 1, 27 bytes
System Information
    Manufacturer: Microsoft Corporation
    Product Name: Windows Dev Kit 2023
    Version: 124I:00097T:000M:0200000B:07
    Serial Number: 0F01C4F22373F6
    UUID: e4a4662c-8367-75d0-a54f-1d04bd404860
    Wake-up Type: Unknown
    SKU Number: 2043
    Family: Surface

> > +&usb_0_hsphy {
> > +	vdda-pll-supply = <&vreg_l9d>;
> > +	vdda-phy-supply = <&vreg_l4d>;
> The binding does not include a vdda-phy supply (same for the other HS
> PHYs).
>
> Where did this come from?

From my "research" on the ic block diagram where they were defined
(outer and inner block). Will remove to X13s levels.

with best regards

Jens

> > +	vdda18-supply = <&vreg_l1c>;
> > +	vdda33-supply = <&vreg_l7d>;
> > +
> > +	status = "okay";
> > +};
> Johan