While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-11-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-10-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-9-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
While the kernel is booting up, APSS clock / CPU clock will be running
at 800MHz with GPLL0 as source. Once the cpufreq driver is available,
APSS PLL will be configured to the rate based on the opp table and the
source also will be changed to APSS_PLL_EARLY. So allow the mailbox to
consume the GPLL0, with this inclusion, CPU Freq correctly reports that
CPU is running at 800MHz rather than 24MHz.
Signed-off-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230913-gpll_cleanup-v2-8-c8ceb1a37680@quicinc.com
[bjorn: Updated commit message, as requested by Kathiravan]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IPQ95xx SoCs have different OPPs available for the CPU based on
SoC variant. This can be determined from an eFuse register
present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
Frequency 1.2GHz 1.8GHz 1.5GHz No opp-supported-hw
Limit
------------------------------------------------------------
936000000 1 1 1 1 0xf
1104000000 1 1 1 1 0xf
1200000000 1 1 1 1 0xf
1416000000 0 1 1 1 0x7
1488000000 0 1 1 1 0x7
1800000000 0 1 0 1 0x5
2208000000 0 0 0 1 0x1
-----------------------------------------------------------
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Link: https://lore.kernel.org/r/14ab08b7cfd904433ca6065fac798d4f221c9d95.1697781921.git.quic_varada@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
IPQ53xx have different OPPs available for the CPU based on
SoC variant. This can be determined through use of an eFuse
register present in the silicon.
Add support to read the eFuse and populate the OPPs based on it.
------------------------------------------------
Frequency BIT2 BIT1 opp-supported-hw
1.1GHz 1.5GHz
------------------------------------------------
1100000000 1 1 0x7
1500000000 0 1 0x3
------------------------------------------------
Signed-off-by: Kathiravan T <quic_kathirav@quicinc.com>
Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
Link: https://lore.kernel.org/r/463f01759cedef3121767d2432aa415794036ce1.1697781921.git.quic_varada@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add the missing regulator supplies to the ADV7533 HDMI bridge to fix
the following dtbs_check warnings. They are all also supplied by
pm8916_l6 so there is no functional difference.
apq8016-sbc.dtb: bridge@39: 'dvdd-supply' is a required property
apq8016-sbc.dtb: bridge@39: 'pvdd-supply' is a required property
apq8016-sbc.dtb: bridge@39: 'a2vdd-supply' is a required property
from schema display/bridge/adi,adv7533.yaml
Fixes: 28546b0955 ("arm64: dts: apq8016-sbc: Add HDMI display support")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20230922-db410c-adv7533-regulators-v1-1-68aba71e529b@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
MSM8976 downstream dts define reloc region which is used by pil-tz
to load both wcnss and lpass, on mainline however we might not be
able to do it and we need separate regions(also validating dts might get
problematic if we had to put memory-region(rproc node) per device).
Luckily it seems size and entry points in firmware headers appears
to be static across multiple devices including Sony Loire platform
and Xiaomi Redmi Note 3 Pro this should let us fit in first ~17MB
Split lpass region(reloc on downstream) into two separate regions.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Link: https://lore.kernel.org/r/20230812112534.8610-7-a39.skl@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The modem firmware size is typically highly device-specific.
The current size of the mpss_mem region in msm8916.dtsi (0x2b00000)
only works for some APQ8016 devices without full-featured modem,
such as the DragonBoard 410c.
The full modem firmware is typically about twice as large (~45 MiB
-> ~90 MiB) but also varies by a few MiB from device to device. Since
these devices are quite memory-constrained nowadays it's important to
minimize the unnecessary memory reservations.
Make it clear that each board needs to specify the necessary mpss_mem
size by replacing the DB410c-specific size in msm8916.dtsi with a
simple comment. &mpss_mem is disabled by default so it's fine to leave
some properties up to the boards if they want to enable it.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-8-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Now that we no longer have fixed addresses for the firmware memory
regions, disable them by default and only enable them together with
the actual user in the board DT.
This frees up unnecessary reserved memory for boards that do not use
some of the remoteprocs and allows moving selected device-specific
properties (such as firmware size) to the board-specific DT part in
the next step.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-7-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
At a first glance the MBA memory region on MSM8916 looks intentionally
placed at the fixed address 0x8ea00000. This is what the ELF headers of
the firmware specify as base address, and the typical Qualcomm-specific
bits suggest the binary is not relocatable.
However, on a closer look this is pointless: Unlike other firmware
images the hardware expects to have the raw ELF image loaded to the MBA
region, including the ELF header (without parsing it at all). This
means that we actually just load the ELF header (not the code!) at
0x8ea00000. The real LOAD segments follow at arbitrary aligned
addresses depending on the structure of the ELF binary.
In practice it looks like we can use an arbitrary 1 MiB-aligned region
for MBA. The downstream/vendor kernel just allocates this dynamically
at an arbitrary (aligned) address.
Drop the pointless fixed address and use the new dynamic reserved
memory mechanism to allocate a region close to the others. This reduces
gaps in the memory map and provides Linux with more contiguous memory.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-5-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Most of the reserved firmware memory on MSM8916 can be relocated when
respecting the required alignment. To avoid having to precompute the
reserved memory regions in every board DT, describe the actual
requirements (size, alignment, alloc-ranges) using the dynamic reserved
memory allocation.
This approach has several advantages:
1. We can define "templates" for the reserved memory regions in
msm8916.dtsi and keep only device-specific details in the board DT.
This is useful for the "mpss" region size for example, which varies
from device to device. It is no longer necessary to redefine all
firmware regions to shift their addresses.
2. When some of the functionality (e.g. WCNSS, Modem, Venus) is not
enabled or needed for a device, the reserved memory can stay
disabled, freeing up the unused reservation for Linux.
3. Devices with special requirements for one of the firmware regions
are handled automatically. For example, msm8916-longcheer-l8150
has non-relocatable "wcnss" firmware that must be loaded exactly
at address 0x8b600000. When this is defined as a static region,
the other dynamic allocations automatically adjust to a different
place with suitable alignment.
All in all this approach significantly reduces the boilerplate necessary
to define the different firmware regions, and makes it easier to enable
functionality on the different devices.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20230911-msm8916-rmem-v1-4-b7089ec3e3a1@gerhold.net
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
