Skip to content

Prepare qcom-next based on tag 'Linux 6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#25

Closed
sgaud-quic wants to merge 64 commits intoqualcomm-linux:qcom-next-stagingfrom
sgaud-quic:qcom-next-staging
Closed

Prepare qcom-next based on tag 'Linux 6.15' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#25
sgaud-quic wants to merge 64 commits intoqualcomm-linux:qcom-next-stagingfrom
sgaud-quic:qcom-next-staging

Conversation

@sgaud-quic
Copy link
Contributor

Merge following topic branches into v6.15 base:
tech/bsp/clk 8310781
tech/bsp/pinctrl 7030654
tech/debug/hwtracing 9982cba
tech/mm/audio/all a0a1b5c
tech/mm/video 2705b45
tech/net/ath 5bc89ad
tech/pm/power 1eeed9b
tech/all/dt/qcs6490 f08a96d
tech/all/dt/qcs9100 de711b0
tech/all/dt/qcs8300 a7787e1
tech/all/dt/qcs615 0209969
tech/all/config a58db88

Imran Shaik and others added 30 commits May 24, 2025 10:00
The QCS8300 Camera clock controller is a derivative of SA8775P, but has
few additional clocks and offset differences. Hence, add support for
QCS8300 Camera clock controller by extending the SA8775P CamCC.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Imran Shaik <quic_imrashai@quicinc.com>

Link: https://lore.kernel.org/all/20250109-qcs8300-mm-patches-new-v4-0-63e8ac268b02@quicinc.com/
Patch-mainline: linux-clk @ 01/09/25, 14:27
Signed-off-by: Shiraz Hashim <quic_shashim@quicinc.com>
Add the global clock controller support for QCS615 SoC.

Signed-off-by: Taniya Das <quic_tdas@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Imran Shaik <quic_imrashai@quicinc.com>
* FROMLIST: dt-bindings: arm: Add label in the coresight components

Current name of coresight component's folder consists of prefix of
the device and the id in the device list. When run 'ls' command,
we can get the register address of the device. Take CTI for example,
if we want to set the config for modem CTI, but we can't know which
CTI is modem CTI from all current information.

cti_sys0 -> ../../../devices/platform/soc@0/138f0000.cti/cti_sys0
cti_sys1 -> ../../../devices/platform/soc@0/13900000.cti/cti_sys1

Add label to show hardware context information of each coresight
device. There will be a sysfs node label in each device folder.

cat /sys/bus/coresight/devices/cti_sys0/label

Link: https://lore.kernel.org/all/20250226121926.2687497-2-quic_jinlmao@quicinc.com/
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: coresight: Add label sysfs node support

For some coresight components like CTI and TPDM, there could be
numerous of them. From the node name, we can only get the type and
register address of the component. We can't identify the HW or the
system the component belongs to. Add label sysfs node support for
showing the intuitive name of the device.

Link: https://lore.kernel.org/all/20250226121926.2687497-3-quic_jinlmao@quicinc.com/
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: dt-bindings: arm: Add CoreSight QMI component description

Add new coresight-qmi.yaml file describing the bindings required
to define qmi node in the device trees.

Link: https://lore.kernel.org/all/20250424115854.2328190-2-quic_jinlmao@quicinc.com/
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: coresight: Add coresight QMI driver

Coresight QMI driver uses QMI(Qualcomm Messaging Interface) interfaces
to communicate with remote subsystems. Driver gets the instance id and
service id from device tree node and init the QMI connections to remote
subsystems. Send request function is for other coresight drivers to
communicate with remote subsystems.

Link: https://lore.kernel.org/all/20250424115854.2328190-3-quic_jinlmao@quicinc.com/
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: dt-bindings: arm: Add qcom,qmi-id for remote etm

qcom,qmi-id is required for remote etm driver to find the remote
subsystem connection. It is the instance id used by qmi API to
communicate with remote processor.

Link: https://lore.kernel.org/all/20250424115854.2328190-4-quic_jinlmao@quicinc.com/
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: coresight: Add remote etm support

The system on chip (SoC) consists of main APSS(Applications
processor subsytem) and additional processors like modem, lpass.
Coresight remote etm(Embedded Trace Macrocell) driver is for
enabling and disabling the etm trace of remote processors. It
uses QMI interface to communicate with remote processors' software
and uses coresight framework to configure the connection from
remote etm source to TMC sinks.

Link: https://lore.kernel.org/all/20250424115854.2328190-5-quic_jinlmao@quicinc.com/
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: arm64: dts: qcom: msm8996: Add coresight qmi node

