The WSA RX slot mapping is currently computed entirely from the channel
count in .prepare() and pushed unconditionally via
snd_soc_dai_set_channel_map(). Userspace has no way to express a
different channel map, so any map defined in UCM is ignored.
Add writable WSA Playback Channel Map controls for the WSA RX backend
ports. Store the userspace-selected SNDRV_CHMAP_* map per AFE port,
translate it to Q6 PCM_CHANNEL_* slots at .prepare() time, and keep the
previous default mapping when userspace has not provided a complete map.
The WSA DAI links are backend no_pcm links, so there is no PCM instance
available when the card is initialized. Register card-level controls
instead, which keeps the maps visible to UCM before stream startup while
still storing the selected map per WSA backend port. Expose the standard
ALSA channel maps through the controls' TLV data.
Allow up to six WSA channels for Glymur, and give the controls
WSA-specific names so they are distinguishable from other channel map
controls on the same card.
Assisted-by: Codex:GPT-5.5
Link: https://patch.msgid.link/20260724-b4-sound-qcom-x1e80100-allow-ucm-channel-map-v2-2-2ca3c1250018@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
The handover interrupt is expected to be consumed once during each prepare
cycle. If the remote processor keeps signalling handover after the first
event, qcom_q6v5 currently logs the duplicate interrupt repeatedly while
leaving the IRQ enabled.
Track the handover IRQ enable state explicitly and route all handover IRQ
enable/disable operations through idempotent helpers. Request the handover
IRQ with IRQF_NO_AUTOEN so it is only enabled through the helper during
prepare. The handover handler disables it after marking handover as issued,
while unprepare disables and synchronizes it before checking whether
handover was issued.
Link: https://patch.msgid.link/20260612-rproc-q6v5-handover-irq-one-shot-v1-1-bb688f4446b3@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Add ADC node and define channels for:
- Die temperature for PMK8550, PM8550VE* and PMC8380* PMICs.
- PM8550: Die temperature, VPH power, and system thermistors.
Add io-channels and io-channel-names properties to the
temp_alarm nodes so that they can get temperature reading
from the ADC die_temp channels.
Remove die_temp channel of PMC8380_6 for Purwa boards where
this PMIC is not present.
Signed-off-by: Ayyagari Ushasreevalli <aushasre@qti.qualcomm.com>
Signed-off-by: Jishnu Prakash <jishnu.prakash@oss.qualcomm.com>
Link: https://patch.msgid.link/20260728-adc5_gen3_dt-v4-4-355f0edece77@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Qualcomm remoteproc drivers such as qcom_q6v5_mss, which do not use the
Peripheral Authentication Service (PAS), always map the MBA region before
use and unmap it once the usage is complete. This behavior was introduced
to avoid issues seen in the past where speculative accesses from the
application processor to the MBA region after it was assigned to the remote
Q6 led to an XPU violation. The issue was mitigated by unmapping the region
before handing control to the remote Q6.
Currently, most Qualcomm SoCs using the PAS driver run either with a
standalone QHEE or the Gunyah hypervisor. In these environments, the
hypervisor unmaps the Q6 memory from HLOS Stage-2 and remaps it into the
Q6 Stage-2 page table. As a result, speculative accesses from HLOS cannot
reach the region even if it remains mapped in HLOS Stage-1; therefore, XPU
violations cannot occur.
However, when the same SoC runs Linux at EL2, Linux itself must perform the
unmapping to avoid such issues. It is still correct to apply this mapping/
unmapping sequence even for SoCs that run under Gunyah, so this behavior
should not be conditional.
Introduce qcom_pas_ctx_map() in qcom_pas.h to centralise the ioremap_wc
pattern used by both qcom_q6v5_pas and qcom_mdt_pas_load, and use it in
both places.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260724182858.1868271-5-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Qualcomm MDT loader changed qcom_mdt_pas_load() to take only four
arguments and use the PAS context for relocation and memory handling.
Update the iris firmware loading path to match that interface by dropping
the temporary memremap/memunmap flow, removing the extra mem_virt argument
from qcom_mdt_pas_load(), and simplifying the error path accordingly.
This keeps the iris driver aligned with the SCM/PAS loader changes and fixes
the build failure caused by the old five-argument call.
Link: https://github.com/qualcomm-linux/qcom-6.18.y/pull/413
Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
Qcom platforms has the legacy of using non-standard SCM calls
splintered over the various kernel drivers. These SCM calls aren't
compliant with the standard SMC calling conventions which is a
prerequisite to enable migration to the FF-A specifications from Arm.
OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't
support these non-standard SCM calls. And even for newer architectures
using S-EL2 with Hafnium support, QTEE won't be able to support SCM
calls either with FF-A requirements coming in. And with both OP-TEE
and QTEE drivers well integrated in the TEE subsystem, it makes further
sense to reuse the TEE bus client drivers infrastructure.
The added benefit of TEE bus infrastructure is that there is support
for discoverable/enumerable services. With that client drivers don't
have to manually invoke a special SCM call to know the service status.
So enable the generic Peripheral Authentication Service (PAS) provided
by the firmware. It acts as the common layer with different TZ
backends plugged in whether it's an SCM implementation or a proper
TEE bus based PAS service implementation.
Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20260427095603.1157963-5-sumit.garg@kernel.org/
The QREF block supplies reference clocks to PCIe/USB/UFS PHYs and
requires dedicated LDO supplies to operate. The digital control
interface for QREF (clkref_en registers) resides in TCSR on x1e80100.
Since QREF has no dedicated DT node of its own, these supply
properties are placed in the TCSR node which acts as the control
interface for QREF.
Add a dedicated binding file for qcom,x1e80100-tcsr and document the
supply properties.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
Link: https://patch.msgid.link/20260714-hamoa_tcsr_qref_0714_2-v1-1-13047922a376@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Add board support for the HP EliteBook X G2q 14" Next Gen AI PC
(product SKU C4JG0AV, board 8E91), a Snapdragon X2 Elite (Glymur)
laptop, using the "hp,elitebook-x-g2q" / "qcom,glymur" compatible.
Enabled by this device tree:
- internal eDP panel (samsung,atna33xc20)
- 2x USB Type-C with DisplayPort alt-mode and USB
- chassis HDMI output
- chassis USB-A host port (usb_mp multiport controller)
- internal eUSB2 host with the Elan fingerprint reader
- NVMe SSD on PCIe5
- Wi-Fi and Bluetooth
- HID-over-I2C keyboard, touchpad, touchscreen; lid switch
- Adreno GPU and GMU (Freedreno GL on Mesa)
- audio playback and capture
- real-time clock
- compute DSP (cDSP)
The HDMI jack is driven by a power-only DisplayPort-to-HDMI LSPCON on
the usb_2 combo-PHY DP lanes rather than being a third USB-C port; HPD
is on gpio126. The LSPCON is on an I/O sub-board with no I2C/AUX control
path, so it is modelled with the generic simple-bridge "parade,ps185hdm"
compatible used by the in-tree x1e80100 HDMI-bridge boards (the exact
bridge part is unconfirmed) and it needs CONFIG_DRM_SIMPLE_BRIDGE.
The &gpu/&gmu enable, the audio nodes and &remoteproc_soccp opt into
glymur.dtsi SoC nodes that are still in-flight; those series are
declared as prerequisites in the cover letter.
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Jason Pettit <jason.pettit@oss.qualcomm.com>
Link: https://patch.msgid.link/20260625-glymur-send-v2-2-00905324ffbf@oss.qualcomm.com
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Move interrupts and interrupt-names list out of pas-common since they
will be redefined differently for Kaanapali SoCCP.
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
The existing DP PHY PLL and AUX configuration for the Glymur platform
does not fully follow the Hardware Programming Guide requirements for
DP over Type-C, which results in DP link bring-up failures.
Update the DP PHY programming sequence and PLL-related register
settings to align with the latest HPG recommendations. With this
change, DP link training completes successfully on Glymur-based
platforms.
Fixes: d10736db98 ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms")
Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com>
Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Bump the maxItems from 16 to 17 for all qcom,ports-* properties to
accommodate SoundWire controllers v3.1.0 with 17 data ports.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Abel Vesa
Ayyagari UshasreevalliandAbel Vesa
Sumit GargandAbel Vesa
Mukesh OjhaandAbel Vesa
Gourav KumarandAbel Vesa
Jishnu PrakashandAbel Vesa
Srinivas KandagatlaandAbel Vesa
Qiang YuandAbel Vesa
Jason PettitandAbel Vesa
Sibi SankarandAbel Vesa
Jingyi WangandAbel Vesa
Mahadevan PandAbel Vesa
Konrad DybcioandAbel Vesa