Add silicon specific compatible qcom,sm8450-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8450 against the yaml documentation.
Add silicon specific compatible qcom,sm8150-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8150 against the yaml documentation.
arm64: dts: qcom: sdm845: do not customize SPI0 pin drive/bias
Each board should define pin drive/bias for used busses. All boards
using SPI0 (db845c and cheza) already do it, so drop the bias/drive
strength from SoC DTSI.
arm64: dts: qcom: sdm845-xiaomi-beryllium: fix audio codec interrupt pin name
The pin config entry should have a string, not number, for the GPIO used
as WCD9340 audio codec interrupt.
Fixes: dd6459a0890a ("arm64: dts: qcom: split beryllium dts into common dtsi and tianma dts") Reported-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221222151319.122398-2-krzysztof.kozlowski@linaro.org
Bindings expect power domains to follow generic naming pattern:
sm8450-qrd.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Bindings expect power domains to follow generic naming pattern:
sm8350-hdk.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Bindings expect power domains to follow generic naming pattern:
sm8250-hdk.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Bindings expect power domains to follow generic naming pattern:
sm8150-hdk.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Bindings expect power domains to follow generic naming pattern:
sm6375-sony-xperia-murray-pdx225.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
Bindings expect power domains to follow generic naming pattern:
sc8280xp-crd.dtb: psci: 'cpu-cluster0', 'cpu0', 'cpu1', 'cpu2', 'cpu3', 'cpu4', 'cpu5', 'cpu6',
'cpu7' do not match any of the regexes: '^power-domain-', 'pinctrl-[0-9]+'
arm64: dts: qcom: sm8450: disable by default Soundwire and VA-macro
Soundwire is a bus and VA-macro requires a supply, thus both are
expected to be explicitly enabled and populated by board DTS. The
HDK8450 already enables Soundwire devices, except swr4 which as a result
of this commit will stay disabled.
Marijn Suijten [Fri, 16 Dec 2022 23:34:08 +0000 (00:34 +0100)]
arm64: dts: qcom: sm6125-seine: Enable GPI DMA 0, QUP 0 and I2C SEs
Enable I2C Serial Engines 1, 2 and 3 which are known to have hardware
connected to them, leaving the rest disabled to save on power. For
this, only GPI DMA 0 and QUP 0 need to be enabled, as nothing seems to
be connected to Serial Engines on GPU DMA 1 / QUP 1. Beyond this
downstream only defines a UART console available on Serial Engine 4
which also resides on QUP 0.
Marijn Suijten [Fri, 16 Dec 2022 23:34:07 +0000 (00:34 +0100)]
arm64: dts: qcom: sm6125: Add QUPs with SPI and I2C Serial Engines
Add Qualcomm Universal Peripheral nodes with SPI and I2C Serial Engines.
QUP 0 only has two SPIs at index 0 and 2, QUP 1 has four SPIs with a gap
in the middle (ranging from 5-9 with SPI 7 missing). Both QUPs have 5
I2C Serial Engines.
[Marijn: Add iommus, reword patch description, reorder all properties,
sort based on address, use QCOM_GPI_ constants, drop dma cells from 5
to 3]
Signed-off-by: Martin Botka <martin.botka@somainline.org> Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Martin Botka <martin.botka@somainline.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221216233408.1283581-3-marijn.suijten@somainline.org
Marijn Suijten [Thu, 22 Dec 2022 19:24:43 +0000 (20:24 +0100)]
arm64: dts: qcom: sm6125-seine: Clean up gpio-keys (volume down)
- Remove autorepeat (leave key repetition to userspace);
- Remove unneeded status = "okay" (this is the default);
- Remove unneeded linux,input-type <EV_KEY> (this is the default for
gpio-keys);
- Allow the interrupt line for this button to be disabled;
- Use a full, descriptive node name;
- Set proper bias on the GPIO via pinctrl;
- Sort properties;
- Replace deprecated gpio-key,wakeup property with wakeup-source.
Fixes: 82e1783890b7 ("arm64: dts: qcom: sm6125: Add support for Sony Xperia 10II") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221222192443.119103-1-marijn.suijten@somainline.org
Marijn Suijten [Thu, 22 Dec 2022 19:32:53 +0000 (20:32 +0100)]
arm64: dts: qcom: sm6125: Add apps_smmu with streamID to SDHCI 1/2 nodes
When enabling the APPS SMMU the mainline driver reconfigures the SMMU
from its bootloader configuration, losing the stream mapping for (among
which) the SDHCI hardware and breaking its ADMA feature. This feature
can be disabled with:
sdhci.debug_quirks=0x40
But it is of course desired to have this feature enabled and working
through the SMMU.
Marijn Suijten [Fri, 16 Dec 2022 21:33:43 +0000 (22:33 +0100)]
arm64: dts: qcom: sm6125: Reorder HSUSB PHY clocks to match bindings
Reorder the clocks and corresponding names to match the QUSB2 phy
schema, fixing the following CHECK_DTBS errors:
arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dtb: phy@1613000: clock-names:0: 'cfg_ahb' was expected
From schema: /newdata/aosp-r/kernel/mainline/kernel/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
arch/arm64/boot/dts/qcom/sm6125-sony-xperia-seine-pdx201.dtb: phy@1613000: clock-names:1: 'ref' was expected
From schema: /newdata/aosp-r/kernel/mainline/kernel/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
Fixes: cff4bbaf2a2d ("arm64: dts: qcom: Add support for SM6125") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: Martin Botka <martin.botka@somainline.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221216213343.1140143-1-marijn.suijten@somainline.org
Sony's seine board features an SD Card slot on SDHCI 2, that is to be
powered by l5 and l22. The card detect pin is already biased via
updates on the generic sdc2_*_state pinctrl nodes.
As usual regulator voltages are decreased to the maximum voted by the
downstream driver for safety. SDHCI 2 is the only hardware block
feeding off of these.
Marijn Suijten [Thu, 22 Dec 2022 20:36:34 +0000 (21:36 +0100)]
arm64: dts: qcom: sm6125-seine: Provide regulators to SDHCI 1
While SDHCI 1 appears to work out of the box, we cannot rely on the
bootloader-enabled regulators nor expect them to remain enabled (e.g.
when finally dropping pd_ignore_unused). Provide it the necessary l24
and l11 regulators now that PM6125 regulators have been made available
on this board.
As usual regulator voltages are decreased to the maximum voted by the
downstream driver for safety. No other hardware feeds off of these
regulators anyway (except UFS, which isn't used on the seine board in
favour of a DV6DMB eMMC card connected to SDHCI 1).
Configure PM6125 regulators based on availability and voltages defined
downstream, to allow powering up (and/or keeping powered) other hardware
blocks going forward.
Marijn Suijten [Thu, 22 Dec 2022 21:59:06 +0000 (22:59 +0100)]
arm64: dts: qcom: sm6350-lena: Flatten gpio-keys pinctrl state
Pinctrl states typically collate multiple related pins. In the case of
gpio-keys there's no hardware-defined relation at all except all pins
representing a key; and especially on Sony's lena board there's only one
pin regardless. Flatten it similar to other boards [1].
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221223021025.1646636-18-bryan.odonoghue@linaro.org
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221223021025.1646636-15-bryan.odonoghue@linaro.org
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221223021025.1646636-14-bryan.odonoghue@linaro.org
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Add silicon specific compatible qcom,msm8953-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8953 against the yaml documentation.
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Alex Elder [Sat, 24 Dec 2022 00:21:26 +0000 (18:21 -0600)]
arm64: dts: qcom: sc7280: only enable IPA for boards with a modem
IPA is only needed on a platform if it includes a modem, and not all
SC7280 SoC variants do. The file "sc7280-herobrine-lte-sku.dtsi" is
used to encapsulate definitions related to Chrome OS SC7280 devices
where a modem is present, and that's the proper place for the IPA
node to be enabled.
Currently IPA is enabled in "sc7280-idp.dtsi", which is included by
DTS files for Qualcomm reference platforms (all of which include the
modem). That also includes "sc7280-herobrine-lte-sku.dtsi", so
enabling IPA there would make it unnecessary for "sc7280-idp.dtsi"
to enable it.
The only other place IPA is enabled is "sc7280-qcard.dtsi".
That file is included only by "sc7280-herobrine.dtsi", which
is (eventually) included only by these top-level DTS files:
sc7280-herobrine-crd.dts
sc7280-herobrine-herobrine-r1.dts
sc7280-herobrine-evoker.dts
sc7280-herobrine-evoker-lte.dts
sc7280-herobrine-villager-r0.dts
sc7280-herobrine-villager-r1.dts
sc7280-herobrine-villager-r1-lte.dts
All of but two of these include "sc7280-herobrine-lte-sku.dtsi", and
for those cases, enabling IPA there means there is no need for it to
be enabled in "sc7280-qcard.dtsi".
The two remaining cases will no longer enable IPA as a result of
this change:
sc7280-herobrine-evoker.dts
sc7280-herobrine-villager-r1.dts
Both of these have "lte" counterparts, and are meant to represent
board variants that do *not* have a modem.
This is exactly the desired configuration.
Signed-off-by: Alex Elder <elder@linaro.org> Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com> Tested-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20221224002126.1518552-1-elder@linaro.org
Add full cache description to DTS to avoid:
1. "Early cacheinfo failed" warnings,
2. Cache topology detection which leads to early memory allocations and
"BUG: sleeping function called from invalid context" on PREEMPT_RT
kernel:
Pierre Gondois [Mon, 7 Nov 2022 15:57:09 +0000 (16:57 +0100)]
arm64: dts: qcom: Update cache properties
The DeviceTree Specification v0.3 specifies that the cache node
'compatible' and 'cache-level' properties are 'required'. Cf.
s3.8 Multi-level and Shared Cache Nodes
The 'cache-unified' property should be present if one of the
properties for unified cache is present ('cache-size', ...).
Update the Device Trees accordingly.
About msm8953.dtsi:
According to the Devicetree Specification v0.3,
s3.7.3 'Internal (L1) Cache Properties',
cache-unified:
If present, specifies the cache has a unified or-
ganization. If not present, specifies that the
cache has a Harvard architecture with separate
caches for instructions and data.
Plus, the 'cache-level' property seems to be reserved to higher
cache levels (cf s3.8).
To describe a l1 data/instruction cache couple, no cache
information should be described. Remove the l1 cache nodes.
Add driver for the Qualcomm interconnect buses found in SM8550 based
platforms. The topology consists of several NoCs that are controlled by
a remote processor that collects the aggregated bandwidth for each
master-slave pairs.
Adjust node names so they're not just memory@ but actually show what
they're used for. Also add labels to most nodes so we can easily
reference them from devices.
arm64: dts: qcom: Re-enable resin on MSM8998 and SDM845 boards
resin node declaration was moved to pm8998.dtsi file (in disabled state).
MSM8998 and SDM845 boards defining resin node did not previously have
status="okay" and ended up disabled.
Re-enable it by using resin node link from pm8998.dtsi with status="okay".
arm64: dts: qcom: sc7280: Add wifi alias for SC7280-idp
Currently, depth-charge Chrome OS bootloader code used in the SC7280
SoC accesses the WiFi node using node names (wifi@<addr>). Since
depth-charge Chrome OS bootloader is a common code that is used in
SoCs having different WiFi chipsets, it is better if the depth-charge
Chrome OS bootloader code accesses the WiFi node using a WiFi alias.
The advantage of this method is that the depth-charge Chrome OS
bootloader code need not be changed for every new WiFi chip.
Therefore, add wifi alias entry for SC7280-idp device tree.
The firmware paths were pointing to qcom/manufacturer whereas other
devices have them under qcom/chipset/manufacturer, so fix this up on the
c630, so we follow the same standard setup.
Richard Acayan [Mon, 5 Dec 2022 22:52:37 +0000 (17:52 -0500)]
arm64: dts: qcom: sdm670-google-sargo: keep pm660 ldo8 on
According to the downstream device tree, the regulator that powers the
I/O for eMMC should not be turned off. Keep it always on just in case
the eMMC driver fails and doesn't enable it, or unloads and disables it.
On eMMC devices, the UFS clocks aren't started in the bootloader (or well,
at least it should not be, as that would just leak power..), which results
in platform reboots when trying to access the unclocked UFS hardware,
which unfortunately happens on each and every boot, as interconnect calls
sync_state and goes over each and every path.
Konrad Dybcio [Sat, 10 Dec 2022 14:09:59 +0000 (15:09 +0100)]
arm64: dts: qcom: msm8996-tone: Enable SDHCI1
With the recent patch that allowed us to reset the SDHCI controller from
Linux, things started working properly. Enable SDHCI1, and by extension
eMMC. Also, remove the now-useless cmdline SDHCI quirks.
arm64: dts: qcom: sdm845: move DSI/QUP/QSPI opp tables out of SoC node
The SoC node is a simple-bus and its schema expect to have nodes only
with unit addresses:
sdm850-lenovo-yoga-c630.dtb: soc@0: opp-table-qup: {'compatible': ['operating-points-v2'], 'phandle': [[60]], 'opp-50000000':
... 'required-opps': [[55]]}} should not be valid under {'type': 'object'}
Move to top-level OPP tables:
- DSI and QUP which are shared between multiple nodes,
- QSPI which cannot be placed in its node due to address/size cells.
arm64: dts: qcom: sc7180: move QUP and QSPI opp tables out of SoC node
The SoC node is a simple-bus and its schema expect to have nodes only
with unit addresses:
sc7180-trogdor-lazor-r3.dtb: soc@0: opp-table-qspi: {'compatible': ['operating-points-v2'], 'phandle': [[186]], 'opp-75000000':
... 'required-opps': [[47]]}} should not be valid under {'type': 'object'}
Move to top-level OPP tables:
- QUP which is shared between multiple nodes,
- QSPI which cannot be placed in its node due to address/size cells.
Konrad Dybcio [Sat, 10 Dec 2022 10:25:59 +0000 (11:25 +0100)]
arm64: dts: qcom: sm6350: Fix up the ramoops node
Fix up the ramoops node to make it match bindings and style:
- remove "removed-dma-pool"
- don't pad size to 8 hex digits
- change cc-size to ecc-size so that it's used
- increase ecc-size from to 16
- remove the zeroed ftrace-size
Marijn Suijten [Fri, 9 Dec 2022 22:04:49 +0000 (23:04 +0100)]
arm64: dts: qcom: Use plural _gpios node label for PMIC gpios
The gpio node in PMIC dts'es define access to multiple GPIOs. Most Qcom
PMICs were already using the plural _gpios label to point to this node,
but a few PMICs were left behind including the recently-pulled
pm(i)8950.
Rename it from *_gpio to *_gpios for pm6125, pm6150(l), pm8005,
pm(i)8950, and pm(i)8998.