coresight qmi nodes is to init the qmi connection to remote subsystem.
qcom,qmi-id is used by remote etm driver to get the remote subsystem
connection and send the request.

Link: https://lore.kernel.org/all/20250424115854.2328190-6-quic_jinlmao@quicinc.com/
Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>

* FROMLIST: dt-bindings: arm: Add support for Coresight TGU trace

The Trigger Generation Unit (TGU) is designed to detect patterns or
sequences within a specific region of the System on Chip (SoC). Once
configured and activated, it monitors sense inputs and can detect a
pre-programmed state or sequence across clock cycles, subsequently
producing a trigger.

   TGU configuration space
        offset table
 x-------------------------x
 |                         |
 |                         |
 |                         |                           Step configuration
 |                         |                             space layout
 |   coresight management  |                           x-------------x
 |        registers        |                     |---> |             |
 |                         |                     |     |  reserve    |
 |                         |                     |     |             |
 |-------------------------|                     |     |-------------|
 |                         |                     |     | priority[3] |
 |         step[7]         |<--                  |     |-------------|
 |-------------------------|   |                 |     | priority[2] |
 |                         |   |                 |     |-------------|
 |           ...           |   |Steps region     |     | priority[1] |
 |                         |   |                 |     |-------------|
 |-------------------------|   |                 |     | priority[0] |
 |                         |<--                  |     |-------------|
 |         step[0]         |-------------------->      |             |
 |-------------------------|                           |  condition  |
 |                         |                           |             |
 |     control and status  |                           x-------------x
 |           space         |                           |             |
 x-------------------------x                           |Timer/Counter|
                                                       |             |
						       x-------------x
TGU Configuration in Hardware

The TGU provides a step region for user configuration, similar
to a flow chart. Each step region consists of three register clusters:

1.Priority Region: Sets the required signals with priority.
2.Condition Region: Defines specific requirements (e.g., signal A
reaches three times) and the subsequent action once the requirement is
met.
3.Timer/Counter (Optional): Provides timing or counting functionality.

Add a new coresight-tgu.yaml file to describe the bindings required to
define the TGU in the device trees.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-1-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight: Add coresight TGU driver

Add driver to support Coresight device TGU (Trigger Generation Unit).
TGU is a Data Engine which can be utilized to sense a plurality of
signals and create a trigger into the CTI or generate interrupts to
processors. Add probe/enable/disable functions for tgu.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-2-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight-tgu: Add signal priority support

Like circuit of a Logic analyzer, in TGU, the requirement could be
configured in each step and the trigger will be created once the
requirements are met. Add priority functionality here to sort the
signals into different priorities. The signal which is wanted could
be configured in each step's priority node, the larger number means
the higher priority and the signal with higher priority will be sensed
more preferentially.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-3-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight-tgu: Add TGU decode support

Decoding is when all the potential pieces for creating a trigger
are brought together for a given step. Example - there may be a
counter keeping track of some occurrences and a priority-group that
is being used to detect a pattern on the sense inputs. These 2
inputs to condition_decode must be programmed, for a given step,
to establish the condition for the trigger, or movement to another
steps.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-4-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight-tgu: add support to configure next action

Add "select" node for each step to determine if another step is taken,
trigger(s) are generated, counters/timers incremented/decremented, etc.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-5-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight-tgu: add timer/counter functionality for TGU

Add counter and timer node for each step which could be
programed if they are to be utilized in trigger event/sequence.

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-6-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

* FROMLIST: coresight-tgu: add reset node to initialize

Add reset node to initialize the value of
priority/condition_decode/condition_select/timer/counter nodes

Link: https://lore.kernel.org/all/20250423-tgu_patch-v5-7-3b52c105cc63@quicinc.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>

---------

Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
Co-authored-by: Mao Jinlong <quic_jinlmao@quicinc.com>
Co-authored-by: Songwei Chai <quic_songchai@quicinc.com>
Add prune.config fragment to disable support for non-Qualcomm
architectures. This helps reduce boot image size and improves
kernel build KPIs by trimming unnecessary configuration options.

Signed-off-by: Komal Bajaj <quic_kbajaj@quicinc.com>
sa8775p-ride firmware supports vendor-defined SYSTEM_RESET2 types.
Describe the reset types: "bootloader" will cause device to reboot and
stop in the bootloader's fastboot mode. "edl" will cause device to
reboot into "emergency download mode", which permits loading images via
the Firehose protocol.

