soc: qcom: Add RPM processor/subsystem driver

Add a simple driver for the qcom,rpm-proc compatible that registers the
"smd-edge" and populates other children defined in the device tree.

Note that t

soc: qcom: Add RPM processor/subsystem driver

Add a simple driver for the qcom,rpm-proc compatible that registers the
"smd-edge" and populates other children defined in the device tree.

Note that the DT schema belongs to the remoteproc subsystem while this
driver is added inside soc/qcom. I argue that the RPM *is* a remoteproc,
but as an implementation detail in Linux it can currently not benefit
from anything provided by the remoteproc subsystem. The RPM firmware is
usually already loaded and started by earlier components in the boot
chain and is not meant to be ever restarted.

To avoid breaking existing kernel configurations the driver is always
built when smd-rpm.c is also built. They belong closely together anyway.
To avoid build errors CONFIG_RPMSG_QCOM_SMD must be also built-in if
rpm-proc is.

Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-9-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

show more ...

soc: qcom: Introduce RPM master stats driver

Introduce a driver to query and expose detailed, per-subsystem (as opposed
to the existing qcom_stats driver which exposes SoC-wide data) about low
power

soc: qcom: Introduce RPM master stats driver

Introduce a driver to query and expose detailed, per-subsystem (as opposed
to the existing qcom_stats driver which exposes SoC-wide data) about low
power mode states of a given RPM master. That includes the APSS (ARM),
MPSS (modem) and other remote cores, depending on the platform
configuration.

This is a vastly cleaned up and restructured version of a similar
driver found in msm-5.4.

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230405-topic-master_stats-v6-2-2277b4433748@linaro.org

show more ...

soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver

This takes the already existing duplicated support in both ufs-qcom
and sdhci-msm drivers and makes it a dedicated driver that can be use

soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver

This takes the already existing duplicated support in both ufs-qcom
and sdhci-msm drivers and makes it a dedicated driver that can be used
by both mentioned drivers.

The reason for this is because, staring with SM8550, the ICE IP block
is shared between UFS and SDCC, which means we need to probe a dedicated
device and share it between those two consumers.

So let's add the ICE dedicated driver as a soc driver.

Platforms that already have ICE supported, will use it as a library
as the of_qcom_ice_get will return an ICE instance created for the
consumer device. This allows the backwards compatibility with old-style
devicetree approach.

Also, add support to HW version 4.x since it works out-of-the-box with
the current driver. The 4.x HW version is found on SM8550 platform.

Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230407105029.2274111-4-abel.vesa@linaro.org

show more ...

soc: qcom: restrict L2 accessors to ARM64 build tests

The QCOM_KRYO_L2_ACCESSORS can be compile tested only on ARM64 because
it references asm/sysreg.h present only on ARM64. Mark the dependency
co

soc: qcom: restrict L2 accessors to ARM64 build tests

The QCOM_KRYO_L2_ACCESSORS can be compile tested only on ARM64 because
it references asm/sysreg.h present only on ARM64. Mark the dependency
correct, even though as a non-selectable option it does not have real
effect.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230123202601.1296983-1-krzysztof.kozlowski@linaro.org

show more ...

soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies

QMI is a network protocol, so anything using requires CONFIG_NET
to be enabled as well:

WARNING: unmet direct dependencies detected for

soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies

QMI is a network protocol, so anything using requires CONFIG_NET
to be enabled as well:

WARNING: unmet direct dependencies detected for QCOM_QMI_HELPERS
Depends on [n]: NET [=n]
Selected by [m]:
- QCOM_PDR_HELPERS [=m]
arm-linux-gnueabi-ld: drivers/soc/qcom/qmi_interface.o: in function `qmi_send_new_lookup':
qmi_interface.c:(.text+0xf0): undefined reference to `kernel_sendmsg'

Add the dependency to both QCOM_PDR_HELPERS and QCOM_PMIC_GLINK to make
it clearly what the dependency is when another PDR user is added.

pmic_glink also needs CONFIG_OF:

drivers/soc/qcom/pmic_glink_altmode.c: In function 'pmic_glink_altmode_probe':
drivers/soc/qcom/pmic_glink_altmode.c:418:33: error: 'struct drm_bridge' has no member named 'of_node'

