kernel/linux.git/drivers/soc/qcom/Makefile, branch v6.3

Merge branch '20230201041853.1934355-1-quic_bjorande@quicinc.com' into drivers-for-6.3

2023-02-04T19:01:06+00:00

soc: qcom: pmic_glink: Introduce altmode support

2023-02-04T18:56:16+00:00

With the PMIC GLINK service, the host OS subscribes to USB-C altmode messages, which are sent by the firmware to notify the host OS about state updates and HPD interrupts. The pmic_glink_altmode driver registers for these notifications and propagates the notifications as typec_mux, typec_switch and DRM OOB notifications as necessary to implement DisplayPort altmode support. Signed-off-by: Bjorn Andersson Acked-by: Neil Armstrong Tested-by: Konrad Dybcio # SM8350 PDX215 Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong # on SM8550-MTP & SM8450-HDK Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230201041853.1934355-4-quic_bjorande@quicinc.com

soc: qcom: pmic_glink: Introduce base PMIC GLINK driver

2023-02-04T18:54:30+00:00

The PMIC GLINK service runs on one of the co-processors of some modern Qualcomm platforms and implements USB-C and battery managements. It uses a message based protocol over GLINK for communication with the OS, hence the name. The driver implemented provides the rpmsg device for communication and uses auxiliary bus to spawn off individual devices in respective subsystem. The auxiliary devices are spawned off from a platform_device, so that the drm_bridge is available early, to allow the DisplayPort driver to probe even before the remoteproc has spun up. Signed-off-by: Bjorn Andersson Tested-by: Konrad Dybcio # SM8350 PDX215 Reviewed-by: Neil Armstrong Tested-by: Neil Armstrong # on SM8550-MTP & SM8450-HDK Signed-off-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230201041853.1934355-3-quic_bjorande@quicinc.com

soc: qcom: dcc: Drop driver for now

2023-01-31T02:30:54+00:00

Arnd asks for the DCC driver to be dropped for now, in order to allow for more thorough review, by a wider audience, of the ABI introduced. The Devicetree binding is adequately describing the hardware block, so this is kept. Requested-by: Arnd Bergmann Signed-off-by: Bjorn Andersson

soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)

2022-12-28T17:29:45+00:00

The DCC is a DMA Engine designed to capture and store data during system crash or software triggers. The DCC operates based on user inputs via the debugfs interface. The user gives addresses as inputs and these addresses are stored in the dcc sram. In case of a system crash or a manual software trigger by the user through the debugfs interface, the dcc captures and stores the values at these addresses. This patch contains the driver which has all the methods pertaining to the debugfs interface, auxiliary functions to support all the four fundamental operations of dcc namely read, write, read/modify/write and loop. The probe method here instantiates all the resources necessary for dcc to operate mainly the dedicated dcc sram where it stores the values. The DCC driver can be used for debugging purposes without going for a reboot since it can perform software triggers as well based on user inputs. Also add the documentation for debugfs entries which explains the functionalities of each debugfs file that has been created for dcc. The following is the justification of using debugfs interface over the other alternatives like sysfs/ioctls i) As can be seen from the debugfs attribute descriptions, some of the debugfs attribute files here contains multiple arguments which needs to be accepted from the user. This goes against the design style of sysfs. ii) The user input patterns have been made simple and convenient in this case with the use of debugfs interface as user doesn't need to shuffle between different files to execute one instruction as was the case on using other alternatives. Signed-off-by: Souradeep Chowdhury Reviewed-by: Alex Elder [bjorn: Fixed up a few indents and line wraps] Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/644b4f66a358492a8a6738454035c3b120092fe7.1672148732.git.quic_schowdhu@quicinc.com

soc: qcom: Add Qualcomm Ramp Controller driver

2022-12-27T19:26:52+00:00

The Ramp Controller is used to program the sequence ID for pulse swallowing, enable sequence and linking sequence IDs for the CPU cores on some Qualcomm SoCs. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221117132956.169432-3-angelogioacchino.delregno@collabora.com

soc: qcom: icc-bwmon: Add bandwidth monitoring driver

2022-07-06T20:57:51+00:00

Bandwidth monitoring (BWMON) sits between various subsytems like CPU, GPU, Last Level caches and memory subsystem. The BWMON can be configured to monitor the data throuhput between memory and other subsytems. The throughput is measured within specified sampling window and is used to vote for corresponding interconnect bandwidth. Current implementation brings support for BWMON v4, used for example on SDM845 to measure bandwidth between CPU (gladiator_noc) and Last Level Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth votes from cpufreq (CPU nodes) thus achieve high memory throughput even with lower CPU frequencies. The driver was tested on SDM845. Co-developed-by: Thara Gopinath Signed-off-by: Thara Gopinath Signed-off-by: Krzysztof Kozlowski Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220704121730.127925-3-krzysztof.kozlowski@linaro.org

soc: qcom: Add Sleep stats driver

2021-10-16T23:23:30+00:00

Let's add a driver to read the stats from remote processor and export to debugfs. The driver creates "qcom_sleep_stats" directory in debugfs and adds files for various low power mode available. Below is sample output with command cat /sys/kernel/debug/qcom_sleep_stats/ddr count = 0 Last Entered At = 0 Last Exited At = 0 Accumulated Duration = 0 Signed-off-by: Mahesh Sivasubramanian Signed-off-by: Lina Iyer [mkshah: add subsystem sleep stats, create one file for each stat] Signed-off-by: Maulik Shah Tested-by: Shawn Guo Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1634107104-22197-3-git-send-email-mkshah@codeaurora.org

cpuidle: qcom_spm: Detach state machine from main SPM handling

2021-09-21T22:41:48+00:00

In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver") the SPM driver has been converted to a generic CPUidle driver: that was mainly made to simplify the driver and that was a great accomplishment; Though, at that time, this driver was only applicable to ARM 32-bit SoCs, lacking logic about the handling of newer generation SAW. In preparation for the enablement of SPM features on AArch64/ARM64, split the cpuidle-qcom-spm driver in two: the CPUIdle related state machine (currently used only on ARM SoCs) stays there, while the SPM communication handling lands back in soc/qcom/spm.c and also making sure to not discard the simplifications that were introduced in the aforementioned commit. Since now the "two drivers" are split, the SCM dependency in the main SPM handling is gone and for this reason it was also possible to move the SPM initialization early: this will also make sure that whenever the SAW CPUIdle driver is getting initialized, the SPM driver will be ready to do the job. Please note that the anticipation of the SPM initialization was also done to optimize the boot times on platforms that have their CPU/L2 idle states managed by other means (such as PSCI), while needing SAW initialization for other purposes, like AVS control. Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Stephan Gerhold Tested-by: Stephan Gerhold Acked-by: Daniel Lezcano Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210729155609.608159-2-angelogioacchino.delregno@somainline.org

PM: AVS: qcom-cpr: Move the driver to the qcom specific drivers

2020-10-22T16:38:21+00:00

The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory, mostly to keep similar functionality together. From a maintenance point of view, it makes better sense to collect SoC specific drivers like these, into the SoC specific directories. Therefore, let's move the qcom-cpr driver to the qcom directory. Signed-off-by: Ulf Hansson Acked-by: Bjorn Andersson Acked-by: Niklas Cassel Signed-off-by: Rafael J. Wysocki