Link: https://lore.kernel.org/r/20250303-arm-psci-system_reset2-vendor-reboots-v9-5-b2cf4a20feda@oss.qualcomm.com
Co-developed-by: Shivendra Pratap <quic_spratap@quicinc.com>
Signed-off-by: Shivendra Pratap <quic_spratap@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Add bindings to describe vendor-specific reboot modes. Values here
correspond to valid parameters to vendor-specific reset types in PSCI
SYSTEM_RESET2 call.

Link: https://lore.kernel.org/r/20250303-arm-psci-system_reset2-vendor-reboots-v9-1-b2cf4a20feda@oss.qualcomm.com
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
qcm6490-idp firmware supports vendor-defined SYSTEM_RESET2 types.
Describe the reset types: "bootloader" will cause device to reboot and
stop in the bootloader's fastboot mode. "edl" will cause device to
reboot into "emergency download mode", which permits loading images via
the Firehose protocol.

Link: https://lore.kernel.org/r/20250303-arm-psci-system_reset2-vendor-reboots-v9-3-b2cf4a20feda@oss.qualcomm.com
Co-developed-by: Shivendra Pratap <quic_spratap@quicinc.com>
Signed-off-by: Shivendra Pratap <quic_spratap@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
…ypes

qcs6490-rb3gen2 firmware supports vendor-defined SYSTEM_RESET2 types.
Describe the reset types: "bootloader" will cause device to reboot and
stop in the bootloader's fastboot mode. "edl" will cause device to
reboot into "emergency download mode", which permits loading images via
the Firehose protocol.

Link: https://lore.kernel.org/r/20250303-arm-psci-system_reset2-vendor-reboots-v9-4-b2cf4a20feda@oss.qualcomm.com
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Now some chips which support 'support_dual_stations' will enable DBS,
but will disable DFS. Restructure the ath11k_mac_setup_iface_combinations
function to support DBS and DFS compatibility.

About 'support_dual_station' feature can refer:
https://msgid.link/20230714023801.2621802-2-quic_cjhuang@quicinc.com

Add a ieee80211_iface_combination to support DBS and DFS compatibility,
one combination can support DFS(same with non dual sta), another
combination can support DBS. When running different scenarios that will
use different ieee80211_iface_combination due to mac80211 will go through
all of possible interface combinations.

In addition, maximum number of interfaces of these types should be total
allowed in this group.

The chips affected are:

 QCA6390 hw2.0
 WCN6855 hw2.0
 WCN6855 hw2.1

Other chips are not affected.

Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-00410-QCAHKSWPL_SILICONZ-2
Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.1.0.1-01161-QCAHKSWPL_SILICONZ-1
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04402-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1


Reviewed-by: Baochen Qiang <quic_bqiang@quicinc.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Tested-by: Mihai Moldovan <ionic@ionic.de>
Link: https://patch.msgid.link/20241127022742.4016870-1-quic_yuzha@quicinc.com

Signed-off-by: Yu Zhang (Yuriy) <quic_yuzha@quicinc.com>
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Co-authored-by: Yu Zhang(Yuriy) <quic_yuzha@quicinc.com>
SoC vendors have different types of resets and are controlled through
various registers. For instance, Qualcomm chipsets can reboot to a
"download mode" that allows a RAM dump to be collected. Another example
is they also support writing a cookie that can be read by bootloader
during next boot. PSCI offers a mechanism, SYSTEM_RESET2, for these
vendor reset types to be implemented without requiring drivers for every
register/cookie.

Add support in PSCI to statically map reboot mode commands from
userspace to a vendor reset and cookie value using the device tree.

A separate initcall is needed to parse the devicetree, instead of using
psci_dt_init because mm isn't sufficiently set up to allocate memory.

Reboot mode framework is close but doesn't quite fit with the
design and requirements for PSCI SYSTEM_RESET2. Some of these issues can
be solved but doesn't seem reasonable in sum:
 1. reboot mode registers against the reboot_notifier_list, which is too
    early to call SYSTEM_RESET2. PSCI would need to remember the reset
    type from the reboot-mode framework callback and use it
    psci_sys_reset.
 2. reboot mode assumes only one cookie/parameter is described in the
    device tree. SYSTEM_RESET2 uses 2: one for the type and one for
    cookie.
 3. psci cpuidle driver already registers a driver against the
    arm,psci-1.0 compatible. Refactoring would be needed to have both a
    cpuidle and reboot-mode driver.

Link: https://lore.kernel.org/r/20250303-arm-psci-system_reset2-vendor-reboots-v9-2-b2cf4a20feda@oss.qualcomm.com
Signed-off-by: Elliot Berman <elliot.berman@oss.qualcomm.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
…or QUP SEs

