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

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

 



On 04.11.24 05:31, Krishna Kurapati wrote:


On 11/1/2024 11:56 PM, Jens Glathe via B4 Relay wrote:
From: Jens Glathe <jens.glathe@xxxxxxxxxxxxxxxxxxxxxx>

Device tree for the Microsoft Windows Dev Kit 2023. This work
is based on the initial work of Merck Hung <merckhung@xxxxxxxxx>.

Original work:
https://github.com/merckhung/linux_ms_dev_kit/blob/ms-dev-kit-2023-v6.3.0/arch/arm64/boot/dts/qcom/sc8280xp-microsoft-dev-kit-2023.dts

The Windows Dev Kit 2023 is a nice little desktop based on sc8280xp.
Link: https://learn.microsoft.com/en-us/windows/arm/dev-kit/

Supported features:
- USB type-c and type-a ports
- minidp connector
- built-in r8152 Ethernet adapter
- PCIe devices
- nvme
- ath11k WiFi (WCN6855)
- WCN6855 Bluetooth
- A690 GPU
- ADSP and CDSP
- GPIO keys
- Audio definition (works via USB)

Signed-off-by: Jens Glathe <jens.glathe@xxxxxxxxxxxxxxxxxxxxxx>
---

[...]

+&usb_2 {
+    pinctrl-0 = <&usb2_en_state>;
+    pinctrl-names = "default";
+

On the blackrock platform, for this controller, are there all 4 ports
given out for use or only one ?

Because if all 4 are there, you might need to give all 4 pinctrls (one
for each TS3USB221A mux select) here for usb_2 node. If only one port
is given out for use on the platform, then only one phy (of the 4
activated below) needs to be marked as active.

In my case, in [1] on the ADP platform, I marked them as always on for
all gpios on multiport controller since driver had no support added yet.

[1]:
https://lore.kernel.org/all/20240707085624.3411961-1-quic_kriskura@xxxxxxxxxxx/

Hi Krishna,

thank you for the hints. Unfortunately, I don't have any schematics for
the box. But I tested out activation combinations for all the
usb_2_hsphy and usb_2_qmpphy listed. All of these are also listed in the
usb_2 node in sc8280xp.dtsi. And they all need to be activated to get
the whole usb_2 node up. Leaving out one lets the whole node vanish.
Maybe it is possible to define fewer phys in the usb_2_dwc3 node, I
don't know. The definition as it is now appears to be a safe bet.
What I noticed in the tests was that the pinctrl usb2_en_state had no
effect here. Although, it apparently was required when it was introduced
[1] by Merck Hung and xlazom00@xxxxxxxxx. Therefore I am hesitant to
remove it. Also, there may be a hint that it is the enable pin of a hub:

$lsusb -tv
[...]
/:  Bus 005.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/4p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 045e:0c5f Microsoft Corp.
/:  Bus 006.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/2p, 10000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
    |__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 10000M
        ID 045e:0c60 Microsoft Corp.
        |__ Port 001: Dev 003, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M
            ID 045e:0c5e Microsoft Corp.

For the IDs 045e:0c5e..045e:c60 there isnot much info, only that its
usually a 10/100/1000 r8152 ethernet adapter, and a USB3.2 /USB2.1 4
port hub. How this is wired, though, no idea. In the face of this I
would suggest to keep the definition as it is now.

[1]:
https://github.com/linux-surface/surface-pro-x/issues/43#issuecomment-1536848253

+    status = "okay";
+};
+
+&usb_2_hsphy0 {
+    vdda-pll-supply = <&vreg_l1b>;
+    vdda18-supply = <&vreg_l1c>;
+    vdda33-supply = <&vreg_l7d>;
+
+    status = "okay";
+};
+
+&usb_2_hsphy1 {
+    vdda-pll-supply = <&vreg_l8d>;
+    vdda18-supply = <&vreg_l1c>;
+    vdda33-supply = <&vreg_l7d>;
+
+    status = "okay";
+};
+
+&usb_2_hsphy2 {
+    vdda-pll-supply = <&vreg_l10d>;
+    vdda18-supply = <&vreg_l8c>;
+    vdda33-supply = <&vreg_l2d>;
+
+    status = "okay";
+};
+
+&usb_2_hsphy3 {
+    vdda-pll-supply = <&vreg_l10d>;
+    vdda18-supply = <&vreg_l8c>;
+    vdda33-supply = <&vreg_l2d>;
+
+    status = "okay";
+};
+
+&usb_2_qmpphy0 {
+    vdda-phy-supply = <&vreg_l1b>;
+    vdda-pll-supply = <&vreg_l4d>;
+
+    status = "okay";
+};
+
+&usb_2_qmpphy1 {
+    vdda-phy-supply = <&vreg_l8d>;
+    vdda-pll-supply = <&vreg_l4d>;
+
+    status = "okay";
+};
+

[...]

+    usb2_en_state: usb2-en-state {
+        /* TS3USB221A USB2.0 mux select */
+        pins = "gpio24";
+        function = "gpio";
+        drive-strength = <2>;
+        bias-disable;
+        output-low;
+    };
+

Regards,
Krishna,





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux