Stephan Gerhold [Mon, 15 Sep 2025 13:28:31 +0000 (15:28 +0200)]
arm64: dts: qcom: msm8939: Add missing MDSS reset
On most MSM8939 devices, the bootloader already initializes the display to
show the boot splash screen. In this situation, MDSS is already configured
and left running when starting Linux. To avoid side effects from the
bootloader configuration, the MDSS reset can be specified in the device
tree to start again with a clean hardware state.
The reset for MDSS is currently missing in msm8939.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:
It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.
Stephan Gerhold [Mon, 15 Sep 2025 13:28:30 +0000 (15:28 +0200)]
arm64: dts: qcom: msm8916: Add missing MDSS reset
On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader
already initializes the display to show the boot splash screen. In this
situation, MDSS is already configured and left running when starting Linux.
To avoid side effects from the bootloader configuration, the MDSS reset can
be specified in the device tree to start again with a clean hardware state.
The reset for MDSS is currently missing in msm8916.dtsi, which causes
errors when the MDSS driver tries to re-initialize the registers:
It turns out that we have always indirectly worked around this by building
the MDSS driver as a module. Before v6.17, the power domain was temporarily
turned off until the module was loaded, long enough to clear the register
contents. In v6.17, power domains are not turned off during boot until
sync_state() happens, so this is no longer working. Even before v6.17 this
resulted in broken behavior, but notably only when the MDSS driver was
built-in instead of a module.
arm64: dts: qcom: qcm6490: Introduce the Particle Tachyon
The Particle Tachyon is a single board computer with 5G connectivity
with AI accelerator, based on the Qualcomm QCM6490 platform.
Introduce the board, with support for UFS, USB, USB Type-C PD and
altmode (DisplayPort), GPU, charger/battery status, PCIe shield,
SD-card, and remoteprocs.
Enable the QCA8081 2.5G Ethernet PHY on port 0. Add MDC and MDIO pin
functions for ethernet0, and enable the internal SGMII/SerDes PHY node.
Additionally, support fetching the MAC address from EEPROM via an nvmem
cell.
arm64: dts: qcom: lemans-evk: Enable first USB controller in device mode
Enable the first USB controller in device mode on the Lemans EVK
board and configure the associated LDO regulators to power
the PHYs accordingly.
The USB port is a Type-C port controlled by HD3SS3320 port controller.
The role switch notifications would need to be routed to glue driver by
adding an appropriate usb-c-connector node in DT. However in the design,
the vbus supply that is to be provided to connected peripherals when
port is configured as an DFP, is controlled by a GPIO.
There is also one ID line going from Port controller chip to GPIO-50 of
the SoC. As per the datasheet of HD3SS3320:
"Upon detecting a UFP device, HD3SS3220 will keep ID pin high if VBUS is
not at VSafe0V. Once VBUS is at VSafe0V, the HD3SS3220 will assert ID
pin low. This is done to enforce Type-C requirement that VBUS must be
at VSafe0V before re-enabling VBUS."
The current HD3SS3220 driver doesn't have this functionality present. So,
putting the first USB controller in device mode for now. Once the vbus
control based on ID pin is implemented in hd3ss3220.c, the
usb-c-connector will be implemented and dr mode would be made OTG.
arm64: dts: qcom: lemans-evk: Enable Iris video codec support
Enable the Iris video codec accelerator on the Lemans EVK board
and reference the appropriate firmware required for its operation.
This allows hardware-accelerated video encoding and decoding using
the Iris codec engine.
arm64: dts: qcom: lemans-evk: Add EEPROM and nvmem layout
Integrate the GT24C256C EEPROM via I2C to enable access to
board-specific non-volatile data.
Also, define an nvmem-layout to expose structured regions within the
EEPROM, allowing consumers to retrieve configuration data such as
Ethernet MAC addresses via the nvmem subsystem.
arm64: dts: qcom: lemans-evk: Enable GPI DMA and QUPv3 controllers
Enable GPI DMA controllers (gpi_dma0, gpi_dma1, gpi_dma2) and QUPv3
interfaces (qupv3_id_0, qupv3_id_2) in the device tree to support
DMA and peripheral communication on the Lemans EVK platform.
qupv3_id_0 provides access to I2C/SPI/UART instances 0-5.
qupv3_id_2 provides access to I2C/SPI/UART instances 14-20.
Introduce the SDHC v5 controller node for the Lemans platform.
This controller supports either eMMC or SD-card, but only one
can be active at a time. SD-card is the preferred configuration
on Lemans targets, so describe this controller.
Define the SDC interface pins including clk, cmd, and data lines
to enable proper communication with the SDHC controller.
Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Co-developed-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-1-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8650: Drop redundant status from PMK8550 RTC
The PMK8550 RTC is always enabled in its DTSI file since
commit a791fc19965e ("arm64: dts: qcom: pmk8550: always enable RTC PMIC
device"), so drop redundant status=okay in SM8650 boards.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250908085331.56478-2-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Eric Gonçalves [Fri, 5 Sep 2025 19:09:29 +0000 (19:09 +0000)]
arm64: dts: qcom: sm8250-samsung-r8q: Move common parts to dtsi
Move common parts of the device tree to a separate dtsi in preparation for
adding other Samsung devices from the S20, Tab S7 or Note 20 families,
creating sm8250-samsung-common.dtsi. Also add support for UFS, USB and
GPIO keys.
Add the sound card node with tested playback over max98357a
I2S speakers amplifier and I2S mic.
Introduce HS (High-Speed) MI2S pin control support.
The I2S max98357a speaker amplifier is connected via HS0 and I2S
microphones utilize the HS2 interface.
Renjiang Han [Tue, 26 Aug 2025 10:53:38 +0000 (16:23 +0530)]
arm64: dts: qcom: sm6150: add venus node to devicetree
Add the venus node to the devicetree for the sm6150 platform to enable
video functionality. The sm6150 platform currently lacks video
functionality due to the absence of the venus node. Fallback to sc7180 due
to the same video core.
Unfortunately, the rfkill pin is triggered by default, so a workaround
is needed to convince the Linux driver to enable the hw, after which it
works just fine.
Add the sound card for monaco-evk board and verified playback
functionality using the max98357a I2S speaker amplifier and I2S
microphones. The max98357a speaker amplifier is connected via
High-Speed MI2S HS0 interface, while the microphones utilize the
Secondary MI2S interface and also enable required pin controller
gpios for audio.
Monaco EVK is a single board computer, based on the Qualcomm
QCS8300 SoC, with the following features :
- Storage: 1 × 128 GB UFS, micro-SD card, EEPROMs for MACs,
and eMMC.
- Audio/Video, Camera & Display ports.
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD.
- PCIe ports.
- USB & UART ports.
On top of Monaco EVK board additional mezzanine boards can be
stacked in future.
Add support for the following components :
- GPI (Generic Peripheral Interface) and QUPv3-0/1
controllers to facilitate DMA and peripheral communication.
- TCA9534 I/O expander via I2C to provide 8 additional GPIO
lines for extended I/O functionality.
- USB1 controller in device mode to support USB peripheral
operations. USB OTG mode will be enabled for USB1 controller
once the VBUS control based on ID pin is implemented in
hd3ss3220.c.
- Remoteproc subsystems for supported DSPs such as Audio DSP,
Compute DSP and Generic DSP, along with their corresponding
firmware.
- Configure nvmem-layout on the I2C EEPROM to store data for Ethernet
and other consumers.
- QCA8081 2.5G Ethernet PHY on port-0 and expose the
Ethernet MAC address via nvmem for network configuration.
It depends on CONFIG_QCA808X_PHY to use QCA8081 PHY.
- Support for the Iris video codec.
Written with inputs from :
Rakesh Kota <rakesh.kota@oss.qualcomm.com> - Regulators.
Nirmesh Kumar Singh <nirmesh.Singh@oss.qualcomm.com> - GPIO expander.
Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> - GPI/QUP.
Mohd Ayaan Anwar <quic_mohdayaa@quicinc.com> - Ethernet.
Monish Chunara <quic_mchunara@quicinc.com> - EEPROM.
Vikash Garodia <quic_vgarodia@quicinc.com> - Iris Video codec.
Swati Agarwal <swati.agarwal@oss.qualcomm.com> - USB.
Enable LPASS macros (WSA, VA, RX, TX) and the lpass_tlmm clock required
for audioreach functionality. In audioreach solution mclk, npl, and fsgen
clocks are managed via the Q6PRM. On SC7280-based boards, the TX CORE
clock is used to drive both RX and WSA audio paths following as per
hardware design.
arm64: dts: qcom: qcs6490-audioreach: Add AudioReach support for QCS6490
Introduce qcs6490-audioreach.dtsi to support AudioReach architecture on
QCS6490 platforms. The existing ADSP Bypass DTSI files such as sc7280.dtsi,
which is tailored for ADSP Bypass architecture as they lack DSP-specific
nodes required for AudioReach. The new qcs6490-audioreach.dtsi file defines
nodes for AudioReach specific components such as APM (Audio Process
Manager), PRM (Proxy Resource Manager), and GPR (Generic Packet Router).
This change enable the audio from the legacy ADSP Bypass solution to
the AudioReach framework.
arm64: dts: qcom: ipq5424: Add reserved memory for TF-A
IPQ5424 supports both TZ and TF-A as secure software options and various
DDR sizes. In most cases, TF-A or TZ is loaded at the same memory
location, but in the 256MB DDR configuration TF-A is loaded at a different
region.
So, add the reserved memory node for TF-A and keep it disabled by default.
During bootup, U-Boot will detect which secure software is running and
enable or disable the node accordingly.
Konrad Dybcio [Tue, 12 Aug 2025 10:48:15 +0000 (12:48 +0200)]
arm64: dts: qcom: sc7180: Describe on-SoC USB-adjacent data paths
USB connector bindings describe a ports subnode, which describes how
its High-/SuperSpeed data lines (as well as the SBU pins for Type-C)
are connected.
On Linux, skipping the graph results in the 'connect_type' sysfs
attribute returning 'unknown', instead of 'hotplug' or similar. This in
turn is parsed by some operating systems (such as CrOS), to e.g. make
security policy decisions.
Define ports {} for the DWC controller & the QMPPHY and connect them
together for the SS lanes.
Leave the DP endpoint unconnected for now, as both Aspire 1 and the
Chromebooks (unmerged, see [1]) seem to have a non-trivial topology.
Take the creative liberty to add a newline before its ports' subnodes
though.
The Laptop is a Snapdragon X1 / X1 Plus (Purwa) based device [1].
Supported features:
- USB type-c and type-a ports
- Keyboard
- Touchpad (all that are described in the dsdt)
- Touchscreen (described in the dsdt, no known SKUss)
- Display including PWM backlight control
- PCIe devices
- nvme
- SDHC card reader
- ath12k WCN7850 Wifi and Bluetooth
- ADSP and CDSP
- GPIO keys (Lid switch)
- Sound via internal speakers / DMIC / USB / headphone jack
- DP Altmode with 2 lanes (as all of these still do)
- Integrated fingerprint reader (FPC)
- Integrated UVC camera
- X1-45 GPU
Not supported yet:
- HDMI port.
- EC and some fn hotkeys.
Limited support yet:
- SDHC card reader is based on the on-chip sdhc_2 controller, but the driver from
the Snapdragon Dev Kit is only a partial match. It can do normal slow sd cards,
but not UHS-I (SD104) and UHS-II.
This work was done without any schematics or non-public knowledge of the device.
So, it is based on the existing x1e device trees, dsdt analysis, using HWInfo
ARM64, and pure guesswork. It has been confirmed, however, that the device really
has 4 NXP PTN3222 eUSB2 repeaters, one of which doesn't have a reset GPIO (eusb5
@43).
Co-developed-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Signed-off-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250822-tb16-dt-v12-3-bab6c2986351@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:29:01 +0000 (11:29 +0200)]
arm64: dts: qcom: x1e80100-qcp: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Stephan Gerhold [Fri, 22 Aug 2025 09:29:00 +0000 (11:29 +0200)]
arm64: dts: qcom: x1e80100-microsoft-romulus: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: 09d77be56093 ("arm64: dts: qcom: Add support for X1-based Surface Laptop 7 devices") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-9-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:59 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Stephan Gerhold [Fri, 22 Aug 2025 09:28:58 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e80100-hp-omnibook-x14: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: 6f18b8d4142c ("arm64: dts: qcom: x1e80100-hp-x14: dt for HP Omnibook X Laptop 14") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-7-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:57 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e80100-dell-xps13-9345: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: f5b788d0e8cd ("arm64: dts: qcom: Add support for X1-based Dell XPS 13 9345") Tested-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> # 3K OLED Reviewed-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-6-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:56 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e80100-asus-vivobook-s15: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: d0e2f8f62dff ("arm64: dts: qcom: Add device tree for ASUS Vivobook S 15") Tested-by: Maud Spierings <maud_spierings@hotmail.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-5-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:55 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: 7d1cbe2f4985 ("arm64: dts: qcom: Add X1E78100 ThinkPad T14s Gen 6") Tested-by: Christopher Obbard <christopher.obbard@linaro.org> Reviewed-by: Christopher Obbard <christopher.obbard@linaro.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Lenovo Thinkpad T14s OLED Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-4-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:54 +0000 (11:28 +0200)]
arm64: dts: qcom: x1-crd: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Stephan Gerhold [Fri, 22 Aug 2025 09:28:53 +0000 (11:28 +0200)]
arm64: dts: qcom: x1-asus-zenbook-a14: Add missing pinctrl for eDP HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Fix this by adding the missing pinctrl for gpio119 (func1/edp0_hot and
bias-disable according to the ACPI DSDT), which is defined as
&edp0_hpd_default template in x1e80100.dtsi.
Fixes: 6516961352a1 ("arm64: dts: qcom: Add support for X1-based Asus Zenbook A14") Tested-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> # FHD OLED Reviewed-by: Aleksandrs Vinarskis <alex.vinarskis@gmail.com> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-2-6310176239a6@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Stephan Gerhold [Fri, 22 Aug 2025 09:28:52 +0000 (11:28 +0200)]
arm64: dts: qcom: x1e80100: Add pinctrl template for eDP0 HPD
At the moment, we indirectly rely on the boot firmware to set up the
pinctrl for the eDP HPD line coming from the internal display. If the boot
firmware does not configure the display (e.g. because a different display
is selected for output in the UEFI settings), then the display fails to
come up and there are several errors in the kernel log:
[drm:dpu_encoder_phys_vid_wait_for_commit_done:544] [dpu error]vblank timeout: 80020041
[drm:dpu_kms_wait_for_commit_done:524] [dpu error]wait for commit done returned -110
[drm:dpu_encoder_frame_done_timeout:2715] [dpu error]enc40 frame done timeout
...
Add a new &edp0_hpd_default pinctrl template that can be used by boards to
set up the eDP HPD pin correctly. All boards upstream so far need the same
configuration; if a board needs a different configuration it can just avoid
using this template and define a custom one in the board DT.
Barnabás Czémán [Sat, 30 Aug 2025 21:13:20 +0000 (23:13 +0200)]
arm64: dts: qcom: msm8953: correct SPI pinctrls
SPI pinctrls should handle 4 pins MOSI, MISO, CLK and CS.
This change adding the missing pins for pinctrls and correcting
CS pins according to downstream sources.
Jagadeesh Kona [Fri, 22 Aug 2025 09:26:38 +0000 (11:26 +0200)]
arm64: dts: qcom: sm8650: Additionally manage MXC power domain in camcc
Camcc requires both MMCX and MXC rails to be powered ON to configure
the camera PLLs on SM8650 platform. Hence add MXC power domain to
camcc node on SM8650.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-6-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: sm8550: Additionally manage MXC power domain in camcc
Camcc requires both MMCX and MXC rails to be powered ON to configure
the camera PLLs on SM8550 platform. Hence add MXC power domain to
camcc node on SM8550.
Fixes: e271b59e39a6f ("arm64: dts: qcom: sm8550: Add camera clock controller") Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-5-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jagadeesh Kona [Fri, 22 Aug 2025 09:26:36 +0000 (11:26 +0200)]
arm64: dts: qcom: sm8450: Additionally manage MXC power domain in camcc
Camcc requires both MMCX and MXC rails to be powered ON to configure
the camera PLLs on SM8450 platform. Hence add MXC power domain to
camcc node on SM8450.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-4-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jagadeesh Kona [Fri, 22 Aug 2025 09:26:35 +0000 (11:26 +0200)]
arm64: dts: qcom: sm8650: Additionally manage MXC power domain in videocc
Videocc requires both MMCX and MXC rails to be powered ON to configure
the video PLLs on SM8650 platform. Hence add MXC power domain to videocc
node on SM8650.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-3-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jagadeesh Kona [Fri, 22 Aug 2025 09:26:34 +0000 (11:26 +0200)]
arm64: dts: qcom: sm8550: Additionally manage MXC power domain in videocc
Videocc requires both MMCX and MXC rails to be powered ON to configure
the video PLLs on SM8550 platform. Hence add MXC power domain to videocc
node on SM8550.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-2-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jagadeesh Kona [Fri, 22 Aug 2025 09:26:33 +0000 (11:26 +0200)]
arm64: dts: qcom: sm8450: Additionally manage MXC power domain in videocc
Videocc requires both MMCX and MXC rails to be powered ON to configure
the video PLLs on SM8450 platform. Hence add MXC power domain to videocc
node on SM8450.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250822-topic-sm8x50-upstream-pll-multi-pd-voting-dt-v2-1-28f35728a146@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: Use GIC_SPI for interrupt-map for readability
Decoding interrupt-map is tricky, because it consists of five
components. Use known GIC_SPI define in final interrupt specifier
component makes easier to read.
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
sm8350.dtsi:1554.4-1557.30: Warning (interrupt_map): /soc@0/pcie@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
sm8250.dtsi:2166.4-2169.30: Warning (interrupt_map): /soc@0/pcie@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
sm8150.dtsi:1869.4-1872.30: Warning (interrupt_map): /soc@0/pcie@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
sm6150.dtsi:1122.4-1125.30: Warning (interrupt_map): /soc@0/pcie@1c08000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
sc8180x.dtsi:1743.4-1746.30: Warning (interrupt_map): /soc@0/pcie@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
qcs404.dtsi:1496.4-1499.30: Warning (interrupt_map): /soc@0/pcie@10000000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@b000000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
msm8996.dtsi:1931.5-1934.31: Warning (interrupt_map): /soc@0/bus@0/pcie@600000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@9bc0000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
lemans.dtsi:7623.3-7626.29: Warning (interrupt_map): /pcie@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
ipq5424.dtsi:961.4-964.30: Warning (interrupt_map): /soc@0/pcie@50000000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@f200000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component "parent unit address", which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Stephan Gerhold [Tue, 19 Aug 2025 10:45:23 +0000 (12:45 +0200)]
arm64: dts: qcom: x1e80100-qcp: Fix swapped USB MP repeaters
The &eusb3_repeater belongs to the first port of the USB MP controller and
the &eusb6_repeater belongs to the second. This is obvious if one looks at
e.g. the CRD or the Dell XPS where only the second port of the USB MP is
used: They only have the &eusb6_repeater and already specify it for the
&usb_mp_hsphy1.
Swap them to set the correct repeater for each of the USB ports.
Stephan Gerhold [Tue, 19 Aug 2025 10:45:22 +0000 (12:45 +0200)]
arm64: dts: qcom: x1e80100-asus-vivobook-s15: Fix swapped USB MP repeaters
The &eusb3_repeater belongs to the first port of the USB MP controller and
the &eusb6_repeater belongs to the second. This is obvious if one looks at
e.g. the CRD or the Dell XPS where only the second port of the USB MP is
used: They only have the &eusb6_repeater and already specify it for the
&usb_mp_hsphy1.
Swap them to set the correct repeater for each of the USB ports.
Stephan Gerhold [Tue, 19 Aug 2025 10:45:21 +0000 (12:45 +0200)]
arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: Fix swapped USB MP repeaters
The &eusb3_repeater belongs to the first port of the USB MP controller and
the &eusb6_repeater belongs to the second. This is obvious if one looks at
e.g. the CRD or the Dell XPS where only the second port of the USB MP is
used: They only have the &eusb6_repeater and already specify it for the
&usb_mp_hsphy1.
Swap them to set the correct repeater for each of the USB ports.
projects / thirdparty / kernel / linux.git / log