Default pinctrl configurations for all QUP (Qualcomm Universal Peripheral)
Serial Engines (SEs) are missing in the SoC device tree. These
configurations are required by client teams when enabling any SEs as I2C,
SPI, or Serial protocols.

Add default pin configurations for Serial Engines (SEs) for all supported
protocols, including I2C, SPI, and UART, to the sa8775p device tree.  This
change facilitates slave device driver clients to enable usecase with
minimal modifications.

Remove duplicate pin configurations from target-specific file as same pin
configuration is included in the SoC device tree.

Link: https://lore.kernel.org/r/20250509090443.4107378-1-quic_vdadhani@quicinc.com
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Signed-off-by: Viken Dadhaniya <quic_vdadhani@quicinc.com>
…board

QCS9075 is compatible Industrial-IOT grade variant of SA8775p SOC.
Unlike QCS9100, it doesn't have safety monitoring feature of
Safety-Island(SAIL) subsystem, which affects thermal management.

qcs9075-iq-9075-evk board is based on QCS9075 SOC.

Link: https://lore.kernel.org/r/20250528122753.3623570-2-quic_wasimn@quicinc.com
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
…/qcs9075

SA8775P has a memory map which caters to the auto specific requirements.
QCS9100 & QCS9075 are its IOT variants (with marketing name as IQ9) which
inherit the memory map of SA8775P require a slightly different memory
map as compared to SA8775P auto parts.
This new memory map is applicable for all the IoT boards which inherit
the initial SA8775P memory map. This is not applicable for non-IoT
boards.

Some new carveouts (viz. gunyah_md and a few pil dtb carveouts) have been
introduced as part of firmware updates for IoT. The size and base address
have been updated for video PIL carveout compared to SA8775P since it is
being brought up for the first time on IoT boards. The base addresses
of the rest of the PIL carveouts have been updated to accommodate the
change in size of video since PIL regions are relocatable and their
functionality is not impacted due to this change. The size of camera
pil has also been increased without breaking any feature.

The size of trusted apps carveout has also been reduced since it is
sufficient to meet IoT requirements. Also, audio_mdf_mem & tz_ffi_mem
carveout and its corresponding scm reference has been removed as these
are not required for IoT parts.

Incorporate these changes in the updated memory map.

Link: https://lore.kernel.org/r/20250528122753.3623570-3-quic_wasimn@quicinc.com
Signed-off-by: Pratyush Brahma <quic_pbrahma@quicinc.com>
Signed-off-by: Prakash Gupta <quic_guptap@quicinc.com>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
QCS9075 is an IoT variant of SA8775P SOC, most notably without
safety monitoring feature of Safety Island(SAIL) subsystem.
Add qcs9075-som.dtsi to specifies QCS9075 based SOM having SOC,
PMICs, Memory-map updates.
Use this SOM for qcs9075-iq-9075-evk board.

Link: https://lore.kernel.org/r/20250528122753.3623570-4-quic_wasimn@quicinc.com
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
Add initial device tree support for IQ-9075-EVK board,
based on Qualcomm's QCS9075 SOC.

Implement basic features like uart/ufs to enable boot to shell.

Link: https://lore.kernel.org/r/20250528122753.3623570-5-quic_wasimn@quicinc.com
Co-developed-by: Rakesh Kota <quic_kotarake@quicinc.com>
Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com>
Co-developed-by: Sayali Lokhande <quic_sayalil@quicinc.com>
Signed-off-by: Sayali Lokhande <quic_sayalil@quicinc.com>
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
Return -ENOMEM if memremap() fails.  Don't return success.

Fixes: d19b163 ("media: iris: implement video firmware load/unload")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-media/4206de50-2970-a93b-867a-03ae6cdcedd3@quicinc.com/
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
In order to support the SM8650 iris33 hardware, we need to provide a
specific constoller power off sequences via the vpu_ops callbacks.

Add the callback, and use the current helper for currently supported
platforms.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-2-f020cb1d0e98@linaro.org/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
…t_tbl

Introduce an optional controller_rst_tbl use to store reset lines
used to reset part of the controller.

This is necessary for the vpu3 support, when the xo reset line
must be asserted separately from the other reset line
on power off operation.

Factor the iris_init_resets() logic to allow requesting
multiple reset tables.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-3-f020cb1d0e98@linaro.org/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The vpu33 HW is very close to vpu3, and shares most of the
operations, so rename file to vpu3x since we'll handle all vpu3
variants in it.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-4-f020cb1d0e98@linaro.org/
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The IRIS acceleration found in the SM8650 platforms uses the vpu33
hardware version, and requires a slighly different reset and power off
sequences in order to properly get out of runtime suspend.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-5-f020cb1d0e98@linaro.org/
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
…rm_gen2

