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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux