-
Notifications
You must be signed in to change notification settings - Fork 20
Prepare qcom-next based on tag 'Linux 6.18-rc7' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
sgaud-quic
wants to merge
345
commits into
qualcomm-linux:qcom-next-staging
Choose a base branch
from
sgaud-quic:qcom-next-staging-6.18-rc7-20251201
base: qcom-next-staging
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
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
…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 <[email protected]> Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
…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 <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
…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 <[email protected]> Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
Document qcom,kaanapali-imem compatible. Reviewed-by: Eugen Hristev <[email protected]> Signed-off-by: Jingyi Wang <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
Add STM configs to enable STM functions, like stm ftrace and stm heartbeat. Signed-off-by: Jie Gan <[email protected]>
Update the documentation for RPMH clock controller for Kaanapali SoC. Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Taniya Das <[email protected]>
… Controller Add bindings documentation for TCSR Clock Controller for Kaanapali SoC. Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Taniya Das <[email protected]>
…ller Add device tree bindings for the global clock controller on Qualcomm Kaanapali platform. Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Taniya Das <[email protected]>
Add the RPMH clocks present in Kaanapali SoC. Signed-off-by: Jingyi Wang <[email protected]> Signed-off-by: Taniya Das <[email protected]>
Add the TCSR clock controller that provides the refclks on Kaanapali platform for PCIe, USB and UFS subsystems. Signed-off-by: Jingyi Wang <[email protected]> Signed-off-by: Taniya Das <[email protected]>
…pali Add support for Global clock controller for Kaanapali Qualcomm SoC. Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Taniya Das <[email protected]>
Add support for Kaanapali TLMM configuration and control via the pinctrl framework. Signed-off-by: Jingyi Wang <[email protected]> Reviewed-by: Bartosz Golaszewski <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
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 <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Yijie Yang <[email protected]> Link: https://lore.kernel.org/all/[email protected]/
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/[email protected]/
Signed-off-by: Songwei Chai <[email protected]>
Reviewed-by: Rob Herring (Arm) <[email protected]>
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/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
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/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
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/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
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/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
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/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
Add reset node to initialize the value of priority/condition_decode/condition_select/timer/counter nodes. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Songwei Chai <[email protected]>
Add Qualcomm extended CTI support in CTI binding file. Qualcomm extended CTI supports up to 128 triggers. Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Yingchao Deng <[email protected]> Signed-off-by: Mao Jinlong <[email protected]>
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/[email protected]/ Signed-off-by: Yingchao Deng <[email protected]> Signed-off-by: Mao Jinlong <[email protected]>
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/[email protected]/ Signed-off-by: Jie Gan <[email protected]>
…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/[email protected]/ Signed-off-by: Tao Zhang <[email protected]> Co-developed-by: Jie Gan <[email protected]> Signed-off-by: Jie Gan <[email protected]> Reviewed-by: James Clark <[email protected]>
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/[email protected]/ Signed-off-by: Tao Zhang <[email protected]> Co-developed-by: Jie Gan <[email protected]> Signed-off-by: Jie Gan <[email protected]> Reviewed-by: James Clark <[email protected]>
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/[email protected]/ Signed-off-by: Tao Zhang <[email protected]> Co-developed-by: Jie Gan <[email protected]> Signed-off-by: Jie Gan <[email protected]> Reviewed-by: James Clark <[email protected]>
…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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
# 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 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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