In order to prepare for supporting the SM8650 SoC, move the
iris_platform_sm8550.c file into iris_platform_gen2.c that will
contain all the common HFI GEN2x structures.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-6-f020cb1d0e98@linaro.org/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add support for the SM8650 platform by re-using the SM8550
definitions and using the vpu33 ops.

Move the Sm8650 reset tables that differs in a per-SoC platform
header, that will contain mode SoC specific data when
more codecs are introduced.

The SM8650/vpu33 requires more reset lines, but the H.264
decoder capabilities are identical.

Link: https://lore.kernel.org/linux-media/20250417-topic-sm8x50-iris-v10-v7-7-f020cb1d0e98@linaro.org/
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Fix the order of compatible strings to make it in alpha numeric order.

Link: https://lore.kernel.org/linux-media/20250501-qcs8300_iris-v7-2-b229d5347990@quicinc.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add platform data for QCS8300, which has different capabilities compared
to SM8550. Introduce a QCS8300 header that defines these capabilities.

Link: https://lore.kernel.org/linux-media/20250501-qcs8300_iris-v7-3-b229d5347990@quicinc.com/
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add support for vadc and adc-tm channels which are used for
monitoring thermistors present on the platform.

- Add the necessary includes for qcom,spmi-adc7-pm7325 and
  qcom,spmi-adc7-pmk8350.
- Add thermal zones for quiet-thermal, sdm-skin-thermal, and
  xo-thermal, and define their polling delays and thermal sensors.
- Configure the pm7325_temp_alarm node to use the pmk8350_vadc
  channel for thermal monitoring.
- Configure the pmk8350_adc_tm node to enable its thermal sensors
  and define their registers and settings.
- Configure the pmk8350_vadc node to define its channels and settings

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250212113342.873086-1-quic_kotarake@quicinc.com
Signed-off-by: Rakesh Kota <quic_kotarake@quicinc.com>
Add the SPMI bus arbiter(Version:5.2.0) node for QCS8300 SoC
which connected with PMICs on QCS8300 boards.

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250108-adds-spmi-pmic-peripherals-for-qcs8300-v3-1-ee94642279ff@quicinc.com
Signed-off-by: Tingguo Cheng <quic_tingguoc@quicinc.com>
Enable PMIC and PMIC peripherals for qcs8300-ride board. The qcs8
300-ride uses 2 pmics(pmm8620au:0,pmm8650au:1) on the board, which
are variants of pmm8654au used on sa8775p/qcs9100 -ride(4x pmics).

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250108-adds-spmi-pmic-peripherals-for-qcs8300-v3-2-ee94642279ff@quicinc.com
Signed-off-by: Tingguo Cheng <quic_tingguoc@quicinc.com>
Add RTC node, the RTC is controlled by PMIC device via spmi bus.

Signed-off-by: Tingguo Cheng <quic_tingguoc@quicinc.com>
Link: https://lore.kernel.org/r/20240902104302.3959670-1-quic_tingguoc@quicinc.com
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
…d card

Document the bindings for the Qualcomm QCS9100 and QCS9075 board
specific sound card.

The bindings are the same as for other newer Qualcomm ADSP sound cards,
thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
is separate.

Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519083244.4070689-2-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
… QCS9075

Add compatibles for sound card on Qualcomm QCS9100 and
QCS9075 boards.

Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519083244.4070689-3-mohammad.rafi.shaik@oss.qualcomm.com
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
mohsRafi and others added 21 commits June 3, 2025 18:15
…lifier

Add nodes for WSA8830 speakers amplifier on qcs6490-rb3gen2 board.

Enable lpass_wsa and lpass_va macros along with pinctrl settings
for audio.

Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Link: https://lore.kernel.org/linux-arm-msm/20250527111227.2318021-6-quic_pkumpatl@quicinc.com/
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
Add the sound card node with tested playback over WSA8835 speakers
and digital on-board mics.

Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/linux-arm-msm/20250527111227.2318021-7-quic_pkumpatl@quicinc.com/
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
…9370 headset codec

Add nodes for WSA8830 speakers and WCD9370 headset codec
on qcm6490-idp board.

Enable lpass macros along with audio support pin controls.

Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Link: https://lore.kernel.org/linux-arm-msm/20250527111227.2318021-8-quic_pkumpatl@quicinc.com/
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
Add the sound card node with tested playback over WSA8835 speakers,
digital on-board mics along with wcd9370 headset playabck and record.

