Several Qualcomm Bluetooth controllers lack persistent storage for the
device address and instead one can be provided by the boot firmware
using the 'local-bd-address' devicetree property.
The Bluetooth bindings clearly states that the address should be
specified in little-endian order, but due to a long-standing bug in the
Qualcomm driver which reversed the address some boot firmware has been
providing the address in big-endian order instead.
The boot firmware in SC7180 Trogdor Chromebooks is known to be affected
so mark the 'local-bd-address' property as broken to maintain backwards
compatibility with older firmware when fixing the underlying driver bug.
Note that ChromeOS always updates the kernel and devicetree in lockstep
so that there is no need to handle backwards compatibility with older
devicetrees.
Fixes: 7ec3e67307 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt")
Cc: stable@vger.kernel.org # 5.10
Cc: Rob Clark <robdclark@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Acked-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The cros_ec driver currently assumes that cros-ec-spi compatible device
nodes are a wakeup-source even though the wakeup-source property is not
defined.
Some Chromebooks use a separate wake pin, while others overload the
interrupt for wake and IO. With the current assumption, spurious wakes
can occur on systems that use a separate wake pin. It is planned to
update the driver to no longer assume that the EC interrupt pin should
be enabled for wake.
Add the wakeup-source property to all cros-ec-spi compatible device
nodes to signify to the driver that they should still be a valid wakeup
source.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
Link: https://lore.kernel.org/r/20240102140734.v4.14.I2ee94aede9e25932f656c2bdb832be3199fa1291@changeid
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
It was asserted that the "/delete-property/ VBAT-supply;" that we
needed to do in the rt5682s dts fragment was ugly. Let's change up all
the trogdor device trees to make it explicit which version of "rt5682"
we have and avoid the need for the "delete-property".
As a side effect, this nicely gets rid of the need for a delete-node
in coachz, which doesn't use "rt5682" at all.
A few notes:
- This doesn't get rid of every "/delete-node/" in trogdor, just the
one that was used for rt5682s.
- Though we no longer have any "/delete-node/", we do still override
the "model" in the "sound" node in one case (in pompom) since that
uses the "2mic" sound setup.
This is validated to produce the same result (other than a few
properties being reordered) when taking the dtbs generated by the
kernel build and then doing:
for dtb in *trogdor*.dtb; do
dtc -I dtb -O dts $dtb -o out/$dtb.dts;
done
Suggested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sheng-Liang Pan <sheng-liang.pan@quanta.corp-partner.google.com>
Link: https://lore.kernel.org/r/20230816112143.2.I29a5a330b6994afca81871f74bbacaf55b155937@changeid
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
When initially submitted, the sc7180 support only targeted CROS devices
that make use of alternative TF-A firmware and not the official Qualcomm
firmware. The PSCI implementations in those firmwares differ however so
devices that use qcom firmware, like WoA laptops such as aspire1 need
different setup.
This commit adjusts the SoC dtsi to the OSI mode PSCI setup, common to
the Qualcomm firmware and introduces new sc7180-firmware-tfa.dtsi that
overrides the PSCI setup for the PC mode and uses TF-A specific
psci-suspend-param. This dtsi is added to all boards that appear to use
TF-A.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20230808-sc7180-tfa-fw-v1-1-666d5d8467e5@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The biggest change this time is for the 32-bit devicetree files, which
are all moved to a new location, using separate subdirectories for each
SoC vendor, following the same scheme that is used on arm64, mips and
riscv. This has been discussed for many years, but so far we never did
this as there was a plan to move the files out of the kernel entirely,
which has never happened.
The impact of this will be that all external patches no longer apply,
and anything depending on the location of the dtb files in the build
directory will have to change. The installed files after 'make
dtbs_install' keep the current location.
There are six added SoCs here that are largely variants of previously
added chips. Two other chips are added in a separate branch along
with their device drivers.
* The Samsung Exynos 4212 makes its return after the Samsung Galaxy
Express phone is addded at last. The SoC support was originally
added in 2012 but removed again in 2017 as it was unused at the time.
* Amlogic C3 is a Cortex-A35 based smart IP camera chip
* Qualcomm MSM8939 (Snapdragon 615) is a more featureful variant of
the still common MSM8916 (Snapdragon 410) phone chip that has been
supported for a long time.
* Qualcomm SC8180x (Snapdragon 8cx) is one of their earlier high-end
laptop chips, used in the Lenovo Flex 5G, which is added along with
the reference board.
* Qualcomm SDX75 is the latest generation modem chip that is used
as a peripherial in phones but can also run a standalone Linux. Unlike
the prior 32-bit SDX65 and SDX55, this now has a 64-bit Cortex-A55.
* Alibaba T-Head TH1520 is a quad-core RISC-V chip based on the Xuantie
C910 core, a step up from all previously added rv64 chips.
All of the above come with reference board implementations, those included
there are 39 new board files, but only five more 32-bit this time, probably
a new low:
* Marantec Maveo board based on dhcor imx6ull module
* Endian 4i Edge 200, based on the armv5 Marvell Kirkwood chip
* Epson Moverio BT-200 AR glasses based on TI OMAP4
* PHYTEC STM32MP1-3 Dev board based on STM32MP15 PHYTEC SOM
* ICnova ADB4006 board based on Allwinner A20
On the 64-bit side, there are also fewer addded machines than
we had in the recent releases:
* Three boards based on NXP i.MX8: Emtop SoM & Baseboard,
NXP i.MX8MM EVKB board and i.MX8MP based Gateworks Venice
gw7905-2x device.
* NVIDIA IGX Orin and Jetson Orin Nano boards, both based on
tegra234
* Qualcomm gains support for 6 reference boards on various members
of their IPQ networking SoC series, as well as the Sony Xperia M4
Aqua phone, the Acer Aspire 1 laptop, and the Fxtec Pro1X board
on top of the various reference platforms for their new chips.
* Rockchips support for several newer boards: Indiedroid Nova (rk3588),
Edgeble Neural Compute Module 6B (rk3588), FriendlyARM NanoPi R2C
Plus (rk3328), Anbernic RG353PS (rk3566), Lunzn Fastrhino R66S/R68S
(rk3568)
* TI K3/AM625 based PHYTEC phyBOARD-Lyra-AM625 board and Toradex Verdin
family with AM62 COM, carrier and dev boards
Other changes to existing boards contain the usual minor improvements
along with
* continued updates to clean up dts files based on dtc warnings and
binding checks, in particular cache properties and node names
* support for devicetree overlays on at91, bcm283x
* significant additions to existing SoC support on mediatek, qualcomm,
ti k3 family, starfive jh71xx, NXP i.MX6 and i.MX8, ST STM32MP1
As usual, a lot more detail is available in the individual merge
commits.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmSdmeUACgkQYKtH/8kJ
UieI5A//bxZXA54htEPXN5V1oIgC4JB4UYkf8fAvtyK4tdaImMn4OTwLD8/sw18X
LQHf1VOLGsGJyNCQ+cUoaBnysr2CXqL/9dA/ARTalqnrKMN/OQjt2wg62n1Ss9Pv
XRlxJABGxAokTO/SuPtOIakSkzwDkuAkIFKfmrNQGcT95XkJXJk3FlMRr84310UG
sl6jP2XFSiLSYm958MMNt+DMhxRmKuyT9gos24KGsb83lZSm9DC2hYimkjd1KF5P
CKeShWeoGoJe+YhnJx6dsDSqVgp1DFLZF1G0auSwjs9rCAKnCDMlz+T2bEzviVDh
XONBNmnOGwPRiBI+1WdzX+pZqMMWINmhIObuODV4ANCSlX3KlSaC2rropEimlW9S
CefvYJ+i7v/BQgMLhKlft0RHhsPU7Pfhfq4PWxaIMAOWA6ZaVczMCpgeUupHIwIQ
lWXZZDlqmTL6SCgkOhEtdP2GGec7YSroq7sscinBaQs1f5pfoW83CNn46gZ9Jh8S
RnXp/+vZ7+RFc15Y0VM82F6a7WN/n0BAqKmqwceDrCpf6ILrBc1lA7NhEvd80wbB
IMg8QNqIzZ9aTOoZmB/1wAXaLClKCE3poTF+Wkd5szN7qe+hKAe1M4w5XvNUO/i/
d0/X5KNA2ykuUxRMdd4lG54VsTJdDCVNaNeaEqasv9JCBBfvuwI=
=X/KE
-----END PGP SIGNATURE-----
Merge tag 'soc-dt-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC devicetree updates from Arnd Bergmann:
"The biggest change this time is for the 32-bit devicetree files, which
are all moved to a new location, using separate subdirectories for
each SoC vendor, following the same scheme that is used on arm64, mips
and riscv. This has been discussed for many years, but so far we never
did this as there was a plan to move the files out of the kernel
entirely, which has never happened.
The impact of this will be that all external patches no longer apply,
and anything depending on the location of the dtb files in the build
directory will have to change. The installed files after 'make
dtbs_install' keep the current location.
There are six added SoCs here that are largely variants of previously
added chips. Two other chips are added in a separate branch along with
their device drivers.
- The Samsung Exynos 4212 makes its return after the Samsung Galaxy
Express phone is addded at last. The SoC support was originally
added in 2012 but removed again in 2017 as it was unused at the
time.
- Amlogic C3 is a Cortex-A35 based smart IP camera chip
- Qualcomm MSM8939 (Snapdragon 615) is a more featureful variant of
the still common MSM8916 (Snapdragon 410) phone chip that has been
supported for a long time.
- Qualcomm SC8180x (Snapdragon 8cx) is one of their earlier high-end
laptop chips, used in the Lenovo Flex 5G, which is added along with
the reference board.
- Qualcomm SDX75 is the latest generation modem chip that is used as
a peripherial in phones but can also run a standalone Linux. Unlike
the prior 32-bit SDX65 and SDX55, this now has a 64-bit Cortex-A55.
- Alibaba T-Head TH1520 is a quad-core RISC-V chip based on the
Xuantie C910 core, a step up from all previously added rv64 chips.
All of the above come with reference board implementations, those
included there are 39 new board files, but only five more 32-bit this
time, probably a new low:
- Marantec Maveo board based on dhcor imx6ull module
- Endian 4i Edge 200, based on the armv5 Marvell Kirkwood chip
- Epson Moverio BT-200 AR glasses based on TI OMAP4
- PHYTEC STM32MP1-3 Dev board based on STM32MP15 PHYTEC SOM
- ICnova ADB4006 board based on Allwinner A20
On the 64-bit side, there are also fewer addded machines than we had
in the recent releases:
- Three boards based on NXP i.MX8: Emtop SoM & Baseboard, NXP i.MX8MM
EVKB board and i.MX8MP based Gateworks Venice gw7905-2x device.
- NVIDIA IGX Orin and Jetson Orin Nano boards, both based on tegra234
- Qualcomm gains support for 6 reference boards on various members of
their IPQ networking SoC series, as well as the Sony Xperia M4 Aqua
phone, the Acer Aspire 1 laptop, and the Fxtec Pro1X board on top
of the various reference platforms for their new chips.
- Rockchips support for several newer boards: Indiedroid Nova
(rk3588), Edgeble Neural Compute Module 6B (rk3588), FriendlyARM
NanoPi R2C Plus (rk3328), Anbernic RG353PS (rk3566), Lunzn
Fastrhino R66S/R68S (rk3568)
- TI K3/AM625 based PHYTEC phyBOARD-Lyra-AM625 board and Toradex
Verdin family with AM62 COM, carrier and dev boards
Other changes to existing boards contain the usual minor improvements
along with
- continued updates to clean up dts files based on dtc warnings and
binding checks, in particular cache properties and node names
- support for devicetree overlays on at91, bcm283x
- significant additions to existing SoC support on mediatek,
qualcomm, ti k3 family, starfive jh71xx, NXP i.MX6 and i.MX8, ST
STM32MP1
As usual, a lot more detail is available in the individual merge
commits"
* tag 'soc-dt-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (926 commits)
ARM: mvebu: fix unit address on armada-390-db flash
ARM: dts: Move .dts files to vendor sub-directories
kbuild: Support flat DTBs install
ARM: dts: Add .dts files missing from the build
ARM: dts: allwinner: Use quoted #include
ARM: dts: lan966x: kontron-d10: add PHY interrupts
ARM: dts: lan966x: kontron-d10: fix SPI CS
ARM: dts: lan966x: kontron-d10: fix board reset
ARM: dts: at91: Enable device-tree overlay support for AT91 boards
arm: dts: Enable device-tree overlay support for AT91 boards
arm64: dts: exynos: Remove clock from Exynos850 pmu_system_controller
ARM: dts: at91: use generic name for shutdown controller
ARM: dts: BCM5301X: Add cells sizes to PCIe nodes
dt-bindings: firmware: brcm,kona-smc: convert to YAML
riscv: dts: sort makefile entries by directory
riscv: defconfig: enable T-HEAD SoC
MAINTAINERS: add entry for T-HEAD RISC-V SoC
riscv: dts: thead: add sipeed Lichee Pi 4A board device tree
riscv: dts: add initial T-HEAD TH1520 SoC device tree
riscv: Add the T-HEAD SoC family Kconfig option
...
Trogdor devices use firmware backed by TF-A instead of Qualcomm's
normal TZ. On TF-A we end up mapping memory as cacheable.
Specifically, you can see in Trogdor's TF-A code [1] in
qti_sip_mem_assign() that we call qti_mmap_add_dynamic_region() with
MT_RO_DATA. This translates down to MT_MEMORY instead of
MT_NON_CACHEABLE or MT_DEVICE. Apparently Qualcomm's normal TZ
implementation maps the memory as non-cacheable.
Let's add the "dma-coherent" attribute to the SCM for trogdor.
Adding "dma-coherent" like this fixes WiFi on sc7180-trogdor
devices. WiFi was broken as of commit 7bd6680b47 ("Revert "Revert
"arm64: dma: Drop cache invalidation from
arch_dma_prep_coherent()"""). Specifically at bootup we'd get:
qcom_scm firmware:scm: Assign memory protection call failed -22
qcom_rmtfs_mem 94600000.memory: assign memory failed
qcom_rmtfs_mem: probe of 94600000.memory failed with error -22
From discussion on the mailing lists [2] and over IRC [3], it was
determined that we should always have been tagging the SCM as
dma-coherent on trogdor but that the old "invalidate" happened to make
things work most of the time. Tagging it properly like this is a much
more robust solution.
[1] https://chromium.googlesource.com/chromiumos/third_party/arm-trusted-firmware/+/refs/heads/firmware-trogdor-13577.B/plat/qti/common/src/qti_syscall.c
[2] https://lore.kernel.org/r/20230614165904.1.I279773c37e2c1ed8fbb622ca6d1397aea0023526@changeid
[3] https://oftc.irclog.whitequark.org/linux-msm/2023-06-15
Fixes: 7bd6680b47 ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""")
Fixes: 7ec3e67307 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt")
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230616081440.v2.3.Ic62daa649b47b656b313551d646c4de9a7da4bd4@changeid
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Currently in board files MDSS and DSI nodes stay apart, because labels
for DSI nodes do not have the mdss_ prefix. It was found that grouping
all display-related notes is more useful.
To keep all display-related nodes close in the board files, change DSI
node labels from dsi_* to mdss_dsi_*.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230531011623.3808538-8-dmitry.baryshkov@linaro.org
mdss is useless without a display controller which makes explicitly
enabling mdp redundant. Have it enabled by default to drop the extra
node for all users.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230515093744.289045-3-nikita@trvn.ru
lpass clocks are usually blocked from HLOS by the firmware and
instead are managed by the ADSP. Mark them as reserved and explicitly
enable in the CrOS boards that have special, cooperative firmware.
The IDP board gets lpass clocks disabled as it doesn't make use of sound
anyway and might use Qualcomm firmware that blocks those clocks. [1]
[1] https://lore.kernel.org/all/ZBJhmDd3zK%2FAiwBD@google.com/
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230515093744.289045-2-nikita@trvn.ru
In commit 7ec3e67307 ("arm64: dts: qcom: sc7180-trogdor: add initial
trogdor and lazor dt") we specified the pull settings on the boot SPI
(the qspi) data lines as pullups to "park" the lines. This seemed like
the right thing to do, but I never really probed the lines to confirm.
Since that time, I've done A LOT of research, experiements and poking
of the lines with a voltmeter.
A first batch of discoveries:
- There is an external pullup on CS (clearly shown on schematics)
- There are weak external pulldowns on CLK/MOSI (believed to be Cr50's
internal pulldowns)
- There is no pull on MISO.
- When qspi isn't actively transferring it still drives CS, CLK, and
MOSI. CS and MOSI are driven high and CLK is driven low. It does not
drive MISO and (if no internal pulls are enabled) the line floats.
The above means that it's good to have some sort of pull on MISO, at
the very least. The pullup that we had before was actually fine (and
my voltmeter confirms that it actually affected the state of the pin)
but a pulldown would work equally well (and would match MOSI and CLK
better).
The above also means that we could save a tiny bit of power (not
measurable by my setup) by setting up a sleep state for these pins. If
nothing else this prevents us from driving high against Cr50's
internal pulldown on MOSI. However, Qualcomm has also asserted in the
past that it burns a little extra power to drive a pin, especially
since these are configured with a slightly higher drive strength
Let's fix all this. Since the external pulls are different for the two
data lines, we'll split them into separate configs. Then we'll change
the MISO pin to a pulldown and add a sleep state.
On a slightly tangental (but not totally unrelated note), I also
discovered some interesting things with these pins in suspend. First,
I found that if we don't switch the pins to GPIO that the qspi
peripheral continues to drive them in suspend. That'll be solved by
what we're already doing above. Second, I found that something in the
system suspend path (after Linux stops running) reconfigures these
pins so that they don't have their normal pulls enabled but instead
change to "keepers" (bias-bus-hold in DT speak). If a pin was floating
before we entered suspend then it would stop floating. I found that I
could manually pull a pin to a different level and then probe it and
it would stay there. This is exactly keeper behavior. With the
solution we have the switch to "keeper" doesn't matter too much but
it's good to document.
While talking about "keepers", it can also be noted that I found that
the "keepers" on these pins were at least enough to win a fight
against Cr50's internal pulls. That means it's best to make sure that
the state of the pins are already correct before the mysterious
transition to a keeper. Otherwise we'll burn (a small amount of) power
in S3 via this fight. Luckily with the current solution we don't hit
this case.
NOTE: I've left "sc7180-idp" behavior totally alone in this patch. I
didn't add a sleep state and I didn't change any pulls--I just adapted
it to the fact that the data lines have separate configs. Qualcomm
doesn't provide me with schematics for IDP and thus I don't actually
know how the pulls are configured. Since this is just a development
platform and worked well enough, it seems safer to leave it alone.
Dependencies:
- This patch has a hard dependency on ("pinctrl: qcom: Support
OUTPUT_ENABLE; deprecate INPUT_ENABLE"). Something in the boot code
seemed to have been confused and thought it needed to set the
"OUTPUT ENABLE" bit for these pins even though it was using them as
SPI. Thus if we don't honor the "output-disable" property we could
end up driving the SPI pins while in sleep mode.
- In general, it's probably best not to backport this to a kernel that
doesn't have commit d21f4b7ffc ("pinctrl: qcom: Avoid glitching
lines when we first mux to output"). That landed a while ago, but
it's still good to be explicit in case someone was backporting. If
we don't have that then there might be a glitch when we first switch
over to GPIO before we disable the output.
- This patch _doesn't_ really have any dependency on the qspi driver
patch that supports setting the pinctrl sleep state--they can go in
either order. If we define the sleep state and the driver never
selects it that's fine. If the driver tries to select a sleep state
that we don't define that's fine.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.12.I6f03f86546e6ce9abb1d24fd9ece663c3a5b950c@changeid
As talked about in the patch ("dt-bindings: pinctrl: qcom: tlmm should
use output-disable, not input-enable"), using "input-enable" in
pinctrl states for Qualcomm TLMM pinctrl devices was either
superfluous or there to disable a pin's output.
Looking at trogdor:
* ap_ec_int_l, fp_to_ap_irq_l, h1_ap_int_odl, p_sensor_int_l:
Superfluous. The pins will be configured as inputs automatically by
the Linux GPIO subsystem (presumably the reference for other OSes
using these device trees).
* bios_flash_wp_l: Superfluous. This pin is exposed to userspace
through the kernel's GPIO API and will be configured automatically.
That means that in none of the cases for trogdor did we need to change
"input-enable" to "output-disable" and we can just remove these
superfluous properties.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.9.I94dbc53176e8adb0d7673b7feb2368e85418f938@changeid
The l13a rail on trogdor devices has always been intended to be
always-on on both S0 and S3. Different trogdor variants use l13a in
slightly different ways, but the overall theme is that it's a 1.8V
rail that the board uses for things that it wants powered in on S0 and
S3. On many boards this includes the boot SPI (AKA qspi).
For all intents and purposes this patch is actually a no-op since
something else in the system seems to already be keeping the rail on
all the time (confirmed via multimeter). That "something else" was
postulated to be the modem but the rail is on / stays on even without
the modem/wifi coming up so it's likely the boot config. In any case,
making the fact that this is always-on explicit seems like a good
idea.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.4.I9f47a8a53eacff6229711a827993792ceeb36971@changeid
Device node names should be generic and bindings expect certain pattern
for RPMh regulator nodes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230127114347.235963-4-krzysztof.kozlowski@linaro.org
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
supported by DP.
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/1672163103-31254-2-git-send-email-quic_khsieh@quicinc.com
Bindings expect DAI children to be named "dai-link":
sc7180-trogdor-coachz-r1.dtb: lpass@62d87000: Unevaluated properties are not allowed ('hdmi@5', 'mi2s@0', 'mi2s@1' were unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221227163158.102737-2-krzysztof.kozlowski@linaro.org
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.
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221209220450.1793421-1-marijn.suijten@somainline.org
On at least one board (pazquel360) the reset line for the touchscreen
was scoped and found to take almost 2 ms to fall when we drove it
low. This wasn't great because the Linux driver for the touchscreen
(the elants_i2c driver) thinks it can do a 500 us reset pulse. If we
bump the drive strength to 8 mA then the reset line went down in ~421
us.
NOTE: we could apply this fix just for pazquel360, but:
* Probably other trogdor devices have similar timings and it's just
that nobody has noticed it before.
* There are other trogdor boards using the same elan driver that tries
to do 500 us reset pulses.
* Bumping the drive strength to 8mA across the board won't hurt. This
isn't a high speed signal or anything.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221209091234.v3.1.I39c387f1e3176fcf340039ec12d54047de9f8526@changeid
The SC7180 MPSS/MSS remote processor can be brought to life using two
different bindings:
1. qcom,sc7180-mpss-pas - currently used in DTSI
2. qcom,sc7180-mss-pil
Move the properties related to qcom,sc7180-mss-pil (qcom,halt-regs,
qcom,spare-regs, resets, additional clocks and regs) to specific boards
using the PIL, to silence DT schema warnings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221124184333.133911-4-krzysztof.kozlowski@linaro.org
The node names should be generic and DT schema expects certain pattern:
qcom/msm8998-oneplus-cheeseburger.dtb: leds: 'button-backlight' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
qcom/sc7180-trogdor-coachz-r1.dtb: pwmleds: 'keyboard-backlight' does not match any of the regexes: '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221125144209.477328-1-krzysztof.kozlowski@linaro.org
The DBVDD and LDO1-IN supplies for rt5682 are required but are missing.
They are supplied by the same power rail as AVDD. Add them.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221102182002.255282-8-nfraprado@collabora.com
Update the fingerprint node on Trogdor to match the fingerprint DT
binding. This will allow us to drive the reset and boot gpios from the
driver when it is re-attached after flashing. We'll also be able to boot
the fingerprint processor if the BIOS isn't doing it for us.
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Cc: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107191535.624371-3-swboyd@chromium.org
DT schema expects TLMM pin configuration nodes to be named with
'-state' suffix and their optional children with '-pins' suffix.
Merge subnodes named 'pinconf' and 'pinmux' into one entry, add function
where missing (required by bindings for GPIOs) and reorganize overriding
pins by boards.
Split the SPI and UART configuration into separate nodes
1. SPI (MOSI, MISO, SCLK), SPI chip-select, SPI chip-select via GPIO,
2. UART per each pin: TX, RX and optional CTS/RTS.
This allows each board to customize them easily without adding any new
nodes.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221020225135.31750-4-krzysztof.kozlowski@linaro.org
This reverts commit e440e30e26 because it
is not a reliable way of fixing SPI CS glitch and it depends on specific
Linux kernel pin controller driver behavior.
This behavior of kernel driver was changed in commit b991f8c362
("pinctrl: core: Handling pinmux and pinconf separately") thus
effectively the DTS fix stopped being effective.
Proper solution for the glitching SPI chip select must be implemented in
the drivers, not via ordering of entries in DTS, and is already
introduced in commit d21f4b7ffc ("pinctrl: qcom: Avoid glitching lines
when we first mux to output").
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221020225135.31750-3-krzysztof.kozlowski@linaro.org
Add missing space or remove redundant one before opening {.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220919163333.129989-1-krzysztof.kozlowski@linaro.org
Add nodes for the onboard USB hub on trogdor devices. Remove the
'always-on' property from the hub regulator, since the regulator
is now managed by the onboard_usb_hub driver.
For anyone using trogdor-based devices on Linux, it should be
noted that this requires "CONFIG_USB_ONBOARD_HUB=y".
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220722093238.v24.1.I7a1a6448d50bdd38e6082204a9818c59cc7a9bfd@changeid
Both vdda-1p2-supply and vdda-0p9-supply regulators are controlled
by dp combo phy. Therefore remove them from dp controller.
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1656690436-15221-1-git-send-email-quic_khsieh@quicinc.com
Trogdor devices that have a detachable keyboard still have a
non-detachable keyboard input device present because we include the
cros-ec-keyboard.dtsi snippet in the top-level sc7180-trogdor.dtsi file
that every variant board includes. We do this because the
keyboard-controller node also provides some buttons like the power
button and volume buttons. Unfortunately, this means we register a
keyboard input device that doesn't do anything on boards with a
detachable keyboard.
Change the node's compatible on detachables to the newly introduced
"google,cros-ec-keyb-switches" compatible to indicate that there are
only switches and no keyboard to register. Similarly, move the keyboard
include that defines the keyboard-controller node out of
sc7180-trogdor.dtsi to boards that actually have a keyboard so that the
matrix properties are not defined on boards with the switches
compatible. Future boards can either use the include approach or the
node definition approach to describe a keyboard with possible switches
or just some switches.
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: "Joseph S. Barrera III" <joebar@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220627212802.3593012-1-swboyd@chromium.org
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
The SoC is always present on sc7180-trogdor.dtsi and thus we should
include it in the "generic" dtsi file for trogdor. Previously we had
removed it from there because we had to do the spi6/spi0 swizzle, so
each trogdor variant board had to include sc7180.dtsi and then
sc7180-trogdor.dtsi so that the latter dtsi file could modify the right
spi bus for EC and H1 properties that are common to all trogdor boards.
Now that we're done with that we can replace sc7180.dtsi includes with
sc7180-trogdor.dtsi and include sc7180.dtsi in sc7180-trogdor.dtsi as
was originally intended. We still need to include sc7180-trogdor.dtsi
before the bridge dtsi files though because those rely on the panel
label.
Cc: "Joseph S. Barrera III" <joebar@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220427020339.360855-4-swboyd@chromium.org
We had to do this spi0/spi6 flip-flop on trogdor-r0 because the spi
buses got swizzled between r0 and r1. The swizzle stopped after r1, but
we kept this around to support either hardware possibility and to keep
trogdor-r0 working.
trogdor-r0 isn't supported upstream, so this swizzle is not doing
anything besides making a pattern that others tryt to copy for the EC and
H1 nodes. Let's remove it and simplify the dts files.
Cc: "Joseph S. Barrera III" <joebar@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220427020339.360855-3-swboyd@chromium.org
Trogdor boards with a detachable keyboard don't have a trackpad over
i2c. Instead the trackpad is on the detachable keyboard base. Let's move
the enabling of the trackpad i2c bus out of the base sc7180-trogdor.dtsi
file so that each trogdor board that is detachable, of which there are
many, doesn't have to disable the trackpad bus.
Cc: "Joseph S. Barrera III" <joebar@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220427020339.360855-2-swboyd@chromium.org
The SAR node, ap_sar_sensor, needs to be enabled in addition to the i2c
bus it resides on. Let's simplify this by leaving the sensor node
enabled by default while leaving the i2c bus disabled by default. On
boards that use the sensor, we already enable the i2c bus so we can
simply remove the extra bit that enables the sar sensor node. This saves
some lines but is otherwise a non-functional change.
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220325211640.54228-1-swboyd@chromium.org
dtschema expects PWM node name to be a generic "pwm". This also matches
Devicetree specification requirements about generic node names.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220214081916.162014-4-krzysztof.kozlowski@canonical.com
All of the other fixed regulators have the "-regulator" suffix. Add it
to pp3300_hub to match.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220202132301.v3.1.I7b284531f1c992932f7eef8abaf7cc5548064f33@changeid
Some trogdor boards have on-board regulators for the MIPI camera
components. Add nodes describing these regulators so boards with these
supplies can consume them.
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-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/20211216044529.733652-1-swboyd@chromium.org
MSM DSI host driver actually parses "data-lanes" in DT and compare
it with the number of DSI lanes the bridge driver sets for
mipi_dsi_device. So we need to always specify "data-lanes" for the
DSI host output. As of now, "data-lanes" is added to ti-sn65dsi86 dts
fragment, but missing in parade-ps8640 dts fragment, which requires
a fixup.
Since we'll do 4-lane DSI regardless of which bridge chip is used,
instead of adding "data-lanes" to parade-ps8640 dts fragment, let's
just move "data-lanes" from the bridge dts to sc7180-trogdor.dtsi.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211029152647.v3.2.If23c83a786fc4d318a1986f43803f22b4b1d82cd@changeid
This is a rather large update for the ARM devicetree files, after a few
quieter releases, with 775 total commits and 47 branches pulled into
this one. There are 5 new SoC types plus some minor variations, and
a total of 60 new machines, so I'm limiting the summary to the main
noteworthy items:
- Apple M1 gain support for PCI and pinctrl, getting a bit
closer to a usable system out of the box.
- Qualcomm gains support for Snapdragon 690 (aka SM6350) as
well as SM7225, 11 new smartphones, and three additional
Chromebooks, and improvements all over the place.
- Samsung gains support for ExynosAutov9, an automotive version
of their smartphone SoC, but otherwise no major changes.
- Microchip adds the SAMA5D29 SoC in the SAMA5 family, and a
number of improvements for the recently added SAMA7 family.
The LAN966 SoC that was added in the platform code does not
have dts files yet. Two board files are added for the older
at91sam9g20 SoC
- Aspeed supports two additional server boards using their AST2600
as BMC, and improves support for qemu models
- Rockchip RK3566/RK3688 gets added, along with six new
development boards using RK3328/RK3399/RK3566, and one
Chromebook tablet.
- Two NAS boxes are added using the ARMv4 based Gemini platform
- One new board is added to the Intel Arria SoC FPGA family
- Marvell adds one network switch based on Armada 381 and the
new MOCHAbin 7040 development board
- NXP adds support for the S32G2 automotive SoC, two imx6 based
ebook readers, and three additional development boards, which
is notably less than their usual additions, but they also gain
improvements to their many existing boards
- STmicroelectronics adds their stm32mp13 SoC family along with
a reference board
- Renesas adds new versions of their R-Car Gen3 SoCs and many
updates for their older generations
- Broadcom adds support for a number of Cisco Meraki wireless
controllers, along with two new boards and other updates for
BCM53xx/BCM47xx networking SoCs and the Raspberry Pi
boards
- Mediatek improves support for the MT81xx SoCs used in Chromebooks
as well as the MT76xx networking SoCs
- NVIDIA adds a number of cleanups and additional support for
more hardware on the already supported machines
- TI K3 adds support for three new boards along with cleanups
- Toshiba adds one board for the Visconti family
- Xilinx adds five new ZynqMP based machines
- Amlogic support is added for the Radxa Zero and two Jethub
home automation controllers, along with changes to other
machines
- Rob Herring continues his work on fixing dtc warnings all over
the tree.
- Minor updates for TI OMAP, Mstar, Allwinner/sunxi, Hisilicon,
Ux500, Unisoc
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmGDCJYACgkQmmx57+YA
GNlIlQ//VOQJeP7Om3Qt3Vai/zvrSWegAagI8quF6m4fTI0D3NVRw4KD7sld1+39
lIcUTdM4eSXO+vsyWRSb9ESyymGGsTy9o8irIDTH2SSyawMwFwydgoO/riS6/tkG
37c9OvCNdjhQIgxo20vW8+dr021UNJqQNG7dQzTJrlbe8IzNGkSjVO5i97v8XK2e
HWtwhOd8W7ptmuTKdq5/DTv0V9LzcJSfWlwYPscHRGHg/t0+frC+G2H3osjgGuux
gbbrdocy1Qmj1sqeAPBud5O2TTEu4M09HYgVWXoKcgBzTt3hJZ9TmzE4YNfUYmv6
sYz+BaPesm2hR+zjBz0wxGG+eP27Zv4FUN/VeMGilRbhXVCv6GSf90fDTbaW4Q8F
IR/BgN0lk2GyNjRyVUcDQI/Aus//TXAI7+rcfXccGBrxs/EBZ3e/hmNNTi9jCMBT
NGLkXAI574tcfLUYybj87upFTPLHTwq4is9p1RY/l73wlcFDZHai+aE2X5GhYLzy
XaYuyur1wA+v5938RjjwCYJjqssz+OlJJP1N2KeQT99PVkS0IunXFJGcsve6UOAN
maRxI4oSU1lz6VaP8tsVJESzObwFCtOdYjgUHpRUJ8JTNTRpy/6JLAX0dnr1LrQV
Fr6gLtodCOa2Udc5T+VkoodAw2f5Gta8cE1fQB9CjUDklkhUtsg=
=jp4P
-----END PGP SIGNATURE-----
Merge tag 'dt-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC DT updates from Arnd Bergmann:
"This is a rather large update for the ARM devicetree files, after a
few quieter releases, with 775 total commits and 47 branches pulled
into this one.
There are 5 new SoC types plus some minor variations, and a total of
60 new machines, so I'm limiting the summary to the main noteworthy
items:
- Apple M1 gain support for PCI and pinctrl, getting a bit closer to
a usable system out of the box.
- Qualcomm gains support for Snapdragon 690 (aka SM6350) as well as
SM7225, 11 new smartphones, and three additional Chromebooks, and
improvements all over the place.
- Samsung gains support for ExynosAutov9, an automotive version of
their smartphone SoC, but otherwise no major changes.
- Microchip adds the SAMA5D29 SoC in the SAMA5 family, and a number
of improvements for the recently added SAMA7 family. The LAN966 SoC
that was added in the platform code does not have dts files yet.
Two board files are added for the older at91sam9g20 SoC
- Aspeed supports two additional server boards using their AST2600 as
BMC, and improves support for qemu models
- Rockchip RK3566/RK3688 gets added, along with six new development
boards using RK3328/RK3399/RK3566, and one Chromebook tablet.
- Two NAS boxes are added using the ARMv4 based Gemini platform
- One new board is added to the Intel Arria SoC FPGA family
- Marvell adds one network switch based on Armada 381 and the new
MOCHAbin 7040 development board
- NXP adds support for the S32G2 automotive SoC, two imx6 based ebook
readers, and three additional development boards, which is notably
less than their usual additions, but they also gain improvements to
their many existing boards
- STmicroelectronics adds their stm32mp13 SoC family along with a
reference board
- Renesas adds new versions of their R-Car Gen3 SoCs and many updates
for their older generations
- Broadcom adds support for a number of Cisco Meraki wireless
controllers, along with two new boards and other updates for
BCM53xx/BCM47xx networking SoCs and the Raspberry Pi boards
- Mediatek improves support for the MT81xx SoCs used in Chromebooks
as well as the MT76xx networking SoCs
- NVIDIA adds a number of cleanups and additional support for more
hardware on the already supported machines
- TI K3 adds support for three new boards along with cleanups
- Toshiba adds one board for the Visconti family
- Xilinx adds five new ZynqMP based machines
- Amlogic support is added for the Radxa Zero and two Jethub home
automation controllers, along with changes to other machines
- Rob Herring continues his work on fixing dtc warnings all over the
tree.
- Minor updates for TI OMAP, Mstar, Allwinner/sunxi, Hisilicon,
Ux500, Unisoc"
* tag 'dt-5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (720 commits)
arm64: dts: apple: j274: Expose PCI node for the Ethernet MAC address
arm64: dts: apple: t8103: Add root port interrupt routing
arm64: dts: apple: t8103: Add PCIe DARTs
arm64: apple: Add PCIe node
arm64: apple: Add pinctrl nodes
ARM: dts: arm: Update ICST clock nodes 'reg' and node names
ARM: dts: arm: Update register-bit-led nodes 'reg' and node names
arm64: dts: exynos: add chipid node for exynosautov9 SoC
ARM: dts: qcom: fix typo in IPQ8064 thermal-sensor node
Revert "arm64: dts: qcom: msm8916-asus-z00l: Add sensors"
arm64: dts: qcom: ipq6018: Remove unused 'iface_clk' property from dma-controller node
arm64: dts: qcom: ipq6018: Remove unused 'qcom,config-pipe-trust-reg' property
arm64: dts: qcom: sm8350: Add CPU topology and idle-states
arm64: dts: qcom: Drop unneeded extra device-specific includes
arm64: dts: qcom: msm8916: Drop standalone smem node
arm64: dts: qcom: Fix node name of rpm-msg-ram device nodes
arm64: dts: qcom: msm8916-asus-z00l: Add sensors
arm64: dts: qcom: msm8916-asus-z00l: Add SDCard
arm64: dts: qcom: msm8916-asus-z00l: Add touchscreen
arm64: dts: qcom: sdm845-oneplus: remove devinfo-size from ramoops node
...
Factor out ti-sn65dsi86 edp bridge as a separate dts fragment.
This helps us introduce the second source edp bridge later.
Signed-off-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211008113839.v3.1.Ibada67e75d2982157e64164f1d11715d46cdc42c@changeid
The current drive strength values are not sufficient on non discrete
boards and this leads to CRC errors during switching to HS400 enhanced
strobe mode.
Hardware simulation results on non discrete boards shows up that use the
maximum drive strength values for data and command lines could helps
in avoiding these CRC errors.
So, update data and command line drive strength values to maximum.
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1629132650-26277-1-git-send-email-sbhanu@codeaurora.org
This should be the dai for display port. Without this set properly we
fail to get audio routed through external displays on trogdor. It looks
like we picked up v4[1] of this patch when there was a v7[2]. The v7
patch still had the wrong sound-dai but at least we can fix all this up
and audio works.
Cc: Srinivasa Rao Mandadapu <srivasam@qti.qualcomm.com>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Douglas Anderson <dianders@chromium.org>
Fixes: b22d313e17 ("arm64: dts: qcom: sc7180-trogdor: Add lpass dai link for HDMI")
Link: https://lore.kernel.org/r/20210721080549.28822-3-srivasam@qti.qualcomm.com [1]
Link: https://lore.kernel.org/r/20210726120910.20335-3-srivasam@codeaurora.org [2]
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210811224141.1110495-1-swboyd@chromium.org
Putting the panel under the bridge chip (under the aux-bus node)
allows the panel driver to get access to the DP AUX bus, enabling all
sorts of fabulous new features.
While we're at this, get rid of a level of hierarchy for the panel
node. It doesn't need "ports / port" and can just have a "port" child.
For Linux, this patch has a hard requirement on the patches adding DP
AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch
("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210611101711.v10.11.Ibdb7735fb1844561b902252215a69526a14f9abd@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This spi flash part is actually being clocked at 37.5MHz, not 25MHz,
because of the way the clk driver is rounding up the rate that is
requested to the nearest supported frequency. Let's update the frequency
here, and remove the TODO because this is the fastest frequency we're
going to be able to use here.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210519054030.3217704-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Johan Hovold