Prepare qcom-next based on tag 'Linux 6.18-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git#114
Closed
sgaud-quic wants to merge 345 commits intoqualcomm-linux:qcom-next-stagingfrom
Conversation
…and Glymur Platforms Document the Inter-Processor Communication Controller on the Qualcomm Kaanapali and Glymur Platforms, which will be used to route interrupts across various subsystems found on the SoC. Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251031-knp-ipcc-v3-1-62ffb4168dff@oss.qualcomm.com/
…IDs on Kaanapali platform On earlier platforms, Inter Process Communication Controller (IPCC) used virtual client IDs and performed virtual-to-physical mapping in hardware, so the IDs defined in dt-bindings/mailbox/qcom-ipcc.h are common across platforms. Physical client IDs instead of virtual client IDs are used for qcom new platforms like Kaanapali, which will be parsed by the devicetree and passed to hardware to use Physical client IDs directly. Since physical client IDs could vary across platforms, add a corresponding header file for the Kaanapali platform. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251031-knp-ipcc-v3-2-62ffb4168dff@oss.qualcomm.com/
…IDs on Glymur platform Physical client IDs are used on Glymur Inter Process Communication Controller (IPCC), add a corresponding header file. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251031-knp-ipcc-v3-3-62ffb4168dff@oss.qualcomm.com/
Document qcom,kaanapali-imem compatible. Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251022-knp-soc-binding-v2-1-3cd3f390f3e2@oss.qualcomm.com/
Add STM configs to enable STM functions, like stm ftrace and stm heartbeat. Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Update the documentation for RPMH clock controller for Kaanapali SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
… Controller Add bindings documentation for TCSR Clock Controller for Kaanapali SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…ller Add device tree bindings for the global clock controller on Qualcomm Kaanapali platform. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add the RPMH clocks present in Kaanapali SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add the TCSR clock controller that provides the refclks on Kaanapali platform for PCIe, USB and UFS subsystems. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
…pali Add support for Global clock controller for Kaanapali Qualcomm SoC. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Add support for Kaanapali TLMM configuration and control via the pinctrl framework. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250924-knp-tlmm-v1-2-acabb59ae48c@oss.qualcomm.com/
The Top Level Mode Multiplexer (TLMM) in the Kaanapali SoC provide GPIO and pinctrl functionality for UFS, SDC and 217 GPIO pins. Add a DeviceTree binding to describe the Kaanapali TLMM block. Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20250924-knp-tlmm-v1-1-acabb59ae48c@oss.qualcomm.com/
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/20250709104114.22240-2-songchai@qti.qualcomm.com/
Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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/20250709104114.22240-3-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
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/20250709104114.22240-4-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
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/20250709104114.22240-5-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
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/20250709104114.22240-6-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
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/20250709104114.22240-7-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
Add reset node to initialize the value of priority/condition_decode/condition_select/timer/counter nodes. Link: https://lore.kernel.org/all/20250709104114.22240-8-songchai@qti.qualcomm.com/ Signed-off-by: Songwei Chai <quic_songchai@quicinc.com>
Add Qualcomm extended CTI support in CTI binding file. Qualcomm extended CTI supports up to 128 triggers. Link: https://lore.kernel.org/all/20250722081405.2947294-2-quic_jinlmao@quicinc.com/ Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com> Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
The QCOM extended CTI is a heavily parameterized version of ARM’s CSCTI. It allows a debugger to send to trigger events to a processor or to send a trigger event to one or more processors when a trigger event occurs on another processor on the same SoC, or even between SoCs. For Qualcomm extended CTI, it supports up to 128 triggers. Link: https://lore.kernel.org/all/20250722081405.2947294-3-quic_jinlmao@quicinc.com/ Signed-off-by: Yingchao Deng <quic_yingdeng@quicinc.com> Signed-off-by: Mao Jinlong <quic_jinlmao@quicinc.com>
The static TPDM function as a dummy source, however, it is essential to enable the port connected to the TPDA and configure the element size. Without this, the TPDA cannot correctly receive trace data from the static TPDM. Since the static TPDM does not require MMIO mapping to access its registers, a clock controller is not mandatory for its operation. Link: https://lore.kernel.org/all/20250822103008.1029-3-jie.gan@oss.qualcomm.com/ Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
…figuration Introduce sysfs nodes to configure cross-trigger parameters for TPDA. These registers define the characteristics of cross-trigger packets, including generation frequency and flag values. Link: https://lore.kernel.org/all/20250827105545.7140-2-jie.gan@oss.qualcomm.com/ Signed-off-by: Tao Zhang <tao.zhang@oss.qualcomm.com> Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: James Clark <james.clark@linaro.org>
The TPDA_SYNCR register defines the frequency at which TPDA generates ASYNC packets, enabling userspace tools to accurately parse each valid packet. Link: https://lore.kernel.org/all/20250827105545.7140-3-jie.gan@oss.qualcomm.com/ Signed-off-by: Tao Zhang <tao.zhang@oss.qualcomm.com> Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: James Clark <james.clark@linaro.org>
Setting bit i in the TPDA_FLUSH_CR register initiates a flush request for port i, forcing the data to synchronize and be transmitted to the sink device. Link: https://lore.kernel.org/all/20250827105545.7140-4-jie.gan@oss.qualcomm.com/ Signed-off-by: Tao Zhang <tao.zhang@oss.qualcomm.com> Co-developed-by: Jie Gan <jie.gan@oss.qualcomm.com> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com> Reviewed-by: James Clark <james.clark@linaro.org>
…licator support Add the following compatible strings to the bindings: - arm,coresight-cpu-funnel - arm,coresight-cpu-replicator - arm,coresight-cpu-tmc Each requires 'power-domains' when used. Link: https://lore.kernel.org/all/20251027-cpu_cluster_component_pm-v1-1-31355ac588c2@oss.qualcomm.com/ Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
The CPU cluster funnel is a type of CoreSight funnel that resides inside the CPU cluster's power domain. Unlike dynamic funnels, CPU funnels are coupled with CPU clusters and share their power management characteristics. When the CPU cluster enters low-power mode (LPM), the funnel's registers become inaccessible. Moreover, runtime PM operations alone cannot bring the CPU cluster out of LPM, making standard register access unreliable. This patch enhances the existing CoreSight funnel platform driver to support CPU cluster funnels by: - Add cpumask to funnel_drvdata to store CPU cluster's mask for CPU cluster funnel. - Retrieving the associated CPU cluster's cpumask from the power domain. - Using smp_call_function_single() to do clear self claim tag operation. - Refactoring funnel_enable function. For cluster funnels, use smp_call_function_single() to ensure register visibility. - Encapsulating coresight registration in funnel_add_coresight_dev(). - Reusing the existing platform driver infrastructure to minimize duplication and maintain compatibility with static funnel devices. This ensures funnel operations are safe and functional even when the CPU cluster is in low-power mode. Link: https://lore.kernel.org/all/20251027-cpu_cluster_component_pm-v1-2-31355ac588c2@oss.qualcomm.com/ Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
Delay probe the cpu cluster funnel when all CPUs of this cluster are offline, re-probe the funnel when any CPU in the cluster comes online. Key changes: - Introduce a global list to track delayed funnels waiting for CPU online. - Add CPU hotplug callback to retry registration when the CPU comes up. Link: https://lore.kernel.org/all/20251027-cpu_cluster_component_pm-v1-3-31355ac588c2@oss.qualcomm.com/ Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
The CPU cluster replicator is a type of CoreSight replicator that resides inside the CPU cluster's power domain. Unlike system-wide replicators, CPU replicators are tightly coupled with CPU clusters and inherit their power management characteristics. When the CPU cluster enters low-power mode (LPM), the replicator registers become inaccessible. Moreover, runtime PM alone cannot bring the CPU cluster out of LPM, making standard register access unreliable. This patch enhances the existing CoreSight replicator platform driver to support CPU cluster replicators by: - Adding replicator_claim/disclaim_device_unlocked() to handle device claim/disclaim before CoreSight device registration. - Wrapping replicator_reset and clear_clear_tag in replicator_init_hw. For cluster replicators, use smp_call_function_single() to ensure register visibility. - Encapsulating csdev registration in replicator_add_coresight_dev(). - Refactoring replicator_enable function. For cluster replicators, use smp_call_function_single() to ensure register visibility. - Maintaining compatibility with existing static/dynamic replicators while minimizing duplication. This ensures replicator operations remain safe and functional even when the CPU cluster is in low-power states. Link: https://lore.kernel.org/all/20251027-cpu_cluster_component_pm-v1-4-31355ac588c2@oss.qualcomm.com/ Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # include/linux/firmware/qcom/qcom_scm.h
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Name SHA Commits
tech/bsp/clk aea4f0c 8
tech/bsp/interconnect 938409e 2
tech/security/firmware-smc 829c78b 1
tech/bsp/soc-infra 07ec4c1 17
tech/bsp/pinctrl 9a297f4 2
tech/bsp/remoteproc 8069134 12
tech/bus/pci/all 4490847 7
tech/bus/pci/pwrctl c36944e 7
tech/bus/usb/dwc c29f570 1
tech/debug/eud eb36d9d 1
tech/debug/hwtracing 9616409 34
tech/pmic/misc 2803dee 8
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu fc1b59c 1
tech/mm/audio/all 5534191 2
tech/mm/camss d1d2c38 3
tech/mm/drm 0d74e43 39
tech/mm/fastrpc dba4eb2 3
tech/mm/video 1af1bf9 13
tech/mm/gpu 229115a 4
tech/net/eth c280d7e 1
tech/net/bluetooth b5902f2 2
tech/pm/pmdomain c2e58ee 3
tech/pm/power 9fe45cf 7
tech/security/crypto 0ff2ae7 11
tech/security/ice e614034 3
tech/storage/all ba8c93d 6
tech/all/dt/qcs6490 91a5f25 7
tech/all/dt/qcs9100 ae04b95 15
tech/all/dt/qcs8300 32998bb 26
tech/all/dt/qcs615 ac047bf 8
tech/all/dt/hamoa 85bf4e6 7
tech/all/dt/kaanapali 746a202 3
tech/all/dt/pakala e0326f1 4
tech/all/config 60f0286 25
tech/overlay/dt 03e0b7b 5
tech/all/workaround 841239d 3