Co-developed-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Signed-off-by: Prasad Kumpatla <quic_pkumpatl@quicinc.com>
Link: https://lore.kernel.org/linux-arm-msm/20250527111227.2318021-9-quic_pkumpatl@quicinc.com/
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
Correct the ngpios entry to account for the UFS_RESET pin being exported
as a GPIO in addition to the real GPIOs, allowing the UFS driver to toggle
it.

Fixes: b698f36 ("pinctrl: qcom: add the tlmm driver for QCS615 platform")
Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/all/20241219-correct_gpio_ranges-v2-3-19af8588dbd0@quicinc.com/
Signed-off-by: Yuanjie Yang <quic_yuanjiey@quicinc.com>
… for qcs615

Correct the gpio-ranges in the QCS615 TLMM pin controller example to
include the UFS_RESET pin, which is expected to be wired to the reset
pin of the primary UFS memory. This allows the UFS driver to toggle it.

Link: https://lore.kernel.org/r/20250506-correct_gpio_ranges-v3-1-49a7d292befa@quicinc.com
Fixes: 55c487e ("dt-bindings: pinctrl: document the QCS615 Top Level Mode Multiplexer")
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com>
… for qcs8300

Correct the gpio-ranges in the QCS8300 TLMM pin controller example to
include the UFS_RESET pin, which is expected to be wired to the reset
pin of the primary UFS memory. This allows the UFS driver to toggle it.

Link: https://lore.kernel.org/r/20250506-correct_gpio_ranges-v3-2-49a7d292befa@quicinc.com
Fixes: 5778535 ("dt-bindings: pinctrl: describe qcs8300-tlmm")
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com>
Correct the ngpios entry to account for the UFS_RESET pin, which is
expected to be wired to the reset pin of the primary UFS memory and is
exported as GPIOs in addition to the real GPIOs, allowing the UFS driver
to toggle it.

Link: https://lore.kernel.org/r/20250506-correct_gpio_ranges-v3-4-49a7d292befa@quicinc.com
Fixes: 0c4cd2c ("pinctrl: qcom: add the tlmm driver for QCS8300 platforms")
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Lijuan Gao <quic_lijuang@quicinc.com>
Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
@sgaud-quic sgaud-quic force-pushed the qcom-next-staging branch from 34488e7 to 9cf98cf Compare June 3, 2025 14:44
@sgaud-quic sgaud-quic closed this Jun 4, 2025
@sgaud-quic sgaud-quic reopened this Jun 4, 2025
@sgaud-quic sgaud-quic closed this Jun 4, 2025
sgaud-quic added a commit that referenced this pull request Jun 24, 2025
sgaud-quic pushed a commit that referenced this pull request Sep 2, 2025
If we hit an error path in GEM obj creation before msm_gem_new_handle()
updates obj->resv to point to the gpuvm resv object, then obj->resv
still points to &obj->_resv.  In this case we don't want to decrement
the refcount of the object being freed (since the refcnt is already
zero).  This fixes the following splat:

   ------------[ cut here ]------------
   refcount_t: underflow; use-after-free.
   WARNING: CPU: 9 PID: 7013 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148
   Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_da>
    qcom_pil_info i2c_hid drm_kms_helper qcom_common qcom_q6v5 phy_snps_eusb2 qcom_geni_serial drm qcom_sysmon pinctrl_s>
   CPU: 9 UID: 1000 PID: 7013 Comm: deqp-vk Not tainted 6.16.0-rc4-debug+ #25 PREEMPT(voluntary)
   Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
   pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
   pc : refcount_warn_saturate+0xf4/0x148
   lr : refcount_warn_saturate+0xf4/0x148
   sp : ffff8000a2073920
   x29: ffff8000a2073920 x28: 0000000000000010 x27: 0000000000000010
   x26: 0000000000000042 x25: ffff000810e09800 x24: 0000000000000010
   x23: ffff8000a2073b94 x22: ffff000ddb22de00 x21: ffff000ddb22dc00
   x20: ffff000ddb22ddf8 x19: ffff0008024934e0 x18: 000000000000000a
   x17: 0000000000000000 x16: ffff9f8c67d77340 x15: 0000000000000000
   x14: 00000000ffffffff x13: 2e656572662d7265 x12: 7466612d65737520
   x11: 3b776f6c66726564 x10: 00000000ffff7fff x9 : ffff9f8c67506c70
   x8 : ffff9f8c69fa26f0 x7 : 00000000000bffe8 x6 : c0000000ffff7fff
   x5 : ffff000f53e14548 x4 : ffff6082ea2b2000 x3 : ffff0008b86ab080
   x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008b86ab080
   Call trace:
    refcount_warn_saturate+0xf4/0x148 (P)
    msm_gem_free_object+0x248/0x260 [msm]
    drm_gem_object_free+0x24/0x40 [drm]
    msm_gem_new+0x1c4/0x1e0 [msm]
    msm_gem_new_handle+0x3c/0x1a0 [msm]
    msm_ioctl_gem_new+0x38/0x70 [msm]
    drm_ioctl_kernel+0xc8/0x138 [drm]
    drm_ioctl+0x2c8/0x618 [drm]
    __arm64_sys_ioctl+0xac/0x108
    invoke_syscall.constprop.0+0x64/0xe8
    el0_svc_common.constprop.0+0x40/0xe8
    do_el0_svc+0x24/0x38
    el0_svc+0x54/0x1d8
    el0t_64_sync_handler+0x10c/0x138
    el0t_64_sync+0x19c/0x1a0
   irq event stamp: 3698694
   hardirqs last  enabled at (3698693): [<ffff9f8c675021dc>] __up_console_sem+0x74/0x90
   hardirqs last disabled at (3698694): [<ffff9f8c68ce8164>] el1_dbg+0x24/0x90
   softirqs last  enabled at (3697578): [<ffff9f8c6744ec5c>] handle_softirqs+0x454/0x4b0
   softirqs last disabled at (3697567): [<ffff9f8c67360244>] __do_softirq+0x1c/0x28
   ---[ end trace 0000000000000000 ]---

