The RSC interrupt is issued only after the request is complete. For
fire-n-forget requests, the irq-done interrupt is sent after issuing the
RPMH request and for response-required request, the interrupt is
triggered only after all the requests are complete.
These unnecessary checks in the interrupt handler issues AHB reads from
a critical path. Lets remove them and clean up error handling in
rpmh_request data structures.
Co-developed-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221116112246.2640648-2-abel.vesa@linaro.org
The next wakeup timer value needs to be set in always on domain timer
as the arch timer interrupt can not wakeup the SoC if after the deepest
CPUidle states the SoC also enters deepest low power state.
To wakeup the SoC in such scenarios the earliest wakeup time is set in
CONTROL_TCS and the firmware takes care of setting up its own timer in
always on domain with next wakeup time. The timer wakes up the RSC and
sets resources back to wake state.
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8450
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221018152837.619426-7-ulf.hansson@linaro.org
The arch timer cannot wake up the Qualcomm Technologies, Inc. (QTI) SoCs
from the deeper CPUidle states. To be able to wakeup from these deeper
states, another always-on timer needs to be programmed through the so
called CONTROL_TCS.
As the RSC is part of CPU subsystem and the corresponding APSS RSC device
is attached to the cluster PM domain (through genpd), it holds the
responsibility to program the always-on timer, before entering any of these
deeper CPUidle states.
However, programming the timer requires information about the next hrtimer
wakeup for the cluster PM domain, which is currently only known by genpd.
Therefore, let's share this data through a new genpd helper function,
dev_pm_genpd_get_next_hrtimer().
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
[Ulf: Reworked the code and updated the commit message]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8450
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221018152837.619426-5-ulf.hansson@linaro.org
RSC is part the CPU subsystem and powers off the CPU domains when all
the CPUs and no RPMH transactions are pending from any of the drivers.
The RSC needs to flush the 'sleep' and 'wake' votes that are critical
for saving power when all the CPUs are in idle.
Let's make RSC part of the CPU PM domains, by attaching it to the
cluster power domain. Registering for PM domain notifications, RSC
driver can be notified that the last CPU is powering down. When the last
CPU is powering down the domain, let's flush the 'sleep' and 'wake'
votes that are stored in the data buffers into the hardware and also
write next wakeup in CONTROL_TCS.
Signed-off-by: Lina Iyer <ilina@codeaurora.org>
Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # SM8450
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221018152837.619426-3-ulf.hansson@linaro.org
WLAN firmware uses SMP2P protocol in order to talk to the application
processor (AP) in certain cases like WoW (Wake on Wireless). WLAN
firmware runs on the WPSS Q6 processor (Wireless Processor SubSystem).
Therefore it is required to have sub nodes pertaining to the WPSS Q6
processor and the application processor in the SMP2P node.
Add WPSS Q6 (Wireless Processor SubSystem) node names to the pattern
property required for WPSS Q6 processor to communicate to the
application processor and vice versa over SMP2P protocol.
Signed-off-by: Manikanta Pubbisetty <quic_mpubbise@quicinc.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221017125346.3691-2-quic_mpubbise@quicinc.com
In some cases the hardware that the bootloader has left configured
depends on RPMH power domains for their operation up until the point
where the related Linux device driver probes and can inherit that
configuration, or power down the hardware gracefully.
Unfortunately as Linux probes the releavant drivers in sequence there
are periods during the Linux boot flow where either the genpd refcount
will reach 0, or worse where the active performance_state votes does not
meet the requirements of the state that the hardware was left in.
One specific example of this is during boot of e.g. SM8150/SC8180X,
where the display clock controller probes, without any particular
performance state needs (to access its registers). This will drop the
MMCX rail to MIN_SVS, which isn't sufficient to sustain the clock rates
that the later probing MDP is configured to. This results in an
unrecoverable system state.
Handle both these cases by keeping the RPMH power-domais that are
referenced voted for highest state, until sync_state indicates that all
devices referencing the RPMH power-domain driver has been probed.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Caleb Connolly <caleb@connolly.tech>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
[bjorn: Added print for sync_state errors]
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220915205559.14574-1-quic_bjorande@quicinc.com
The Qualcomm Resource Power Manager (RPM) over SMD bindings contain
compatibles and description for RPM devices on two different
communication channels: SMD and GLINK. Except the difference in the
parent node, they use different properties for describing name of
channel qcom,smd-channels or qcom,glink-channels. The first one is
already present but second is missing:
qcom/sm6125-sony-xperia-seine-pdx201.dtb: rpm-requests: 'qcom,glink-channels' does not match any of the regexes: '^regulators(-[01])?$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220926092104.111449-2-krzysztof.kozlowski@linaro.org
The Qualcomm SoC ID values are encoded in few places: DTS files,
Devicetree bindings (both used by some of Qualcomm bootloaders or tools)
and in soc_id table of socinfo driver. Do not duplicate the actual
values in the last one but use the constants from the bindings.
Tested by comparing output object file (exactly the same).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220830065744.161163-3-krzysztof.kozlowski@linaro.org
The top level qcom,msm-id and qcom,board-id properties are utilized by
bootloaders on Qualcomm MSM platforms to determine which device tree
should be used and passed to the kernel.
The commit b32e592d3c ("devicetree: bindings: Document qcom board
compatible format") from 2015 was a consensus during discussion about
upstreaming qcom,msm-id and qcom,board-id fields. There are however still
problems with that consensus:
1. It was reached 7 years ago but it turned out its implementation did
not reach all possible products.
2. Initially additional tool (dtbTool) was needed for parsing these
fields to create a QCDT image consisting of multiple DTBs, later the
bootloaders were improved and they use these qcom,msm-id and
qcom,board-id properties directly.
3. Extracting relevant information from the board compatible requires
this additional tool (dtbTool), which makes the build process more
complicated and not easily reproducible (DTBs are modified after the
kernel build).
4. Some versions of Qualcomm bootloaders expect these properties even
when booting with a single DTB. The community is stuck with these
bootloaders thus they require properties in the DTBs.
Since several upstreamed Qualcomm SoC-based boards require these
properties to properly boot and the properties are reportedly used by
bootloaders, document them along with the bindings header with constants
used by: bootloader, some DTS and socinfo driver.
Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/
Co-developed-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220830065744.161163-2-krzysztof.kozlowski@linaro.org
