The CAMSS DTSI device node, which came after the bindings were merged,
got the clocks ordered differently then specified in the bindings:
sdm636-sony-xperia-ganges-mermaid.dtb: camss@ca00000: reg-names:4: 'csid3' was expected
Reordering them to match bindings should not cause ABI issues, because
the driver relies on names, not ordering.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220509144714.144154-2-krzysztof.kozlowski@linaro.org
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]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220507194913.261121-9-krzysztof.kozlowski@linaro.org
The bindings require that every pin configuration comes with 'function'
property. Add such to PM8994 GPIO5.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220507194913.261121-8-krzysztof.kozlowski@linaro.org
The bindings require all PMIC GPIO nodes to have two compatibles -
specific followed by SPMI or SSBI fallback. Add the fallback to fix
warnings like:
msm8916-samsung-serranove.dtb: gpios@c000: compatible: ['qcom,pm8916-gpio'] is too short
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220507194913.261121-7-krzysztof.kozlowski@linaro.org
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]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220507194913.261121-6-krzysztof.kozlowski@linaro.org
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.
[1]: https://lore.kernel.org/linux-arm-msm/20220507153627.1478268-1-marijn.suijten@somainline.org/
Fixes: 30a7f99bef ("arm64: dts: qcom: Add support for SONY Xperia XZ2 / XZ2C / XZ3 (Tama platform)")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220620211212.269956-1-marijn.suijten@somainline.org
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162642.608106-1-konrad.dybcio@somainline.org
It looks like all Tone devices out in the wild are using PMI8996, which
suggests the PMI8994-variant DTs are not needed. Remove them.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162525.607946-1-konrad.dybcio@somainline.org
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162319.607629-1-konrad.dybcio@somainline.org
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162353.607709-14-konrad.dybcio@somainline.org
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162353.607709-13-konrad.dybcio@somainline.org
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.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162353.607709-10-konrad.dybcio@somainline.org
While not strictly necessary, at least on maple, configure the USB extcon,
which requires two pins on Yoshino.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162353.607709-5-konrad.dybcio@somainline.org
Remove the unnecessary level of indentation, commonize SDC2 pins and notice
that SDCC2_CD_ON and _OFF is identical, deduplicate it!
Also, remove some unnecessary overrides and use decimal values in #-cells
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220430162353.607709-1-konrad.dybcio@somainline.org
The dts entry vdda-supply connects to a common vdda-phy-supply rail. Rename
to reflect what the functionality is.
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220111125212.2343184-4-bryan.odonoghue@linaro.org
There's no reason the timer needs > 32-bits of address or size.
Since we using 32-bit size, we need to define ranges properly.
Fixes warnings as:
```
arch/arm64/boot/dts/qcom/sdm845-oneplus-fajita.dt.yaml: timer@17c90000: #size-cells:0:0: 1 was expected
From schema: Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
```
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220626105800.35586-1-david@ixit.cz
DT schema expects names of operating points tables to start with
"opp-table":
ipq6018-cp01-c1.dtb: cpu_opp_table: $nodename:0: 'cpu_opp_table' does not match '^opp-table(-[a-z0-9]+)?$'
Use hyphens instead of underscores, fix the names to match DT schema or
remove the prefix entirely when it is not needed.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220627093250.84391-1-krzysztof.kozlowski@linaro.org
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.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220518091943.734478-1-vladimir.zapolskiy@linaro.org
As we are converting this platform to use DT clock bindings, add clocks
and clock-names properties to the MMCC device tree node.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220617122922.769562-7-dmitry.baryshkov@linaro.org
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.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220505161425.1.Icf6f3796d2fa122b4c0566d9317b461bfbc24b7f@changeid
We don't use this carveout on trogdor boards, and having it defined in
the sc7180 SoC file causes an overlap message to be printed at boot.
OF: reserved mem: OVERLAP DETECTED!
memory@86000000 (0x0000000086000000--0x000000008ec00000) overlaps with memory@8b700000 (0x000000008b700000--0x000000008b710000)
Delete the node in the trogdor dtsi file to fix the overlap problem and
remove the error message.
Cc: Alex Elder <elder@linaro.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Fixes: 310b266655 ("arm64: dts: qcom: sc7180: define ipa_fw_mem node")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220517193307.3034602-1-swboyd@chromium.org
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.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220518155252.1.I176d4254c79cfaafa38cbe36f066f02f819df9b6@changeid
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.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220520143502.v4.4.I1318c1ae2ce55ade1d092fc21df846360b15c560@changeid
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.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220520143502.v4.3.I9804fcd5d6c8552ab25f598dd7a3ea71b15b55f0@changeid
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.
Reported-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220520143502.v4.2.I6418884d8bab6956c7016304f45adc7df808face@changeid
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.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220520143502.v4.1.I71e42c6174f1cec17da3024c9f73ba373263b9b6@changeid
On herobrine boards the keyboard backlight is controlled through the
PWM LED driver. Currently both the PWM LED node and the node for the
keyboard backlight are disabled in sc7280-herobrine.dtsi, which
requires boards with a backlit keyboard to enable both nodes. There
are no other PWM LEDs on herobrine boards besides the keyboard
backlight, delete the 'disabled' status from the keyboard backlight
node, with that boards only have to enable the 'pwmleds' node for
keyboard backlight support.
Also add a label to the 'pwmleds' node to allow board files to refer to
it with a phandle.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220523123157.v2.1.I47ec78581907f7ef024f10bc085f970abf01ec11@changeid
This adds the touchscreen to the sc7280-herobrine-villager device
tree. Note that the touchscreen on villager actually uses the reset
line and thus we use the more specific "elan,ekth6915" compatible
which allows us to specify the reset.
The fact that villager's touchscreen uses the reset line can be
contrasted against the touchscreen for CRD/herobrine-r1. On those
boards, even though the touchscreen goes to the display, it's not
hooked up to anything there.
In order to keep the line parked on herobrine/CRD, we'll move the
pullup from the qcard.dtsi file to the specific boards. This allows us
to disable the pullup in the villager device tree since the pin is an
output.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220524134840.1.I80072b8815ac08c12af8f379a33cc2d83693dc51@changeid
