Specifying interrupts and interrupts-extended is not correct. Keep only
the extended ones, routed towards IPCC mailbox to fix warnings like:
sm8450-qrd.dtb: glink-edge: More than one condition true in oneOf schema:
{'$filename': 'Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml',
Specifying interrupts and interrupts-extended is not correct. Keep only
the extended ones, routed towards IPCC mailbox to fix warnings like:
sm8350-sony-xperia-sagami-pdx214.dtb: glink-edge: More than one condition true in oneOf schema:
{'$filename': 'Documentation/devicetree/bindings/remoteproc/qcom,glink-edge.yaml',
As Bjorn noted in [1], since the qmp phy driver doesn't
use the 'vdda-max-microamp' & 'vdda-pll-max-microamp' properties
currently, let's remove them from the dts files as well.
Otherwise, it leads to the following '$ make dtbs_check'
warning(s):
sm8350-microsoft-surface-duo2.dt.yaml: phy@1d87000:
'vdda-max-microamp', 'vdda-pll-max-microamp' do not match any of
the regexes: '^phy@[0-9a-f]+$', 'pinctrl-[0-9]+
If later on the driver support is added, we can add these properties
back to the dts files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:23 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix 'reg-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports a number of issues with
ordering of 'reg-names' as various possible combinations
are possible for different qcom SoC dts files.
Fix the same by updating the offending 'dts' files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:22 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix ordering of 'clocks' & 'clock-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports a number of issues with
ordering of 'clocks' & 'clock-names' for sdhci nodes:
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:0: 'iface' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:1: 'core' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:2: 'xo' was expected
Fix the same by updating the offending 'dts' files.
Bhupesh Sharma [Sat, 14 May 2022 21:54:20 +0000 (03:24 +0530)]
arm64: dts: qcom: sdm630: Fix 'interconnect-names' for sdhci nodes
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports issues with
inconsistent 'interconnect-names' used for sdhci nodes.
Bhupesh Sharma [Sat, 14 May 2022 21:54:19 +0000 (03:24 +0530)]
arm64: dts: qcom: Fix sdhci node names - use 'mmc@'
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports issues with
inconsistent 'sdhci@' convention used for specifying the
sdhci nodes. The generic mmc bindings expect 'mmc@' format
instead.
Fix the same.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Herring <robh@kernel.org> Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
[bjorn: Moved non-arm64 changes to separate commit] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220514215424.1007718-2-bhupesh.sharma@linaro.org
Marijn Suijten [Wed, 11 May 2022 19:07:18 +0000 (21:07 +0200)]
arm64: dts: qcom: sdm630-nile: Add RGB status LED on the PM660L LPG
The entire Sony Nile and Ganges lineup utilize the first three channels
(the triled channels) of the LPG block for an RGB (battery) status and
notification indicator.
Marijn Suijten [Wed, 11 May 2022 19:07:17 +0000 (21:07 +0200)]
arm64: dts: qcom: pm660l: Add LPG node
The Light Pulse Generator describes a hardware block responsible for
displaying colors and patterns on an RGB LED (usually used for [battery]
status and notifications), and drive PWM signals for general-purpose
(ie. backlight) LEDs. The availability and usage of the individual
channels differ per board and is hence left for individual platform DTs
to configure.
Andrey Konovalov [Sat, 11 Jun 2022 19:57:13 +0000 (22:57 +0300)]
arm64: dts: qcom: qcs404: fix default pinctrl settings for blsp1_spi1
The current settings refer to "blsp_spi1" function which isn't defined.
For this reason an attempt to enable blsp1_spi1 interface results in
the probe failure below:
[ 3.492900] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.502460] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.517725] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.532998] qcs404-pinctrl 1000000.pinctrl: invalid function blsp_spi1 in map table
[ 3.548277] spi_qup: probe of 78b6000.spi failed with error -22
Fix this by making the functions used in qcs404.dtsi to match the contents
of drivers/pinctrl/qcom/pinctrl-qcs404.c.
Fix whitespace coding style: use single space instead of tabs or
multiple spaces around '=' sign in property assignment. No functional
changes (same DTB).
The NVMEM bindings expect that 'bits' property holds offset and size of
region within a byte, so it applies a constraint of <0, 7> for the
offset. Using 25 as HSTX trim offset is within 4-byte QFPROM word, but
outside of the byte:
sdm630-sony-xperia-nile-discovery.dtb: qfprom@780000: hstx-trim@240:bits:0:0: 25 is greater than the maximum of 7
sdm630-sony-xperia-nile-discovery.dtb: qfprom@780000: gpu-speed-bin@41a0:bits:0:0: 21 is greater than the maximum of 7
The AOSS QMP bindings expect all compatibles to be followed by fallback
"qcom,aoss-qmp" because all of these are actually compatible with each
other. This fixes dtbs_check warnings like:
sm8250-hdk.dtb: power-controller@c300000: compatible: ['qcom,sm8250-aoss-qmp'] is too short
Wormdingler is a trogdor-based board, shipping to customers as the
Lenovo IdeaPad Chromebook Duet 3. These dts files are copies from
the downstream Chrome OS 5.4 kernel, but with the camera
(sc7180-trogdor-mipi-camera.dtsi) #include removed.
Gwendal Grignou [Thu, 23 Jun 2022 22:31:19 +0000 (15:31 -0700)]
arm64: dts: qcom: sc7280: Rename sar sensor labels
To ease matching configuration of sysfs attributes for particular
sensor, match label reported by iio 'label' attribute with the location
label generated by ChromeOS config tool.
Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220623223119.1858863-1-gwendal@chromium.org
Add an initial devicetree for the Lenovo Thinkpad X13s with support for
USB, backlight, keyboard, touchpad, touchscreen (to be verified), PMICs
and remoteprocs.
Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220622132617.24604-1-johan+linaro@kernel.org
Bjorn Andersson [Wed, 29 Jun 2022 04:14:38 +0000 (21:14 -0700)]
arm64: dts: qcom: add SA8540P and ADP
Introduce the Qualcomm SA8540P automotive platform and the SA8295P ADP
development board.
The SA8540P and SC8280XP are fairly similar, so the SA8540P is built
ontop of the SC8280XP dtsi to reduce duplication. As more advanced
features are integrated this might be re-evaluated.
This initial contribution supports SMP, CPUFreq, cluster idle, UFS, RPMh
regulators, debug UART, PMICs, remoteprocs (NSPs crashes shortly after
booting) and USB.
The SA8295P ADP contains four PM8450 PMICs, which according to their
revid are compatible with PM8150. They are defined within the ADP for
now, to avoid creating additional .dtsi files for PM8150 with just
addresses changed - and to allow using the labels from the schematics.
Bjorn Andersson [Wed, 29 Jun 2022 04:14:37 +0000 (21:14 -0700)]
arm64: dts: qcom: sc8280xp: Add reference device
Add basic support for the SC8280XP reference device, which allows it to
boot to a shell (using EFIFB) with functional storage (UFS), USB,
keyboard, touchpad, touchscreen, backlight and remoteprocs.
The PMICs are, per socinfo, reused from other platforms. But given that
the address of the PMICs doesn't match other cases and that it's
desirable to label things according to the schematics a new dtsi file is
created to represent the reference combination of PMICs.
Bjorn Andersson [Wed, 29 Jun 2022 04:14:36 +0000 (21:14 -0700)]
arm64: dts: qcom: add SC8280XP platform
Introduce initial support for the Qualcomm SC8280XP platform, aka 8cx
Gen 3. This initial contribution supports SMP, CPUfreq, CPU cluster
idling, GCC, TLMM, SMMU, RPMh regulators, power-domains and clocks,
interconnects, some QUPs, UFS, remoteprocs, USB, watchdog, LLCC and
tsens.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20220629041438.1352536-4-bjorn.andersson@linaro.org
Dmitry Baryshkov [Sat, 21 May 2022 20:27:08 +0000 (23:27 +0300)]
arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support
The IFC6560 is a board from Inforce Computing, built around the SDA660
SoC. This patch describes core clocks, some regulators from the two
PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
The regulator settings are inherited from prior work by Konrad Dybcio
and AngeloGioacchino Del Regno.
This results in dts duplication, but per mutual agreement card detect
pin configuration belongs to the board files. Move it from the SoC
dtsi to the board DT files.
ICC path for the GPU incorrectly states <&gnoc 1 &bimc 5>, which is
a path from SLAVE_GNOC_BIMC to SLAVE_EBI. According to the downstream
kernel sources, the GPU uses MASTER_OXILI here, which is equivalent to
<&bimc 1 ...>.
While we are at it, use defined names instead of the numbers for this
interconnect path.
Dmitry Baryshkov [Sat, 21 May 2022 20:27:00 +0000 (23:27 +0300)]
arm64: dts: qcom: sdm630: disable GPU by default
The SoC's device tree file disables gpucc and adreno's SMMU by default.
So let's disable the GPU too. Moreover it looks like SMMU might be not
usable without additional patches (which means that GPU is unusable
too). No board uses GPU at this moment.
Dmitry Baryshkov [Sat, 21 May 2022 20:26:59 +0000 (23:26 +0300)]
arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default
Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
They should be enabled in the board DT files. No existing boards use
them at this moment.
Dmitry Baryshkov [Sat, 21 May 2022 20:26:58 +0000 (23:26 +0300)]
arm64: dts: qcom: sdm630: disable dsi0/dsi0_phy by default
Follow the typical practice and keep DSI0/DSI0 PHY disabled by default.
They should be enabled in the board DT files. No existing boards use
them at this moment.
arm64: dts: qcom: correct interrupt controller on PM8916 and PMS405
The PM8916 and PMS405 PMIC GPIOs are interrupt controllers, as described
in the bindings and used by the driver. Drop the interrupts (apparently
copied from downstream tree), just like in commit 61d2ca503d0b ("arm64:
dts: qcom: fix pm8150 gpio interrupts"):
qcs404-evb-4000.dtb: gpio@c000: 'interrupts' does not match any of the regexes: '-state$', 'pinctrl-[0-9]+'
qcs404-evb-4000.dtb: gpio@c000: 'interrupt-controller' is a required property
The bindings require that every pin configuration comes with 'function'
property. There is also no 'drive-strength' property but
'qcom,drive-strength':
msm8994-msft-lumia-octagon-cityman.dtb: gpios@c000: amsel-high-state: 'oneOf' conditional failed, one must be fixed:
'drive-strength' does not match any of the regexes: 'pinctrl-[0-9]+'
'bias-pull-up', 'drive-strength', 'function', 'pins' do not match any of the regexes: '(pinconf|-pins)$', 'pinctrl-[0-9]+'
DT schema expects PMIC GPIO pin configuration nodes to be named with
'-state' suffix. Optional children should be either 'pinconf' or
followed with '-pins' suffix. This fixes dtbs_check warnings like:
sdm845-xiaomi-beryllium.dtb: gpios@c000: 'vol-up-active' does not match any of the regexes: '-state$', 'pinctrl-[0-9]+'
Marijn Suijten [Mon, 20 Jun 2022 21:12:12 +0000 (23:12 +0200)]
arm64: dts: qcom: sdm845-akatsuki: Round down l22a regulator voltage
2700000 is not a multiple of pmic4_pldo's step size of 8000 (with base
voltage 1664000), resulting in pm8998-rpmh-regulators not probing. Just
as we did with MSM8998's Sony Yoshino Poplar [1], round the voltages
down to err on the cautious side and leave a comment in place to
document this discrepancy wrt downstream sources.
Konrad Dybcio [Sat, 30 Apr 2022 16:26:42 +0000 (18:26 +0200)]
arm64: dts: qcom: msm8996: Add SDHCI resets
On MSM8996, the default bootloader configuration leaves the hosts in some
weird state that never allows them to function properly under Linux.
Add the hardware resets so that we can start clean and get them actually
working.
Konrad Dybcio [Sat, 30 Apr 2022 16:23:19 +0000 (18:23 +0200)]
arm64: dts: qcom: msm8996-tone: Drop cont_splash_mem region
Tone does not have a functioning bootloader framebuffer and Linux allocates
the DRM framebuffer dynamically. Free up 36 MiB of precious RAM by removing
this reservation.
Konrad Dybcio [Sat, 30 Apr 2022 16:23:52 +0000 (18:23 +0200)]
arm64: dts: qcom: msm8998-mtp: Merge and fix up the DT
Merge the two DT files into one, sort the nodes and fix up a couple of style
incoherencies by adding some newlines, removing some, sorting properties etc.
Konrad Dybcio [Sat, 30 Apr 2022 16:23:51 +0000 (18:23 +0200)]
arm64: dts: qcom: msm8998-fxtec: Decouple from 8998 MTP
While the Pro-1 is based on MTP and is very close to it, it's really not great
for it to include the MTP dtsi straight up, as any small change will affect
both boards and not all of them will apply to the phone as well.
MMCC is a component of the SoC that should always be configured. It was kept
off due to misconfiguration on clamshell machines. Keep it disabled on these
ones and enable it by default on all the others.
Exactly the same story applies to MMSS_SMMU, which directly depends on MMCC.
Do note, that if a platform doesn't use neither EFIFB (only applies to WoA
devices in this case) or simplefb (applies to precisely 2 msm8998 devices
as of this commit), this will not cause any harm.
arm64: dts: qcom: sm8250: Disable camcc by default
At the moment there are no changes in SM8250 board files, which require
camera clock controller to run, whenever it is needed for a particular
board, the status of camcc device node will be changed in a board file.
arm64: dts: qcom: sc7280: Set SPI flash to 50 MHz for herobrine boards
sc7280-herobrine based boards are specced to be able to access their
SPI flash at 50 MHz with the drive strength of the pins set at 8. The
drive strength is already set to 8 in "sc7280-herobrine.dtsi", so
let's bump up the clock. The matching firmware change for this is at:
https://review.coreboot.org/c/coreboot/+/63948
NOTE: the firmware change isn't _required_ to make the kernel work at
50 MHz, it merely shows that the boards are known to work fine at 50
MHz.
ALSO NOTE: this doesn't update the "sc7280-chrome-common.dtsi" file
which is used by both herobrine boards and IDP. At the moment the IDP
boards aren't configuring a drive strength of 8 and it seems safer to
just leave them at the slower speed if they're already working.
arm64: dts: qcom: sc7280: Enable wifi for Chrome OS boards
Enable the 'wifi' and 'remoteproc_wpss' nodes for all sc7280
based Chrome OS boards. Delete the corresponding entries from
sc7280-idp.dtsi since this file includes sc7280-chrome-common.dtsi.
This copy-pastes compatibles from sc7280-based boards from the device
trees to the yaml file. It also fixes the CRD/IDP bindings which had
gotten stale.
This copy-pastes compatibles from sc7180-based boards from the device
trees to the yaml file so that `make dtbs_check` will be happy.
NOTES:
- I make no attempt to try to share an "item" for all sc7180 based
Chromebooks. Because of the revision matching scheme used by the
Chromebook bootloader, at times we need a different number of
revisions listed.
- Some of the odd entries in here (like google,homestar-rev23 or the
fact that "Google Lazor Limozeen without Touchscreen" changed from
sku5 to sku6) are not typos but simply reflect reality.
- Many revisions of boards here never actually went to consumers, but
they are still in use within various companies that were involved in
Chromebook development. Since Chromebooks are developed with an
"upstream first" methodology, having these revisions supported with
upstream Linux is important. Making it easy for Chromebooks to be
developed with an "upstream first" methodology is valuable to the
upstream community because it improves the quality of upstream and
gets Chromebooks supported with vanilla upstream faster.
One other note here is that, though the bootloader effectively treats
the list of compatibles in a given device tree as unordered, some
people would prefer future boards to list higher-numbered revisions
first in the list. Chromebooks here are not changing and typically
list lower revisions first just to avoid churn.
Douglas Anderson [Fri, 20 May 2022 21:38:42 +0000 (14:38 -0700)]
dt-bindings: arm: qcom: Mention that Chromebooks use a different scheme
The qcom.yaml bindings file has a whole description of what the
top-level compatible should look like for Qualcomm devices. It doesn't
match what Chromebooks do, so add a link to the Chromebook docs.
Douglas Anderson [Fri, 20 May 2022 21:38:41 +0000 (14:38 -0700)]
dt-bindings: Document how Chromebooks with depthcharge boot
This documents how many Chromebooks pick the device tree that will be
passed to the OS and can help understand the revisions / SKUs listed
as the top-level "compatible" in many Chromebooks.
projects / thirdparty / linux.git / log
