On 11/6/2024 12:57 AM, Jens Glathe wrote:
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
My point is little different.
Third controller supports upto 4 physical ports. How many of them have
been exposed on this WDK2023 ? Depending on that, the phys have to be
enabled in DT.
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.
Regards,
Krishna,
