Normally the 'pinctrl' properties of a SDHC controller and the
chip detect pin settings are dependent on the type of the slots
(for e.g uSD card slot), regulators and GPIO(s) available on the
board(s).
So, move the same from the sm6115 dtsi file to the respective
board file(s).
Bhupesh Sharma [Tue, 14 Mar 2023 08:36:33 +0000 (14:06 +0530)]
arm64: dts: qcom: sm6115: Move USB node's 'maximum-speed' and 'dr_mode' properties to dts
Normally the 'maximum-speed' and 'dr_mode' properties
of a USB controller + port is dependent on the type of
the ports, regulators and mode change interrupt routing
available on the board(s).
So, move the same from the sm6115 dtsi file to respective
board file(s).
Bhupesh Sharma [Tue, 14 Mar 2023 08:36:32 +0000 (14:06 +0530)]
arm64: dts: qcom: sm6115: Cleanup USB node's label
There is only one USB controller present on SM6115 / SM4250
Qualcomm SoC, so drop the numbering used with USB node's label
names in the dtsi and the related sm4250-oneplus-billie2.dts.
The mrbland board was never actually produced and there has been no
activity around the board for quite some time. It seems highly
unlikely to magically get revived. There should be nobody in need of
these device trees, so let's delete them. If somehow the project
resurrects itself then we can re-add support, perhaps just for -rev1+.
lazor-rev0 was a pile of parts. While I kept the pile of parts for
lazor running on my desk for longer than I usually do, those days are
still long past. Let's finally delete support for lazor-rev0.
The earliest kingoftown that I could find in my pile of boards was
-rev2 and even that revision looks pretty rough (plastics on the case
are very unfinished). Though I don't actually have details about how
many -rev0 devices were produced, I can't imagine anyone still using
one. Let's delete support.
The earliest wormdingler I could find in my pile of hardware is
-rev1. I believe that -rev0 boards were just distributed as a pile of
components with no case. At this point I can't imagine anyone needing
to make wormdingler-rev0 work, so let's delete support for it.
Adam Skladowski [Thu, 2 Mar 2023 12:30:49 +0000 (13:30 +0100)]
arm64: dts: qcom: msm8976: Add and provide xo clk to rpmcc
In order for consumers of RPMCC XO clock to probe successfully
their parent needs to be feed with reference clock to obtain proper rate,
add fixed xo-board clock and supply it to rpmcc to make consumers happy.
Frequency setting is left per board basis just like on other recent trees.
arm64: dts: qcom: sm8350: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: sm8450: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: sm8150: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: sc8280xp: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x30200000, 0x32200000, 0x34200000, 0x38200000, 0x3c200000) specified in
the ranges property for I/O region.
arm64: dts: qcom: sm8250: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000, 0x64200000) specified in the ranges property for
I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: msm8996: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x0c200000, 0x0d200000, 0x0e200000) specified in the ranges property for
I/O region.
arm64: dts: qcom: ipq6018: Fix the PCI I/O port range
For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI address
(0x20200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: ipq8074: Fix the PCI I/O port range
For 64KiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x10000. Hence, fix the bogus PCI addresses
(0x10200000, 0x20200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses and align
them in a single line.
arm64: dts: qcom: sm8550: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
arm64: dts: qcom: sc7280: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
(0x40200000) specified in the ranges property for I/O region.
arm64: dts: qcom: msm8998: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI address
(0x1b200000) specified in the ranges property for I/O region.
arm64: dts: qcom: sdm845: Fix the PCI I/O port range
For 1MiB of the I/O region, the I/O ports of the legacy PCI devices are
located in the range of 0x0 to 0x100000. Hence, fix the bogus PCI addresses
(0x60200000, 0x40200000) specified in the ranges property for I/O region.
While at it, let's use the missing 0x prefix for the addresses.
Vincent Guittot [Fri, 6 Jan 2023 16:46:18 +0000 (17:46 +0100)]
arm64: dts: qcom: sdm845: correct dynamic power coefficients
While stressing EAS on my dragonboard RB3, I have noticed that LITTLE cores
where never selected as the most energy efficient CPU whatever the
utilization level of waking task.
energy model framework uses its cost field to estimate the energy with
the formula:
nrg = cost of the selected OPP * utilization / CPU's max capacity
which ends up selecting the CPU with lowest cost / max capacity ration
as long as the utilization fits in the OPP's capacity.
If we compare the cost of a little OPP with similar capacity of a big OPP
like :
OPP(kHz) OPP capacity cost max capacity cost/max capacity
LITTLE 1766400 407 351114 407 863
big 1056000 408 520267 1024 508
This can be interpreted as the LITTLE core consumes 70% more than big core
for the same compute capacity.
According to [1], LITTLE consumes 10% less than big core for Coremark
benchmark at those OPPs. If we consider that everything else stays
unchanged, the dynamic-power-coefficient of LITTLE core should be
only 53% of the current value: 290 * 53% = 154
Set the dynamic-power-coefficient of CPU0-3 to 154 to fix the energy model.
arm64: dts: qcom: msm8996-oneplus: do not enable incomplete nodes
status=okay should appear in final place where all required properties
are provided, because that makes the code the easiest to read. Move the
status from common OnePlus DTSI to board DTS. No functional changes.
arm64: dts: qcom: msm8994: correct RPMCC node name
The bindings expect RPM clock controller subnode to be named
'clock-controller':
apq8094-sony-xperia-kitakami-karin_windy.dtb: smd: rpm:rpm-requests: 'rpmcc' does not match any of the regexes: '^regulators(-[01])?$', 'pinctrl-[0-9]+'
arm64: dts: qcom: sm8250: drop incorrect Coresight funnel properties
There is only one output port, thus out-ports should not have
'address/size-cells' and unit addresses. 'reg-names' are also not
allowed by bindings.
qrb5165-rb5.dtb: funnel@6042000: out-ports: '#address-cells', '#size-cells', 'port@0' do not match any of the regexes: 'pinctrl-[0-9]+'
qrb5165-rb5.dtb: funnel@6b04000: Unevaluated properties are not allowed ('reg-names' was unexpected)
arm64: dts: qcom: sm6350: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
On SM6350, there is only one LLCC bank available. So let's just pass that
as "llcc0_base".
arm64: dts: qcom: sm8450: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
arm64: dts: qcom: sm8350: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
arm64: dts: qcom: sm8250: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
arm64: dts: qcom: sm8150: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
arm64: dts: qcom: sc8280xp: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
arm64: dts: qcom: sc7280: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
While at it, let's also fix the size of the llcc_broadcast_base to cover
the whole region.
arm64: dts: qcom: sc7180: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
On SC7180, there is only one LLCC bank available. So let's just pass that
as "llcc0_base".
arm64: dts: qcom: sdm845: Fix the base addresses of LLCC banks
The LLCC block has several banks each with a different base address
and holes in between. So it is not a correct approach to cover these
banks with a single offset/size. Instead, the individual bank's base
address needs to be specified in devicetree with the exact size.
On SDM845, the size of the LLCC bank 0 needs to be reduced to 0x4500 as
there are LLCC BWMON registers located after this range.
Mukesh Ojha [Wed, 22 Feb 2023 15:30:45 +0000 (21:00 +0530)]
arm64: dts: qcom: sm8450: Add IMEM and PIL info region
Add a simple-mfd representing IMEM on SM8450 and define the PIL
relocation info region, so that post mortem tools will be able
to locate the loaded remoteprocs.
arm64: dts: qcom: msm8996: move WCD9335 audio codec to boards
The WCD9335 audio codec on Slimbus is a property of a board, not SoC,
thus it should not be present in MSM8996 DTSI. Keep it in specific
boards, so it won't appear incomplete in the boards not having it.
arm64: dts: qcom: sm6115: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm6375: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sc8280xp: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm8350: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm8150: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sc7180: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: qdu1000: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm8250: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm8550: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sm6350: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sc7280: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: sdm845: Supply clock from cpufreq node to CPUs
Qualcomm platforms making use of CPUFreq HW Engine (EPSS/OSM) supply clocks
to the CPU cores. But this relationship is not represented in DTS so far.
So let's make cpufreq node as the clock provider and CPU nodes as the
consumers. The clock index for each CPU node is based on the frequency
domain index.
arm64: dts: qcom: add initial support for qcom sa8775p-ride
This adds basic support for the Qualcomm sa8775p platform and the
reference board: sa8775p-ride. The dt files describe the basics of the
SoC and enable booting to shell.
Abel Vesa [Wed, 8 Feb 2023 18:00:20 +0000 (20:00 +0200)]
arm64: dts: qcom: sm8550: Fix PCIe PHYs and controllers nodes
First, move the pinctrl related propeties out from SoC dtsi and into the
board dts and add blank lines before status properties in the PHY nodes
to be consistent with the rest of the nodes. Then drop the pipe clock
from the controller nodes. Rename the aggre0 and aggre1 clocks to more
generic noc_aggr, and then the cnoc_pcie_sf_axi to cnoc_sf_axi. Add the
cpu-pcie interconnects to both controller nodes. Rename the pcie1 second
reset to link_down and drop the unnecessary enable-gpios. Switch the aux
clock to GCC_PCIE_1_PHY_AUX_CLK for the pcie1 PHY and drop the aux_phy
from clock-names. Also rename the nocsr reset to phy_nocsr. With this
changes we are now in line with the SC8280XP bindings.
Fixes: 7d1158c984d3 ("arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230208180020.2761766-12-abel.vesa@linaro.org
Johan Hovold [Thu, 2 Feb 2023 15:54:48 +0000 (16:54 +0100)]
arm64: dts: qcom: sc8280xp-x13s: enable rtc
The Lenovo X13s firmware does not implement the UEFI time runtime
services so the RTC in the PM8280K PMIC needs to be accessed directly.
To complicate things further, the RTC control and time registers are
read-only on this platform so an offset must be stored in some other
machine-specific non-volatile memory which an RTC driver can take into
account when reading or updating the time.
The UEFI firmware (and Windows) use a UEFI variable for this:
but the offset can only be accessed via the Qualcomm UEFI Secure
Application residing in the TEE as the firmware does not implement the
variable runtime services either.
While it is possible to access this UEFI variable from Linux on the
X13s, this requires using a fairly complex and reverse-engineered
firmware interface. As the only benefit of doing so is to make sure that
the UEFI (Windows) and Linux time never gets out of sync, it seems
preferable to use the PMIC scratch registers for storing an offset
instead. This also avoids flash wear in case of RTC drift, etc.
So instead of using the UEFI RTC offset, reserve four bytes in one of
the PMIC SDAM scratch-register blocks to hold the RTC offset.
Johan Hovold [Thu, 2 Feb 2023 15:54:47 +0000 (16:54 +0100)]
arm64: dts: qcom: sc8280xp-crd: enable rtc
The SC8280XP CRD firmware does not implement the UEFI time runtime
services so the RTC in the PM8280K PMIC needs to be accessed directly.
To complicate things further, the RTC control and time registers are
read-only on this platform so an offset must be stored in some other
machine-specific non-volatile memory which an RTC driver can take into
account when reading or updating the time.
The UEFI firmware (and Windows) use a UEFI variable for this:
but the offset can only be accessed via the Qualcomm UEFI Secure
Application residing in the TEE as the firmware does not implement the
variable runtime services either.
While it is possible to access this UEFI variable from Linux on the CRD,
this requires using a fairly complex and reverse-engineered firmware
interface. As the only benefit of doing so is to make sure that the UEFI
(Windows) and Linux time never gets out of sync, it seems preferable to
use the PMIC scratch registers for storing an offset instead. This also
avoids flash wear in case of RTC drift, etc.
Also note that setting variables using this interface does not work on
at least one CRD for reasons not yet known.
So instead of using the UEFI RTC offset, reserve four bytes in one of
the PMIC SDAM scratch-register blocks to hold the RTC offset.
Johan Hovold [Thu, 2 Feb 2023 15:54:45 +0000 (16:54 +0100)]
arm64: dts: qcom: sc8280xp-pmics: add pmk8280 rtc
The PMK8280 has an RTC which can also be used as a wakeup source.
Note that the RTC can not be disabled and updating the time is not
permitted either. Instead an offset can be stored in some other machine-
specific non-volatile memory which a driver can take into account.
projects / thirdparty / kernel / stable.git / log