Fixes: b58e12a ("drm/msm: Add _NO_SHARE flag")
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/665355/
sgaud-quic pushed a commit that referenced this pull request Sep 2, 2025
submit_unpin_objects() should come before we unlock the objects.  This
fixes the splat:

   WARNING: CPU: 2 PID: 2171 at drivers/gpu/drm/msm/msm_gem.h:395 msm_gem_unpin_locked+0x8c/0xd8 [msm]
   Modules linked in: uinput snd_seq_dummy snd_hrtimer aes_ce_ccm snd_soc_wsa884x regmap_sdw q6prm_clocks q6apm_lpass_dais q6apm_dai snd_q6dsp_common q6prm snd_q6apm qcom_pd_mapper cdc_mbim cdc_wdm cdc_ncm r8153_ecm cdc_ether usbnet sunrpc nls_ascii nls_cp437 vfat fat snd_soc_x1e80100 snd_soc_lpass_rx_macro snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_wsa_macro snd_soc_qcom_common soundwire_qcom snd_soc_lpass_macro_common snd_soc_hdmi_codec snd_soc_qcom_sdw ext4 snd_soc_core snd_compress soundwire_bus snd_pcm_dmaengine snd_seq mbcache jbd2 snd_seq_device snd_pcm pm8941_pwrkey snd_timer r8152 qcom_spmi_temp_alarm industrialio snd lenovo_yoga_slim7x ath12k mii arm_smccc_trng soundcore rng_core evdev loop panel_samsung_atna33xc20 msm ubwc_config drm_client_lib drm_gpuvm drm_exec gpu_sched drm_display_helper pmic_glink_altmode aux_hpd_bridge ucsi_glink qcom_battmgr phy_qcom_qmp_combo ps883x cec aux_bridge drm_dp_aux_bus i2c_hid_of aes_ce_blk drm_kms_helper aes_ce_cipher i2c_hid qcom_q6v5_pas
    ghash_ce qcom_pil_info drm sha1_ce qcom_common phy_snps_eusb2 qcom_geni_serial qcom_q6v5 qcom_sysmon pinctrl_sm8550_lpass_lpi lpasscc_sc8280xp sbsa_gwdt mdt_loader gpio_keys pmic_glink i2c_dev efivarfs autofs4
   CPU: 2 UID: 1000 PID: 2171 Comm: gnome-shell Not tainted 6.16.0-rc4-debug+ #25 PREEMPT(voluntary)
   Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN53WW 08/02/2024
   pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
   pc : msm_gem_unpin_locked+0x8c/0xd8 [msm]
   lr : msm_gem_unpin_locked+0x88/0xd8 [msm]
   sp : ffff80009c963820
   x29: ffff80009c963820 x28: ffff80009c9639f8 x27: ffff00080552a830
   x26: 0000000000000000 x25: ffff0009d5655800 x24: 0000000000000000
   x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000
   x20: ffff000831db5480 x19: ffff000816e74400 x18: 0000000000000000
   x17: 0000000000000000 x16: ffffc1396afdd720 x15: 0000000000000000
   x14: 0000000000000000 x13: 0000000000000000 x12: ffff0008c065bc00
   x11: ffff0008c065c000 x10: 0000000000000000 x9 : ffffc13945b19074
   x8 : 0000000000000000 x7 : 0000000000000209 x6 : 0000000000000002
   x5 : 0000000000019d01 x4 : ffff0008ba8db080 x3 : 000000000004093f
   x2 : ffff3ed5e727f000 x1 : 0000000000000000 x0 : 0000000000000000
   Call trace:
    msm_gem_unpin_locked+0x8c/0xd8 [msm] (P)
    msm_ioctl_gem_submit+0x32c/0x1760 [msm]
    drm_ioctl_kernel+0xc8/0x138 [drm]
    drm_ioctl+0x2c8/0x618 [drm]
    __arm64_sys_ioctl+0xac/0x108
    invoke_syscall.constprop.0+0x64/0xe8
    el0_svc_common.constprop.0+0x40/0xe8
    do_el0_svc+0x24/0x38
    el0_svc+0x54/0x1d8
    el0t_64_sync_handler+0x10c/0x138
    el0t_64_sync+0x19c/0x1a0
   irq event stamp: 2185036
   hardirqs last  enabled at (2185035): [<ffffc1396afeef9c>] _raw_spin_unlock_irqrestore+0x74/0x80
   hardirqs last disabled at (2185036): [<ffffc1396afd8164>] el1_dbg+0x24/0x90
   softirqs last  enabled at (2184778): [<ffffc13969675e44>] fpsimd_restore_current_state+0x3c/0x328
   softirqs last disabled at (2184776): [<ffffc13969675e14>] fpsimd_restore_current_state+0xc/0x328
   ---[ end trace 0000000000000000 ]---

