Now that the CPR v3/v4/Hardened is ready and the cpufreq-hw driver
got OSM programming, we can finally enable CPU scaling on both
of the clusters on SDM630.
The driver was updated to add SAW2 v4.1 support for new SoCs: document
the new compatibles.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Add the SAWv4.1 parameters for MSM8998's Gold and Silver clusters.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Implement the support for SAW v4.1, used in at least MSM8998,
SDM630, SDM660 and APQ variants and, while at it, also add the
configuration for the SDM630/660 Silver and Gold cluster L2
Adaptive Voltage Scaler: this is also one of the prerequisites
to allow the OSM controller to perform DCVS.
Please note that despite there are various "versions" of these
values downstream, these are the only ones that are perfectly
stable on the entire set of tested devices.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Add devicetree binding for Qualcomm Subsystem Power Manager (SPM).
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
In commit a871be6b8e ("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>
Some IOMMU context banks are secured and any attempt to disable them
during arm-smmu initialization will result in a system crash.
To work around this issue, add a list of context banks that will never
be disabled, but only reconfigured, at initialization time.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Avoid modifying the contents of the secure Auxiliary Control Register
on some Qualcomm SoCs: due to a hypervisor configuration on some
firmware versions, this would result in a system crash.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Some Qualcomm SoCs' TZ/hypervisor configuration is disallowing the
disablement of some context banks, being them used for tzapps and/or
remote processors; any attempt to disable such CBs will result in
triggering a fault and the system will freeze and/or reset.
For this reason, get a list of context banks that should never get
disabled during smmu initialization through a DT array property
`qcom,reset-nodisable-cbs`.
It was chosen to not hardcode the CBs as this is dependant on the
SoC's firmware, which may vary on different boards.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
On some SoCs some IOMMU context banks are actively used from TZ
during system boot, or some hypervisor configurations will trigger
a system reset upon disabling some protected/secured CBs.
Allow skipping the disablement of such contexts at IOMMU reset time
during initialization with a new implementation detail to work around
this quirk.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
It cannot be taken for granted that the last IOMMU context is free
and available for us to use it to emulate bypass streams and, at least
on MSM8998's lpass iommu, using the last one will produce a crash;
please note that this may not be only dependant on the SoC, but also
on the firmware version.
To overcome to this issue, allow specifying a different context for
bypass emulation with the optional DT property "qcom,bypass-cbndx":
if this property is not found this means that we are either booting
with ACPI instead or that we don't want to specify a custom cb because
the default one (the last context bank) is fine.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
The db820c has 4 "user LEDs", all connected to the PMI8994. The first
three are connected to the three current sinks provided by the TRILED
and the fourth is connected to MPP2.
By utilizing the DTEST bus the MPP is fed the control signal from the
fourth LPG block, providing a consistent interface to the user.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The DB845c has 4 "user LEDs", the last one is already supported as it's
just wired to a gpio. Now that the LPG binding is in place we can wire
up the other 3 LEDs as well.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
PMICs from Qualcomm. It can operate on fixed parameters or based on a
lookup-table, altering the duty cycle over time - which provides the
means for e.g. hardware assisted transitions of LED brightness.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This adds the binding document describing the three hardware blocks
related to the Light Pulse Generator found in a wide range of Qualcomm
PMICs.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
`last_repeat` holds the actual value requested by the user whereas
`repeat` is a software iteration variable that is unused in hardware
patterns.
Furthermore `last_repeat` is the field returned to the user when reading
the `repeat` sysfs property. This field is initialized to `-1` which is
- together with `1` - the only valid value in the upcoming Qualcomm LPG
driver. It is thus unexpected when `repeat` with an initialization
value of `0` is passed into the the driver, when the sysfs property
clearly presents a value of `-1`.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
This adds support for sdm630/636/660 modem subsystem
remote processor.
Currently an issue persists, where the remote processor will
restart itself every 40 seconds, but it seems to work otherwise.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
SDM630 has two usable layer mixers (LM0, LM2) and pingpongs (PP0, PP2),
with writeback located on LM2, has no RGB pipe and does not support
source split.
SDM660 has four usable layer mixers (LM0, LM1, LM2, LM5) and
three pingpongs (PP0, PP1, PP4), with writeback located on LM2,
has no RGB pipes and does support source split; also, the HDMI
is on INTF0.
As cherry on top, let's also write the correct flush_hw_mask for
both MDP configurations to stop flushing useless and unused pipes
for performance purposes.
Signed-off-by: AngeloGioacchino Del Regno <kholk11@gmail.com>
This adds support for nt36672a Tianma FHD+ (2520x1080)
video mode panel as found on Sony Xperia 10 Plus (mermaid)
devices.
Due to the nature of phone manufacturing, it is impossible
to retrieve the actual panel name, hence the replacement
one, detailing the device it's used on.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
This adds support for nt36672a Truly FHD+ (2520x1080)
video mode panel as found on Sony Xperia 10 (kirin)
devices.
Due to the nature of phone manufacturing, it is impossible
to retrieve the actual panel name, hence the replacement
one, detailing the device it's used on.
Signed-off-by: Konrad Dybcio <konradybcio@gmail.com>
