arm64: dts: qcom: qcs615-ride: Set drive strength for wlan-en-state pin
Set the drive-strength to 16mA for gpio98 used as wlan-en-state in the
QCS615 ride platform device tree. This ensures sufficient output
strength for controlling the WLAN enable signal reliably.
arm64: dts: qcom: sc8280xp-x13s: enable camera privacy indicator
Leverage newly introduced 'leds' and 'led-names' properties to pass
indicator's phandle and function to v4l2 subnode. The latter supports
privacy led since couple of years ago under 'privacy-led' designation.
Unlike initially proposed trigger-source based approach, this solution
cannot be easily bypassed from userspace, thus reducing privacy
concerns.
Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com> Tested-by: Steev Klimaszewski <threeway@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250910-leds-v5-4-bb90a0f897d5@vinarskis.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: ipq5424: add cooling maps for CPU thermal zones
Add cooling-maps to the cpu1, cpu2, and cpu3 thermal zones to associate
passive trip points with CPU cooling devices. This enables proper
thermal mitigation by allowing the thermal framework to throttle CPUs
based on temperature thresholds. Also, label the trip points to allow
referencing them in the cooling maps.
Luca Weiss [Thu, 23 Oct 2025 11:39:27 +0000 (13:39 +0200)]
arm64: dts: qcom: sm6350: Add OPP table support to UFSHC
UFS host controller, when scaling gears, should choose appropriate
performance state of RPMh power domain controller along with clock
frequency. So let's add the OPP table support to specify both clock
frequency and RPMh performance states replacing the old "freq-table-hz"
property.
Luca Weiss [Thu, 23 Oct 2025 11:39:26 +0000 (13:39 +0200)]
arm64: dts: qcom: sm6350: Fix wrong order of freq-table-hz for UFS
During upstreaming the order of clocks was adjusted to match the
upstream sort order, but mistakently freq-table-hz wasn't re-ordered
with the new order.
Fix that by moving the entry for the ICE clk to the last place.
Alexey Klimov [Wed, 22 Oct 2025 06:06:43 +0000 (07:06 +0100)]
arm64: dts: qcom: qrb2210-rb1: add HDMI/I2S audio playback support
Add sound node and aDSP-related pieces to enable HDMI+I2S audio playback
support on Qualcomm QR2210 RB1 board. That is the only sound output
supported for now.
The audio playback is verified using the following commands:
amixer -c0 cset iface=MIXER,name='SEC_MI2S_RX Audio Mixer MultiMedia1' 1
aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
Add the Low Power Audio SubSystem Low Power Island (LPASS LPI) pin
controller device node required for audio subsystem on Qualcomm
QRB2210 RB1. QRB2210 is based on qcm2290 which is based on sm6115.
While at this, also add description of lpi_i2s2 pins (active state)
required for audio playback via HDMI/I2S.
The touchscreen properties previously upstreamed was based on downstream
touchscreen driver. We ended up adapting upstream edt_ft5x06 driver to
support the touchscreen controller used in this device. Update the
touchscreen properties to match with the upstream edt_ft5x06
driver.
Also, the touchscreen controller used in this device is ft5452 and not
fts8719. Fix the compatible string accordingly.
The wakeup-source property was removed as it prevents the touchscreen's
regulators and irq from being disabled when the device is suspended and
could lead to unexpected battery drain. Once low power mode and
tap-to-wake functionality is properly implemented and tested to be
working, we can add it back, if needed.
Guido Günther [Mon, 20 Oct 2025 11:58:24 +0000 (13:58 +0200)]
arm64: dts: qcom: sdm845-shift-axolotl: Drop address and size cells from panel
They're set in the parent to describe the panel's reg property already.
Fixes the
linux/arch/arm64/boot/dts/qcom/sdm845-shift-axolotl.dtb: panel@0 (visionox,rm69299-shift): '#address-cells', '#size-cells' do not match any of the regexes: '^pinctrl-[0-9]+$'
arm64: dts: qcom: sm8550-hdk: Add SM8550-HDK Rear Camera Card overlay
Lantronix SM8550-HDK board may be equipped with a Rear Camera Card PCB
which contains:
* Samsung S3K33D time-of-fligt image sensor connected to CSIPHY0 (TOF),
* Omnivision OV64B40 image sensor connected to CSIPHY1 (uWide),
* Sony IMX766 image sensor connected to CSIPHY2 (Wide),
* Samsung S5K3M5 image sensor connected to CSIPHY3 (Tele),
* two flash leds.
The change adds support of a Samsung S5K3M5 camera image sensor and
two flash leds on the external camera card module.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20251013235500.1883847-4-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
arm64: dts: qcom: x1e80100: Add opp-level to indicate PCIe data rates
The existing OPP table for PCIe is shared across different link
configurations such as data rates 8GT/s x2 and 16GT/s x1. These
configurations often operate at the same frequency, allowing them
to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have
different RPMh votes which cannot be represented accurately when
sharing a single OPP.
To address this, introduce an `opp-level` to indicate the PCIe data
rate and uniquely differentiate OPP entries even when the frequenc
is the same.
Although this platform does not currently suffer from this issue, the
change is introduced to support unification across platforms.
Append the opp level to name of the opp node to indicate both frequency
and level.
arm64: dts: qcom: sm8650: Add opp-level to indicate PCIe data rates
The existing OPP table for PCIe is shared across different link
configurations such as data rates 8GT/s x2 and 16GT/s x1. These
configurations often operate at the same frequency, allowing them
to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have
different RPMh votes which cannot be represented accurately when
sharing a single OPP.
To address this, introduce an `opp-level` to indicate the PCIe data
rate and uniquely differentiate OPP entries even when the frequenc
is the same.
Although this platform does not currently suffer from this issue, the
change is introduced to support unification across platforms.
Append the opp level to name of the opp node to indicate both frequency
and level.
arm64: dts: qcom: sm8550: Add opp-level to indicate PCIe data rates
The existing OPP table for PCIe is shared across different link
configurations such as data rates 8GT/s x2 and 16GT/s x1. These
configurations often operate at the same frequency, allowing them
to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have
different RPMh votes which cannot be represented accurately when
sharing a single OPP.
To address this, introduce an `opp-level` to indicate the PCIe data
rate and uniquely differentiate OPP entries even when the frequency
is the same.
Although this platform does not currently suffer from this issue, the
change is introduced to support unification across platforms.
Append the opp level to name of the opp node to indicate both frequency
and level.
arm64: dts: qcom: sm8450: Add opp-level to indicate PCIe data rates
The existing OPP table for PCIe is shared across different link
configurations such as data rates 8GT/s x2 and 16GT/s x1. These
configurations often operate at the same frequency, allowing them
to reuse the same OPP entries. However, 8GT/s and 16 GT/s may have
different RPMh votes which cannot be represented accurately when
sharing a single OPP.
To address this, introduce an `opp-level` to indicate the PCIe data
rate and uniquely differentiate OPP entries even when the frequency
is the same.
Although this platform does not currently suffer from this issue, the
change is introduced to support unification across platforms.
Append the opp level to name of the opp node to indicate both frequency
and level.
The commit 458de584248a ("arm64: dts: qcom: x1e80100: move dp0/1/2
data-lanes to SoC dtsi") has landed before this file was added, so
the data-lanes lines here remained.
Remove them to enable 4-lane DP on the X1E Dell Inspiron/Latitude.
Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251012224909.14988-1-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Val Packett [Sun, 12 Oct 2025 22:40:08 +0000 (19:40 -0300)]
arm64: dts: qcom: x1-dell-thena: Add missing pinctrl for eDP HPD
The commit a41d23142d87 ("arm64: dts: qcom: x1e80100-dell-xps13-9345:
Add missing pinctrl for eDP HPD") has applied this change to a very
similar machine, so apply it here too.
This allows us not to rely on the boot firmware to set up the pinctrl
for the eDP HPD line of the internal display.
Fixes: e7733b42111c ("arm64: dts: qcom: Add support for Dell Inspiron 7441 / Latitude 7455") Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Val Packett <val@packett.cool> Link: https://lore.kernel.org/r/20251012224706.14311-1-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Le Qi [Fri, 10 Oct 2025 03:37:28 +0000 (11:37 +0800)]
arm64: dts: qcom: hamoa-iot-evk: Fix 4-speaker playback support
On the HAMOA-IOT-EVK board only 2 out of 4 speakers were functional.
Unlike the CRD, which shares a single GPIO reset line for WSA1/2,
this board provides a dedicated GPIO reset for each WSA, resulting
in 4 separate reset lines.
Update the device tree accordingly so that all 4 speakers can
playback audio as expected.
Konrad Dybcio [Thu, 9 Oct 2025 12:59:18 +0000 (14:59 +0200)]
arm64: dts: qcom: x1e80100: Describe the full 'link' region of DP hosts
The regions are larger than currently described. Rather inconveniently,
some control registers, including some related to USB4, are in that
left-out chunk.
Extend it to cover the entire region, as per the hw specification.
arm64: dts: qcom: qcm6490-shift-otter: Remove thermal zone polling delays
As with all other devices in commit 7747a49db7e5 ("arm64: dts: qcom:
sc7280-*: Remove thermal zone polling delays"), apply the same change to
this device as the delays are assumed to be equal to "0" if not set.
Jingzhou Zhu [Wed, 8 Oct 2025 13:00:52 +0000 (21:00 +0800)]
arm64: dts: qcom: Add support for Huawei MateBook E 2019
Add device tree for Huawei MateBook E 2019, which is a 2-in-1 tablet based
on Qualcomm's sdm850 platform.
Supported features:
- ADSP, CDSP and SLPI
- Volume Key
- Power Key
- Tablet Mode Switching
- Display
- Touchscreen
- Stylus
- WiFi [1]
- Bluetooth [2]
- GPU
- USB
- Keyboard
- Touchpad
- UFS
- SD Card
- Audio (right internal mic and headphone mic not working)
- Mobile Network
[1] WiFi probing log:
ath10k_snoc 18800000.wifi: Adding to iommu group 12
ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001
ath10k_snoc 18800000.wifi: qmi fw_version 0x2009856b fw_build_timestamp 2018-07-19 12:28 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0
ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
ath10k_snoc 18800000.wifi: htt-ver 3.53 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
[2] Bluetooth probing log:
Bluetooth: hci0: setting up wcn399x
Bluetooth: hci0: QCA Product ID :0x0000000a
Bluetooth: hci0: QCA SOC Version :0x40010214
Bluetooth: hci0: QCA ROM Version :0x00000201
Bluetooth: hci0: QCA Patch Version:0x00000001
Bluetooth: hci0: QCA controller version 0x02140201
Bluetooth: hci0: QCA Downloading qca/crbtfw21.tlv
Bluetooth: hci0: QCA Downloading qca/crnv21.bin
Bluetooth: hci0: QCA setup on UART is completed
Features not supported yet:
- Panel Backlight
- Lid Detection
- Battery
- EFI Variable Access
- Cameras
1. Panel backlight, lid detection and battery will be supported with the
EC driver upstreamed.
2. EFI variables can only be read with the QSEECOM driver, and will be
enabled when the driver is fixed.
3. Cameras are tested to work with modified downstream driver, and once
drivers for these camera modules are included in the tree, cameras can
be enabled.
Features won't be supported:
- External Display
- Fingerprint
1. To make external display work, more reverse engineering may be required,
but it's beyond my ability.
2. Fingerprint is controlled by TrustZone, meaning direct access to it
isn't possible.
arm64: dts: qcom: sm8750-mtp: move PCIe GPIOs to pcieport0 node
Relocate the wake-gpios and perst-gpios properties from the pcie0
controller node to the pcieport0 node. These GPIOs are associated with
the PCIe root port and should reside under the pcieport0 node.
Also rename perst-gpios to reset-gpios to match the expected property name
in the PCIe port node.
Fixes: 141714e163bb ("arm64: dts: qcom: sm8750-mtp: Add WiFi and Bluetooth") Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20251008-sm8750-v1-1-daeadfcae980@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Neil Armstrong [Tue, 7 Oct 2025 18:53:44 +0000 (20:53 +0200)]
arm64: dts: qcom: sm8650: set ufs as dma coherent
The UFS device is ovbiously dma coherent like the other IOMMU devices
like usb, mmc, ... let's fix this by adding the flag.
To be sure an extensive test has been performed to be sure it's
safe, as downstream uses this flag for UFS as well.
As an experiment, I checked how the dma-coherent could impact
the UFS bandwidth, and it happens the max bandwidth on cached
write is slighly highter (up to 10%) while using less cpu time
since cache sync/flush is skipped.
arm64: dts: qcom: sm8250: Add MDSS_CORE reset to mdss
Like on other platforms, if the OS does not support recovering the state
left by the bootloader it needs access to MDSS_CORE, so that it can
clear the MDSS configuration. Add a reference to the relevant reset.
arm64: dts: qcom: x1e80100-asus-zenbook-a14: Enable WiFi, Bluetooth
Unlike UX3407QA with WCN6855, UX3407RA comes with WCN7850. Definitions
were not added during initial bringup due to lack of hardware to test
it. Add missing definitions that were now confirmed to work.
arm64: dts: qcom: Rework X1-based Asus Zenbook A14's displays
The laptop comes in two variants:
* UX3407RA, higher end, FHD+ OLED or WOXGA+ OLED panels
* UX3407QA, lower end, FHD+ OLED or FHD+ LCD panels
Even though all three panels work with "edp-panel", unfortunately the
brightness adjustmenet of LCD panel is PWM based, requiring a dedicated
device-tree. Convert "x1p42100-asus-zenbook-a14.dts" into ".dtsi" to
allow for this split, introduce new LCD variant. Leave current variant
without postfix and with the unchanged model name, as some distros
(eg. Ubuntu) rely on this for automatic device-tree detection during
kernel installation/upgrade.
As dedicated device-tree is required, update compatibles of OLED
variants to correct ones. Keep "edp-panel" as fallback, since it is
enough to make the panels work.
While at it moving .dts, .dtsi around, drop 'model' from the top level
x1-asus-zenbook-a14.dtsi as well.
dt-bindings: arm: qcom: Add Asus Zenbook A14 UX3407QA LCD/OLED variants
X1/X1 Plus variant of the said device comes in either FHD+ OLED or FHD+
LCD panel, and shares the same model number UX3407QA. It appears LCD
panel's brightness adjustment is PWM backlight controlled, so a
dedicated device-tree is required. Introduce dedicated compatibles with
fallback to 'asus,zenbook-a14-ux3407qa' as they are otherwise the same.
Since max77705 has a register, which indicates interrupt source, it acts
as an interrupt controller.
Direct MAX77705's subdevices to use the IC's internal interrupt
controller, instead of listening to every interrupt fired by the
chip towards the host device.
arm64: dts: qcom: monaco-evk: Add firmware-name to QUPv3 nodes
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
arm64: dts: qcom: lemans-evk: Add firmware-name to QUPv3 nodes
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
arm64: dts: qcom: qcs6490-rb3gen2: Add firmware-name to QUPv3 nodes
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
The BQ Aquaris X5 (Longcheer L8910) has a Himax HX852x-ES touchscreen,
which can now be described with the bindings recently added to linux-next.
Add it to the device tree to allow using the touchscreen.
Signed-off-by: Jonathan Albrieux <jonathan.albrieux@gmail.com> Co-developed-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250919-msm8916-l8910-touchscreen-v1-1-c46e56ec0a3b@gerhold.net Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Update min/max voltage settings for regulators below to align
with the HW specification
vreg_l3b_0p504
vreg_l6b_1p2
vreg_l11b_1p504
vreg_l14b_1p08
vreg_l16b_1p1
vreg_l17b_1p7
vreg_s1c_2p19
vreg_l8c_1p62
vreg_l9c_2p96
vreg_l12c_1p65.
While at it, remove RPMH regulator rails (listed below) as
these are not to be used on APPS, and any client accidently
voting on it can potentially cause issues.
vreg_s2b_0p876
vreg_s2c_0p752
vreg_s5c_0p752
vreg_s7c_0p752
vreg_s10c_0p752
vreg_l4b_0p752
vreg_l5b_0p752.
arm64: dts: qcom: sm6350: Add MDSS_CORE reset to mdss
Like on other platforms, if the OS does not support recovering the state
left by the bootloader it needs access to MDSS_CORE, so that it can
clear the MDSS configuration. Add a reference to the relevant reset.
SM6150 and QCS615 are two names for the same die, collectively known as
'talos'. Follow the example of other platforms and rename SM6150 to
talos.dtsi.
The X1E80100 and several other similar names (X1E78100, X1E001DE) all
belong to the platform now known as 'hamoa'. Follow the example of
'lemans' and rename the x1e80100.dtsi to hamoa.dtsi and
x1e80100-pmics.dtsi to hamoa-pmics.dtsi.
The QCS8300 and QCS8275 are two variants of the same die with no
difference visible to the Linux kernel, which are collectively named as
'monaco'. Rather than trying to using the name, which is not always
relevant, follow the example of 'lemans' and rename qcs8300.dtsi to
monaco.dtsi (and qcs8300-pmics.dtsi to monaco-pmics.dtsi).
arm64: dts: qcom: sc7280: Increase config size to 256MB for ECAM feature
PCIe ECAM(Enhanced Configuration Access Mechanism) feature requires
maximum of 256MB configuration space.
To enable this feature increase configuration space size to 256MB. If
the config space is increased, the BAR space needs to be truncated as
it resides in the same location. To avoid the bar space truncation move
config space, DBI, ELBI, iATU to upper PCIe region and use lower PCIe
iregion entirely for BAR region.
This depends on the commit: '10ba0854c5e6 ("PCI: qcom: Disable mirroring
of DBI and iATU register space in BAR region")'
arm64: dts: qcom: qcs615: Add OSM l3 interconnect provider node and CPU OPP tables to scale DDR/L3
Add Operation State Manager (OSM) L3 interconnect provide node and OPP
tables required to scale DDR and L3 per freq-domain on QCS615 SoC.
As QCS615 and SM8150 SoCs have same OSM hardware, added SM8150
compatible as fallback for QCS615 OSM device node.
Krishna Kurapati [Fri, 24 Oct 2025 10:50:19 +0000 (16:20 +0530)]
arm64: dts: qcom: lemans: Add missing quirk for HS only USB controller
The PIPE clock is provided by the USB3 PHY, which is predictably not
connected to the HS-only controller. Add "qcom,select-utmi-as-pipe-clk"
quirk to HS only USB controller to disable pipe clock requirement.
Krishna Kurapati [Fri, 24 Oct 2025 10:50:18 +0000 (16:20 +0530)]
arm64: dts: qcom: x1e80100: Add missing quirk for HS only USB controller
The PIPE clock is provided by the USB3 PHY, which is predictably not
connected to the HS-only controller. Add "qcom,select-utmi-as-pipe-clk"
quirk to HS only USB controller to disable pipe clock requirement.
Krishna Kurapati [Sun, 19 Oct 2025 11:56:30 +0000 (17:26 +0530)]
arm64: dts: qcom: x1e80100: Fix compile warnings for USB HS controller
With W=1, the following error comes up:
Warning (graph_child_address): /soc@0/usb@a2f8800/usb@a200000/ports: graph node has single child node 'port@0', #address-cells/#size-cells are not necessary
This could be since the controller is only HS capable and only one port
node is added.
The zap shader was previously loaded from "qcom/a530_zap.mdt", which is a
symlink to "qcom/apq8096/a530_zap.mbn". Update the DTS to reference the
actual firmware file in linux-firmware directly.
This avoids relying on the symlink and ensures a more robust firmware load
path.
When booting msm8953-based devices, the following kernel message
appears:
[ 13.090800] qcom-spmi-vadc 200f000.spmi:pmic@2:adc@3100: Please define VDD channel
It turns out the pmi8950 uses same VDD and GND channels as other
Qualcomm's PMICs, so we can simply copy the channel definition from
the other Qualcomm's PMIC dtsi.
projects / thirdparty / linux.git / log
