Re: [PATCH v12 3/3] arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board

[tessolveupstream@gmail.com]

On 16-01-2026 13:24, Dmitry Baryshkov wrote:
> On Fri, Jan 16, 2026 at 11:25:50AM +0530, tessolveupstream@gmail.com wrote:
>>
>>
>> On 15-01-2026 07:54, Jie Gan wrote:
>>>
>>>
>>> On 1/14/2026 6:00 PM, Sudarshan Shetty wrote:
>>>> Add the device tree for the QCS615-based Talos EVK platform. The
>>>> platform is composed of a System-on-Module following the SMARC
>>>> standard, and a Carrier Board.
>>>>
>>>> The Carrier Board supports several display configurations, HDMI and
>>>> LVDS. Both configurations use the same base hardware, with the display
>>>> selection controlled by a DIP switch.
>>>>
>>>> Use a DTBO file, talos-evk-lvds-auo,g133han01.dtso, which defines an
>>>> overlay that disables HDMI and adds LVDS. The DTs file talos-evk
>>>> can describe the HDMI display configurations.
>>>>
>>>> The initial device tree includes support for:
>>>> - CPU and memory
>>>> - UART
>>>> - GPIOs
>>>> - Regulators
>>>> - PMIC
>>>> - Early console
>>>> - AT24MAC602 EEPROM
>>>> - MCP2515 SPI to CAN
>>>> - ADV7535 DSI-to-HDMI bridge
>>>> - DisplayPort interface
>>>> - SN65DSI84ZXHR DSI-to-LVDS bridge
>>>> - Wi-Fi/BT
>>>>
> 
>>>> +
>>>> +&usb_1 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&usb_1_dwc3 {
>>>> +    dr_mode = "host";
>>>> +};
>>>> +
>>>> +&usb_hsphy_1 {
>>>> +    vdd-supply = <&vreg_l5a>;
>>>> +    vdda-pll-supply = <&vreg_l12a>;
>>>> +    vdda-phy-dpdm-supply = <&vreg_l13a>;
>>>> +
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&usb_2 {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&usb_2_dwc3 {
>>>> +    dr_mode = "host";
>>>> +};
>>>
>>> Both usb devices have been configured to host mode, do we need adb?
>>> The adb only work with usb peripheral mode.
>>>
>>
>> This topic was discussed previously, and the fix was implemented 
>> based on that discussion.
>> For reference, I’m sharing the earlier communication in the 
>> links below.
>>
>> https://lore.kernel.org/all/qq4aak33bn3mqxd2edu6zgkkshby63mmitg7zqkly2rj4c2lh7@4s7sndb7e2jr/T/#meaa464a4e6992b36b5d8d41ddc691ee4ea36b1ce
>>
>> https://lore.kernel.org/all/20251014120223.1914790-1-tessolveupstream@gmail.com/T/#t
> 
> Neither of these links is relevant to the question.
> 

In our hardware design, the USB0 controller is a USB 3.0-capable 
controller whose high‑speed (HS) differential lines are routed through 
a mechanical switch.

a) During EDL (flashing) mode:
   The HS lines are explicitly routed to the Micro‑USB port. 
   This allows the SoC to enter "device mode" for firmware flashing.

b) After EDL completes (normal operation):
   The mechanical switch is driven to route the HS signals to the on‑
   board USB 3.0 hub.
   The hub connects to four Type-A ports, all designed for host mode 
   only.
   The Micro-USB connector is now electrically disconnected.

Why host-only mode: Once the switch routes to the hub, there's no 
electrical path back to the Micro-USB port. The USB controller can 
only talk to the hub and its downstream Type-A ports, which are wired 
for host mode only. Device mode is physically impossible in this 
configuration.
Therefore, USB0 must be configured as host-only in the device tree, 
since device mode cannot work after the system boots.
 
The USB1 controller supports USB 2.0 and has its data lines directly 
routed to a Type-A connector. This hardware design restricts the 
controller to host-only operation, preventing any peripheral/device 
mode functionality.
>