Fixes: 111fdd2 ("drm/msm: drm_gpuvm conversion")
Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
Patchwork: https://patchwork.freedesktop.org/patch/665357/
sgaud-quic pushed a commit that referenced this pull request Oct 15, 2025
…machine

After GPU reset with VRAM loss, a general protection fault occurs
during user queue restoration when accessing vm_bo->vm after
spinlock release in amdgpu_vm_bo_reset_state_machine.

The root cause is that vm_bo points to the last entry from the
list_for_each_entry loop, but this becomes invalid after the
spinlock is released. Accessing vm_bo->vm at this point leads
to memory corruption.

Crash log shows:
[  326.981811] Oops: general protection fault, probably for non-canonical address 0x4156415741e58ac8: 0000 [#1] SMP NOPTI
[  326.981820] CPU: 13 UID: 0 PID: 1035 Comm: kworker/13:3 Tainted: G            E       6.16.0+ #25 PREEMPT(voluntary)
[  326.981826] Tainted: [E]=UNSIGNED_MODULE
[  326.981827] Hardware name: Gigabyte Technology Co., Ltd. X870E AORUS PRO ICE/X870E AORUS PRO ICE, BIOS F3i 12/19/2024
[  326.981831] Workqueue: events amdgpu_userq_restore_worker [amdgpu]
[  326.981999] RIP: 0010:amdgpu_vm_assert_locked+0x16/0x70 [amdgpu]
[  326.982094] Code: 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 ff 74 45 48 8b 87 80 03 00 00 48 85 c0 74 40 <48> 8b b8 80 01 00 00 48 85 ff 74 3b 8b 05 0c b7 0e f0 85 c0 75 05
[  326.982098] RSP: 0018:ffffaa91c2a6bc20 EFLAGS: 00010206
[  326.982100] RAX: 4156415741e58948 RBX: ffff9e8f013e8330 RCX: 0000000000000000
[  326.982102] RDX: 0000000000000005 RSI: 000000001d254e88 RDI: ffffffffc144814a
[  326.982104] RBP: ffffaa91c2a6bc68 R08: 0000004c21a25674 R09: 0000000000000001
[  326.982106] R10: 0000000000000001 R11: dccaf3f2f82863fc R12: ffff9e8f013e8000
[  326.982108] R13: ffff9e8f013e8000 R14: 0000000000000000 R15: ffff9e8f09980000
[  326.982110] FS:  0000000000000000(0000) GS:ffff9e9e79995000(0000) knlGS:0000000000000000
[  326.982112] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  326.982114] CR2: 000055ed6c9caa80 CR3: 0000000797060000 CR4: 0000000000750ef0
[  326.982116] PKRU: 55555554

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.