[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <wbg34hghu4gl277ppitctxgs5swlchjyjk425cjf4sbojlymlj@ca62bvncptny>
Date: Wed, 15 Oct 2025 01:15:50 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Sudarshan Shetty <tessolveupstream@...il.com>
Cc: andersson@...nel.org, konradybcio@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/2] arm64: dts: qcom: Add support for QCS615 talos
evk board
On Tue, Oct 14, 2025 at 05:32:23PM +0530, Sudarshan Shetty wrote:
> Introduce the device tree support for the QCS615-based talos-evk
> platform, which follows the SMARC (Smart Mobility ARChitecture)
> standard. The platform is composed of two main hardware
> components: the talos-evk-som and the talos-evk carrier board.
>
> The talos-evk-som is a compact System on Module that integrates the
> QCS615 SoC, PMIC, and essential GPIO connectivity. It follows the
> SMARC standard, which defines a modular form factor allowing the SoM
> to be paired with different carrier boards for varied applications.
>
> The talos-evk is one such carrier board, designed for evaluation
> and development purposes. It provides additional peripherals
> such as UART, USB, and other interfaces to enable rapid
> prototyping and hardware bring-up.
>
> This initial device tree provides the basic configuration needed
> to boot the platform to a UART shell. Further patches will extend
> support for additional peripherals and subsystems.
>
> The initial device tree includes basic support for:
>
> - CPU and memory
>
> - UART
>
> - GPIOs
>
> - Regulators
>
> - PMIC
>
> - Early console
>
> - AT24MAC602 EEPROM
>
> - MCP2515 SPI to CAN
>
> QCS615 talos-evk uses a Quectel AF68E WiFi/BT module (PCIe for
> WiFi and UART for Bluetooth), which is different from the RIDE
> platform. Plan to enable these in a follow-up patch series.
>
> Signed-off-by: Sudarshan Shetty <tessolveupstream@...il.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/talos-evk-som.dtsi | 435 ++++++++++++++++++++
> arch/arm64/boot/dts/qcom/talos-evk.dts | 42 ++
> 3 files changed, 478 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/talos-evk-som.dtsi
> create mode 100644 arch/arm64/boot/dts/qcom/talos-evk.dts
>
> +
> + extcon_usb_1: extcon-usb-1 {
> + compatible = "linux,extcon-usb-gpio";
> + vbus-gpio = <&pm8150_gpios 6 GPIO_ACTIVE_HIGH>;
> + id-gpio = <&pm8150_gpios 7 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&usb1_vbus_det_default &usb1_id_det_default>;
> + pinctrl-names = "default";
> + };
Given that we are trying to switch to flattened DWC3 nodes and we are
not going to support extcon in such a configuration (commit aeb0169217eb
("usb: dwc3: qcom: Remove extcon functionality from glue layer")), I
don't think this is a way to go. Please add a proper
gpio-usb-b-connector node.
Also... This is not correct if SW1 is switched to the USB-Host. The ID
is still connected to the micro-USB port and so it might generate some
unpredicted interference. Unfortunately, DT isn't well-fitting for
describing board options and SW1 is definitely an SoM option. Depending
on its position the EVK should either use this gpio-usb-b-connector or
an onboard USB hub (which ideally should also be described in DT). So,
it feels like you need two different DT files, one for each SW1
position.
> +
> +&pm8150_gpios {
> + usb2_en: usb2-en-state {
> + pins = "gpio10";
> + function = "normal";
> + output-enable;
> + power-source = <0>;
> + };
> +
> + usb1_vbus_det_default: usb1-vbus-det-default-state {
> + pins = "gpio6";
> + function = "normal";
> + output-enable;
> + power-source = <0>;
> + };
> +
> + usb1_id_det_default: usb1-id-det-default-state {
> + pins = "gpio7";
> + function = "normal";
> + output-enable;
> + power-source = <0>;
> + };
Do you want to also describe gpio8 here?
> +};
> +
[...]
> +&usb_1_hsphy {
> + vdd-supply = <&vreg_l5a>;
> + vdda-pll-supply = <&vreg_l12a>;
> + vdda-phy-dpdm-supply = <&vreg_l13a>;
> +
> + status = "okay";
> +};
> +
> +&usb_qmpphy {
> + vdda-phy-supply = <&vreg_l5a>;
> + vdda-pll-supply = <&vreg_l12a>;
> +
> + status = "okay";
> +};
> +
> +&usb_1 {
> + status = "okay";
> +};
> +
> +/*
> + * USB1 port supports both host and device modes.
> + * By default, it operates in device mode.
> + * To enable host mode, set switch SW1 to 'ON' position on the SoM.
Is it device mode or is it an OTG mode? I don't have carrier board
schematics, so I don't see if it is possible to enable VBUS on the
micro-USB or not.
> + */
> +
> +&usb_1_dwc3 {
> + dr_mode = "otg";
JFYI: it's a default and can be omitted. Only host / peripheral needs to
be specified explicitly.
> + extcon = <&extcon_usb_1>;
> +};
> +
--
With best wishes
Dmitry
Powered by blists - more mailing lists