Fixes: 58ef4ece1e41 ("soc: qcom: pmic_glink: Introduce base PMIC GLINK driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230206193804.191343-1-arnd@kernel.org

show more ...

soc: qcom: pmic_glink: Introduce base PMIC GLINK driver

The PMIC GLINK service runs on one of the co-processors of some modern
Qualcomm platforms and implements USB-C and battery managements. It use

soc: qcom: pmic_glink: Introduce base PMIC GLINK driver

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 <bjorn.andersson@linaro.org>
Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM8350 PDX215
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-MTP & SM8450-HDK
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230201041853.1934355-3-quic_bjorande@quicinc.com

show more ...

soc: qcom: dcc: Drop driver for now

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 bindin

soc: qcom: dcc: Drop driver for now

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 <arnd@arndb.de>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

show more ...

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

The DCC is a DMA Engine designed to capture and store data
during system crash or software triggers. The DCC operates
based

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

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 <quic_schowdhu@quicinc.com>
Reviewed-by: Alex Elder <elder@linaro.org>
[bjorn: Fixed up a few indents and line wraps]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/644b4f66a358492a8a6738454035c3b120092fe7.1672148732.git.quic_schowdhu@quicinc.com

show more ...

soc: qcom: Add Qualcomm Ramp Controller driver

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 Qualcom

soc: qcom: Add Qualcomm Ramp Controller driver

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 <angelogioacchino.delregno@collabora.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221117132956.169432-3-angelogioacchino.delregno@collabora.com

show more ...

soc: qcom: Select REMAP_MMIO for ICC_BWMON driver

ICC_BWMON driver uses REGMAP_MMIO for accessing the hardware registers.
So select the dependency in Kconfig. Without this, there will be errors
whil

soc: qcom: Select REMAP_MMIO for ICC_BWMON driver

ICC_BWMON driver uses REGMAP_MMIO for accessing the hardware registers.
So select the dependency in Kconfig. Without this, there will be errors
while building the driver with COMPILE_TEST only:

ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/soc/qcom/icc-bwmon.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:126: Module.symvers] Error 1
make: *** [Makefile:1944: modpost] Error 2

Cc: <stable@vger.kernel.org> # 6.0
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Fixes: b9c2ae6cac40 ("soc: qcom: icc-bwmon: Add bandwidth monitoring driver")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221129072022.41962-1-manivannan.sadhasivam@linaro.org

show more ...

soc: qcom: Select REMAP_MMIO for LLCC driver

LLCC driver uses REGMAP_MMIO for accessing the hardware registers. So
select the dependency in Kconfig. Without this, there will be errors
while building

soc: qcom: Select REMAP_MMIO for LLCC driver

LLCC driver uses REGMAP_MMIO for accessing the hardware registers. So
select the dependency in Kconfig. Without this, there will be errors
while building the driver with COMPILE_TEST only:

ERROR: modpost: "__devm_regmap_init_mmio_clk" [drivers/soc/qcom/llcc-qcom.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:126: Module.symvers] Error 1
make: *** [Makefile:1944: modpost] Error 2

Cc: <stable@vger.kernel.org> # 4.19
Fixes: a3134fb09e0b ("drivers: soc: Add LLCC driver")
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221129071201.30024-2-manivannan.sadhasivam@linaro.org

show more ...

soc: qcom: Make QCOM_RPMPD depend on OF

WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS_OF
Depends on [n]: PM_GENERIC_DOMAINS [=y] && OF [=n]
Selected by [m]:
- QCOM_RPMPD [

soc: qcom: Make QCOM_RPMPD depend on OF

WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS_OF
Depends on [n]: PM_GENERIC_DOMAINS [=y] && OF [=n]
Selected by [m]:
- QCOM_RPMPD [=m] && PM [=y] && QCOM_SMD_RPM [=m]

PM_GENERIC_DOMAINS_OF depends on OF, so QCOM_RPMPD also depends on it.

Fixes: 7d0221fb5912 ("soc/qcom: Make QCOM_RPMPD select PM_GENERIC_DOMAINS/_OF")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220820113202.23940-1-yuehaibing@huawei.com

show more ...

soc: qcom: Make QCOM_RPMPD depend on PM

QCOM_RPMPD requires PM_GENERIC_DOMAINS/_OF, which in turns requires
CONFIG_PM. I forgot about the latter in my earlier patch (it's still
in -next as of the ti

soc: qcom: Make QCOM_RPMPD depend on PM

QCOM_RPMPD requires PM_GENERIC_DOMAINS/_OF, which in turns requires
CONFIG_PM. I forgot about the latter in my earlier patch (it's still
in -next as of the time of committing, hence no Fixes: tag). Fix it.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707212158.32684-1-konrad.dybcio@somainline.org

show more ...

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

Bandwidth monitoring (BWMON) sits between various subsytems like CPU,
GPU, Last Level caches and memory subsystem. The BWMON can be
configured

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

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 <thara.gopinath@gmail.com>
Signed-off-by: Thara Gopinath <thara.gopinath@gmail.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220704121730.127925-3-krzysztof.kozlowski@linaro.org

show more ...

soc/qcom: Make QCOM_RPMPD select PM_GENERIC_DOMAINS/_OF

The driver uses generic genpd OF APIs and with a very minimal config
where nothing else selects them, this driver will not probe, as
of_genpd_

soc/qcom: Make QCOM_RPMPD select PM_GENERIC_DOMAINS/_OF

The driver uses generic genpd OF APIs and with a very minimal config
where nothing else selects them, this driver will not probe, as
of_genpd_add_provider_onecell will return -EOPNOTSUPP.

Make sure to select these in Kconfig to prevent that.

Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220701073700.17124-1-konrad.dybcio@somainline.org

show more ...

qcom: spm: allow compile-testing

ARM_QCOM_SPM_CPUIDLE can be selected when compile-testing on
other architectures, but this causes a Kconfig warning
for QCOM_SPM:

WARNING: unmet direct dependencies

qcom: spm: allow compile-testing

ARM_QCOM_SPM_CPUIDLE can be selected when compile-testing on
other architectures, but this causes a Kconfig warning
for QCOM_SPM:

WARNING: unmet direct dependencies detected for QCOM_SPM
Depends on [n]: ARCH_QCOM [=n]
Selected by [y]:
- ARM_QCOM_SPM_CPUIDLE [=y] && CPU_IDLE [=y] && (ARM [=y] || ARM64) && (ARCH_QCOM [=n] || COMPILE_TEST [=y]) && !ARM64 && MMU [=y]

Make it possible to also compile-test this one, which can
be done now that v5.15-rc5 lets you select QCOM_SCM everywhere.

Fixes: a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver")
Fixes: 498ba2a8a275 ("cpuidle: Fix ARM_QCOM_SPM_CPUIDLE configuration")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

soc: qcom: Add Sleep stats driver

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 var

soc: qcom: Add Sleep stats driver

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 <msivasub@codeaurora.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
[mkshah: add subsystem sleep stats, create one file for each stat]
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1634107104-22197-3-git-send-email-mkshah@codeaurora.org

show more ...

soc: qcom: apr: Add GPR support

Qualcomm Generic Packet router aka GPR is the IPC mechanism found
in AudioReach next generation signal processing framework to perform
command and response messages b

soc: qcom: apr: Add GPR support

Qualcomm Generic Packet router aka GPR is the IPC mechanism found
in AudioReach next generation signal processing framework to perform
command and response messages between various processors.

GPR has concepts of static and dynamic port, all static services like
APM (Audio Processing Manager), PRM (Proxy resource manager) have
fixed port numbers where as dynamic services like graphs have dynamic
port numbers which are allocated at runtime. All GPR packet messages
will have source and destination domain and port along with opcode
and payload.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210927135559.738-6-srinivas.kandagatla@linaro.org

show more ...

cpuidle: qcom_spm: Detach state machine from main SPM handling

In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic
CPUidle driver") the SPM driver has been converted to a
gene

cpuidle: qcom_spm: Detach state machine from main SPM handling

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 <angelogioacchino.delregno@somainline.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Tested-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210729155609.608159-2-angelogioacchino.delregno@somainline.org

show more ...

soc: qcom: Make QCOM_RPMPD depend on PM

[ Upstream commit a6232f2aa99ce470799992e99e0012945bb5308f ]

QCOM_RPMPD requires PM_GENERIC_DOMAINS/_OF, which in turns requires
CONFIG_PM. I forgot about th

soc: qcom: Make QCOM_RPMPD depend on PM

[ Upstream commit a6232f2aa99ce470799992e99e0012945bb5308f ]

QCOM_RPMPD requires PM_GENERIC_DOMAINS/_OF, which in turns requires
CONFIG_PM. I forgot about the latter in my earlier patch (it's still
in -next as of the time of committing, hence no Fixes: tag). Fix it.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220707212158.32684-1-konrad.dybcio@somainline.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

soc: qcom: Kconfig: make RPMH match Command DB setting

RPMH and drivers that use RPMH APIs need Command DB API to find the
dynamic resource information. Let's match the RPMH to match the Command
DB

soc: qcom: Kconfig: make RPMH match Command DB setting

RPMH and drivers that use RPMH APIs need Command DB API to find the
dynamic resource information. Let's match the RPMH to match the Command
DB configuration.

This should fix undefined symbol references reported by CI :

aarch64-linux-ld: drivers/clk/qcom/clk-rpmh.o: in function `clk_rpmh_probe':
>> clk-rpmh.c:(.text+0xac): undefined reference to `cmd_db_read_addr'
>> aarch64-linux-ld: clk-rpmh.c:(.text+0xc0): undefined reference to `cmd_db_read_aux_data'
aarch64-linux-ld: drivers/soc/qcom/rpmh-rsc.o: in function `rpmh_rsc_probe':
>> rpmh-rsc.c:(.text+0x42c): undefined reference to `cmd_db_ready'
aarch64-linux-ld: drivers/regulator/qcom-rpmh-regulator.o: in function `rpmh_regulator_probe':
>> qcom-rpmh-regulator.c:(.text+0x3e0): undefined reference to `cmd_db_read_addr'

Cc: Todd Kjos <tkjos@google.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Maulik Shah <mkshah@codeaurora.org>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Link: https://lore.kernel.org/r/20201008040907.7036-1-ilina@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

soc: qcom: cmd-db: allow loading as a module

This patch enables Command DB driver to be loaded as a module. Command
DB is inherent to RPMH interaction and as such would never be unloaded.
Add supres

soc: qcom: cmd-db: allow loading as a module

This patch enables Command DB driver to be loaded as a module. Command
DB is inherent to RPMH interaction and as such would never be unloaded.
Add supress_bind_attrs to make it a permanently loaded module.

Reviewed-by: John Stultz <john.stultz@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Link: https://lore.kernel.org/r/20201001154144.5226-1-ilina@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

soc: qcom: rpmh: Allow RPMH driver to be loaded as a module

This patch allow the rpmh driver to be loaded as a permenent
module. Meaning it can be loaded from a module, but then cannot
be unloaded.

soc: qcom: rpmh: Allow RPMH driver to be loaded as a module

This patch allow the rpmh driver to be loaded as a permenent
module. Meaning it can be loaded from a module, but then cannot
be unloaded.

Ideally, it would include a remove hook and related logic, but
the rpmh driver is fairly core to the system, so once its loaded
with almost anything else to get the system to go, the dependencies
are not likely to ever also be removed.

So making it a permanent module at least improves things slightly
over requiring it to be a built in driver.

Cc: Todd Kjos <tkjos@google.com>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[mkshah: Fix typos in commit message, send after removing _rcuidle trace]
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1601877596-32676-3-git-send-email-mkshah@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

show more ...

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

The avs drivers are all SoC specific drivers that doesn't share any code.
Instead they are located in a directory, mostly to keep simi

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

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 <ulf.hansson@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Niklas Cassel <nks@flawful.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

show more ...

soc: qcom: Separate kryo l2 accessors from PMU driver

The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driv

soc: qcom: Separate kryo l2 accessors from PMU driver

The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driver and
making it public to allow other drivers use it.
The accesses must be separated with a single spinlock,
maintained in this driver.

Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Link: https://lore.kernel.org/r/1593766185-16346-2-git-send-email-loic.poulain@linaro.org
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>

show more ...