rk3399-gru chromebooks have a regulator chains where one named regulator
supplies multiple regulators pp900-usb pp900_pcie that supply
the named peripherals.
The dtsi used somewhat creative structure to describe that in creating
the base node 3 times with different phandles and describing the EC
dependency in a comment.
This didn't register in the recent regulator-node renaming, as the
additional nodes were empty, so adapt the missing node names for now.
Fixes: 5c96e63301 ("arm64: dts: rockchip: adapt regulator nodenames to preferred form")
Tested-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250116143631.3650469-1-heiko@sntech.de
The preferred nodename for fixed-regulators has changed to
pattern: '^regulator(-[0-9]+v[0-9]+|-[0-9a-z-]+)?$'
Fix all Rockchip DT regulator nodenames.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/0ae40493-93e9-40cd-9ca9-990ae064f21a@gmail.com
[adapted rebased on top of a number of other changes and included
neu6a-wifi + wolfvision-pf5-io-expander overlays]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Rename the Rockchip RK3399 SoC dtsi files and, consequently, adjust their
contents and the contents of the affected board dts(i) files appropriately,
to "encapsulate" the different CPU and GPU OPPs for each of the supported
RK3399 SoC variants into the respective SoC variant dtsi files.
Moving the OPPs to the SoC variant dtsi files, instead of requiring the
board dts(i) files to include both the SoC variant dtsi file and the right
OPP variant dtsi file, reduces the possibility for mismatched inclusion and
improves the overall hierarchical representation of data.
These changes follow the approach used for the Rockchip RK3588 SoC variants,
which was introduced and described further in commit def88eb4d8 ("arm64:
dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs"). Please
see that commit for a more detailed explanation.
No functional changes are introduced, which was validated by decompiling and
comparing all affected dtb files before and after these changes. In more
detail, all decompiled dtb files remain exactly the same, except the files
list below, which results from all of them stemming from the same base board
dtsi file (rk3399-rock-pi-4.dtsi), while all of them include one of the three
different RK3399 SoC variant dtsi files by themselves:
- rk3399-rock-4se.dtb
- rk3399-rock-pi-4a.dtb
- rk3399-rock-pi-4a-plus.dtb
- rk3399-rock-pi-4b.dtb
- rk3399-rock-pi-4b-plus.dtb
- rk3399-rock-pi-4c.dtb
When compared with the decompiled original dtb files, these dtb files have
some of their blocks shuffled around a bit and some of their phandles have
different values, as a result of the changes to the order in which the
building blocks from the parent dtsi files are included into them, but they
still effectively remain the same as the originals.
The only exception to the "include only a SoC variant dtsi" is found in
rk3399-evb.dts, which includes rk3399-base.dtsi instead of rk3399.dtsi.
This is intentional, because this board dts file doesn't enable the TSADC,
so including rk3399.dtsi would enable the SoC to go into higher OPPs with
no thermal throttling in place. Let's hope that people interested in this
board will fix this in the future.
As a side note, due to the nature of introduced changes, this commit is best
viewed using the --break-rewrites option for git-log(1).
Related-to: def88eb4d8 ("arm64: dts: rockchip: Prepare RK3588 SoC dtsi files for per-variant OPPs")
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/9417b5c5b64f9aceea64530a85a536169a3e7466.1721532747.git.dsimic@manjaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to Documentation/devicetree/bindings/sound/dialog,da7219.yaml,
the value of `dlg,jack-det-rate` property should be "32_64" instead of
"32ms_64ms".
Fixes: dc0ff0fa3a ("ASoC: da7219: Add Jack insertion detection polarity")
Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
Link: https://lore.kernel.org/r/20240613-jack-rate-v2-2-ebc5f9f37931@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The rk3399-gru PCI node addresses are wrong.
In rk3399-gru-scarlet, the bus number in the address should be 0. This is
because bus number assignment is dynamic and not known up front. For FDT,
the bus number is simply ignored.
In rk3399-gru-chromebook, the addresses are simply invalid. The first
"reg" entry must be the configuration space for the device. The entry
should be all 0s except for device/slot and function numbers. The existing
64-bit memory space (0x83000000) entries are not valid because they must
have the BAR address in the lower byte of the first cell.
Warnings for these are enabled by adding the missing 'device_type = "pci"'
for the root port node.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231130191830.2424361-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The recommended name for enable GPIOs property in regulator-gpio is
enable-gpios. This is also required by bindings:
rk3399-gru-bob.dtb: ppvar-sd-card-io: Unevaluated properties are not allowed ('enable-gpio' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230725142616.157405-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the DMC (Dynamic Memory Controller) and the DFI (DDR PHY
Interface) nodes on gru boards so we can support DDR DVFS.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Gaël PORTAY <gael.portay@collabora.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220308110825.v4.12.I3a5c7f21ecd8221b42c2dbcd618386bce7b3e9a6@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Commit b18c6c3c77 ("ASoC: rockchip: cdn-dp sound output use spdif")
switched the platform to SPDIF, but we didn't fix up the device tree.
Drop the pinctrl settings, because the 'spdif_bus' pins are either:
* unused (on kevin, bob), so the settings is ~harmless
* used by a different function (on scarlet), which causes probe
failures (!!)
Fixes: b18c6c3c77 ("ASoC: rockchip: cdn-dp sound output use spdif")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20220114150129.v2.1.I46f64b00508d9dff34abe1c3e8d2defdab4ea1e5@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Nodes with compatible "jedec,spi-nor" are now checked with
jedec,spi-nor.yaml and mtd.yaml. The pattern is now
"^flash(@.*)?$", so change that for the boards with a
Rockchip SoC.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210711145900.15443-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
A test with the command below gives this error:
/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dt.yaml:
sdmmcio-regulator: states:0:
[1800000, 1, 3300000, 0] is too long
dtbs_check expects regulator-gpio states in a format
of 2 per item, so fix them all.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/
regulator/gpio-regulator.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210510215840.16270-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-7-heiko@sntech.de
A test with the command below gives for example this error:
arch/arm64/boot/dts/rockchip/rk3326-odroid-go2.dt.yaml:
tsadc: tsadc-otp-gpio:
{'phandle': [[90]], 'rockchip,pins': [[0, 6, 0, 123]]}
is not of type 'array'
'gpio' is a sort of reserved nodename and should not be used
for pinctrl in combination with 'rockchip,pins', so change
nodes that end with 'gpio' to end with 'pin' or 'pins'.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/
dtschema/schemas/gpio/gpio.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200524160636.16547-2-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The cros-ec-extcon has no reg property so remove the unit address from
the DT node to make DT compiler happy.
While here, remove the inexistent extcon-cells property from the extcon
nodes.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20200207141324.3188898-1-enric.balletbo@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Currently, we don't coordinate BT USB activity with our handling of the
BT out-of-band wake pin, and instead just use gpio-keys. That causes
problems because we have no way of distinguishing wake activity due to a
BT device (e.g., mouse) vs. the BT controller (e.g., re-configuring wake
mask before suspend). This can cause spurious wake events just because
we, for instance, try to reconfigure the host controller's event mask
before suspending.
We can avoid these synchronization problems by handling the BT wake pin
directly in the btusb driver -- for all activity up until BT controller
suspend(), we simply listen to normal USB activity (e.g., to know the
difference between device and host activity); once we're really ready to
suspend the host controller, there should be no more host activity, and
only *then* do we unmask the GPIO interrupt.
This is already supported by btusb; we just need to describe the wake
pin in the right node.
We list 2 compatible properties, since both PID/VID pairs show up on
Scarlet devices, and they're both essentially identical QCA6174A-based
modules.
Also note that the polarity was wrong before: Qualcomm implemented WAKE
as active high, not active low. We only got away with this because
gpio-keys always reconfigured us as bi-directional edge-triggered.
Finally, we have an external pull-up and a level-shifter on this line
(we didn't notice Qualcomm's polarity in the initial design), so we
can't do pull-down. Switch to pull-none.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This adds the 32k clock to the RK3399 Gru board file, which is provided
by a Silego oscillator on Gru boards.
Even though it's not directly used, muxes will end up traversing the
entire clk tree on calls to determine_rate if it doesn't exist. This
is because the 32k clk is listed as a possible parent on some clks.
Since the clk doesn't know about the 32k clk (it was never registered),
it triggers a global search for it. This can happen about 40 times per
second, which isn't great for power.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
[moved clock position and adapted commit message a bit]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Similar to rk3288-Veyron before, the Gru-series does contain Chromebook
(aka clamshell laptops) and non-Chromebook devices. And while the two
Chromebook devices Kevin and Bob are quite similar, Scarlet the tablet-
device is quite different in its design.
Therefore move the Chromebook parts into a gru-chromebook dtsi file
to make sharing easier.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Some nodes will need to be refined on a per board level, so add phandles
to them to reference them later.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Update all 64bit rockchip devicetree files to use SPDX-License-Identifiers.
All devicetrees claim to be either GPL or X11 while the actual license
text is MIT. Therefore we use MIT for the SPDX tag as X11 is clearly
wrong.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Acked-by: Brian Norris <briannorris@chromium.org>
Acked-by: Matthias Brugger <mbrugger@suse.com>
Acked-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
These clocks do not assign default clock frequency, and use the
default cru register value to get frequency, so if cpll increase
frequency, these clocks also increase their frequency, that may
exceed their signed off frequency. So assign default clock for
them to avoid it.
NOTE: on none of the boards currently in mainline do we expect
CPLL to be anything other than 800 MHz, but some future boards
might have it. It's still good to be explicit about the clock
rates to make diffing against future boards easier and also to
rely less on BIOS muxing.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This is the usual set of changes for device trees, with over 700
non-merged changesets. There is an ongoing set of dtc warning fixes and
the usual bugfixes, cleanups and added device support.
The most interesting bit as usual is support for new machines listed
below:
- The Allwinner H6 makes its debut with the Pine-H64 board, and we get
two new machines based on its older siblings: the H5 based OrangePi
Zero+ and the A64 based Teres-I Laptop from Olimex. On the 32-bit side,
we add The Olimex som204 based on Allwinner A20, and the Banana Pi M2
Zero development board (based on H2).
- NVIDIA adds support for Tegra194 aka "Xavier", plus their p2972
development board and p2888 CPU module.
- The Nuvoton npcm750 is a BMC that was newly added, for now we only
support running on the evaluation board.
- STmicroelectronics stm32 gains support for the stm32mp157c and two
evaluation boards.
- The Toradex Colibri board family grows a few members based on the
i.MX6ULL variant.
- The Advantec DMS-BA16 is a Qseven module using the NXP i.MX6
family of chips.
- The Phytec phyBOARD Mira is a family of industrial boards based on
i.MX6. For now, four models get added.
- TI am335x based PDU-001 is an industrial embedded machine used for
traffic monitoring
- The Aspeed platform now supports running on the BMC on the Qualcomm
Centriq 2400 server
- Samsung Exynos4 based Galaxy S3 is a family of mobile phones Qualcomm
msm8974 based Galaxy S5 is a rather different phone made by the same
company.
- The Xilinx Zynq and ZynqMP platforms now gained a lot of dts file
for the various boards made by Xilinx themselves, as well as the
Digilent Zybo Z7.
- The ARM Versatile family now supports the "IB2" interface board.
- The Renesas H2 based "Stout" and the H3 based Salvator-X are more
evaluation boards named after a kind of beer, as most of them are.
The r8a77980 (V3H) based "Condor" apparently doesn't follow that
tradition. ;-)
- ROC-RK3328-CC is a simple developement board from the Libre Computer
Project, based on the Rockchips RK3328 SoC
- Haiku is another development board plus Qseven module based on Rockchips
RK3368 and made by Theobroma Systems.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJaxjFeAAoJEGCrR//JCVInw2gQALS/sK83IJE0Ngw98Cko8fqn
NnbaLaZybajRCdZfXFrIgyL1YijsK4eeniA6zXvFixctlx0FcH2Ep1merbFa52Il
bZKDOeCr6JfSggk2pZvnC7efwAsc5qMmSGU7KgvUV9vgAXTXANdTlVttoBrZldvI
baR5W34BjcXRvA14FyxUPiQgGiCft3rE2ZJA9CqJQ9W44vxnTpbcYpimwya8LWss
hhbJ8P73HhVsKlwS4QXajpLJSo52VdhGDZCd/MwH1yWjzgQZ7O2ijSFz3jYmvdZf
1guE1FhcpHX8/0j1v5OqfEFAjaFUl+Fef11McUlGe4lVM2C47kuNEil//cb4pJ2j
ipQ0qR26GkoBmoxSlt0cI9yUtSemTWzZZSLeTPNQGytb7hRNdR22xwf2vr9Eh6dB
PMG2G0VXVp5Xuif+3iDLxFKiPsBsN49RGtqOj6p9eZhbTIRjgQ5671T3Kla0KRLH
CFlWyYYrRqtUVeM3XSXmNQb9pyuCDqOlLyVngDbCuz4HIly3I2kgSYLTCFZx5FfT
kkVbNy+cO/TOkX8w1P8XiRDGQ16YHQ5kjvy1mUPiPEnf70L2gD8HXWeVX1J2SXzF
OoeNJTzON0cpvtUaM/4hsASi5mHz8rv8CTH8HUviRlXvSH/7JqlM2XqhWSVJ+gYZ
S7/RgDEviOzsHBf/EMUN
=7rHo
-----END PGP SIGNATURE-----
Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC device tree updates from Arnd Bergmann:
"This is the usual set of changes for device trees, with over 700
non-merged changesets. There is an ongoing set of dtc warning fixes
and the usual bugfixes, cleanups and added device support.
The most interesting bit as usual is support for new machines listed
below:
- The Allwinner H6 makes its debut with the Pine-H64 board, and we
get two new machines based on its older siblings: the H5 based
OrangePi Zero+ and the A64 based Teres-I Laptop from Olimex. On the
32-bit side, we add The Olimex som204 based on Allwinner A20, and
the Banana Pi M2 Zero development board (based on H2).
- NVIDIA adds support for Tegra194 aka "Xavier", plus their p2972
development board and p2888 CPU module.
- The Nuvoton npcm750 is a BMC that was newly added, for now we only
support running on the evaluation board.
- STmicroelectronics stm32 gains support for the stm32mp157c and two
evaluation boards.
- The Toradex Colibri board family grows a few members based on the
i.MX6ULL variant.
- The Advantec DMS-BA16 is a Qseven module using the NXP i.MX6 family
of chips.
- The Phytec phyBOARD Mira is a family of industrial boards based on
i.MX6. For now, four models get added.
- TI am335x based PDU-001 is an industrial embedded machine used for
traffic monitoring
- The Aspeed platform now supports running on the BMC on the Qualcomm
Centriq 2400 server
- Samsung Exynos4 based Galaxy S3 is a family of mobile phones
Qualcomm msm8974 based Galaxy S5 is a rather different phone made
by the same company.
- The Xilinx Zynq and ZynqMP platforms now gained a lot of dts file
for the various boards made by Xilinx themselves, as well as the
Digilent Zybo Z7.
- The ARM Versatile family now supports the "IB2" interface board.
- The Renesas H2 based "Stout" and the H3 based Salvator-X are more
evaluation boards named after a kind of beer, as most of them are.
The r8a77980 (V3H) based "Condor" apparently doesn't follow that
tradition. ;-)
- ROC-RK3328-CC is a simple developement board from the Libre
Computer Project, based on the Rockchips RK3328 SoC
- Haiku is another development board plus Qseven module based on
Rockchips RK3368 and made by Theobroma Systems"
* tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (701 commits)
arm: dts: modify Nuvoton NPCM7xx device tree structure
arm: dts: modify Makefile NPCM750 configuration name
arm: dts: modify clock binding in NPCM750 device tree
arm: dts: modify timer register size in NPCM750 device tree
arm: dts: modify UART compatible name in NPCM750 device tree
arm: dts: add watchdog device to NPCM750 device tree
arm64: dts: uniphier: add ethernet node for PXs3
ARM: dts: uniphier: add pinctrl groups of ethernet for second instance
arm: dts: kirkwood*.dts: use SPDX-License-Identifier for board using GPL-2.0+
arm: dts: kirkwood*.dts: use SPDX-License-Identifier for boards using GPL-2.0+/MIT
arm: dts: kirkwood*.dts: use SPDX-License-Identifier for boards using GPL-2.0
arm: dts: armada-385-turris-omnia: use SPDX-License-Identifier
arm: dts: armada-385-db-ap: use SPDX-License-Identifier
arm: dts: armada-388-rd: use SPDX-License-Identifier
arm: dts: armada-xp-db-xc3-24g4xg: use SPDX-License-Identifier
arm: dts: armada-xp-db-dxbc2: use SPDX-License-Identifier
arm: dts: armada-370-db: use SPDX-License-Identifier
arm: dts: armada-*.dts: use SPDX-License-Identifier for most of the Armada based board
arm: dts: armada-xp-98dx: use SPDX-License-Identifier for prestara 98d SoCs
arm: dts: armada-*.dtsi: use SPDX-License-Identifier for most of the Armada SoCs
...
The ACLK_VIO is a parent clock used by a several children,
its suggested clock rate is 400MHz. Right now it gets 400MHz
because it sources from CPLL(800M) and divides by 2 after reset.
It's good not to rely on default values like this, so let's
explicitly set it.
NOTE: it's expected that at least one board may override cru node and
set the CPLL to 1.6 GHz. On that board it will be very important to be
explicit about aclk-vio being 400 MHz.
Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Back in the early days when gru devices were still under development
we found an issue where the WiFi reset line needed to be configured as
early as possible during the boot process to avoid the WiFi module
being in a bad state.
We found that the way to get the kernel to do this in the earliest
possible place was to configure this line in the pinctrl hogs, so
that's what we did. For some history here you can see
<http://crosreview.com/368770>. After the time that change landed in
the kernel, we landed a firmware change to configure this line even
earlier. See <http://crosreview.com/399919>. However, even after the
firmware change landed we kept the kernel change to deal with the fact
that some people working on devices might take a little while to
update their firmware.
At this there are definitely zero devices out in the wild that have
firmware without the fix in it. Specifically looking in the firmware
branch several critically important fixes for memory stability landed
after the patch in coreboot and I know we didn't ship without those.
Thus, by now, everyone should have the new firmware and it's safe to
not have the kernel set this up in a pinctrl hog.
Historically, even though it wasn't needed to have this in a pinctrl
hog, we still kept it since it didn't hurt. Pinctrl would apply the
default hog at bootup and then would never touch things again. That
all changed with commit 981ed1bfbc ("pinctrl: Really force states
during suspend/resume"). After that commit then we'll re-apply the
default hog at resume time and that can screw up the reset state of
WiFi. ...and on rk3399 if you touch a device on PCIe in the wrong way
then the whole system can go haywire. That's what was happening.
Specifically you'd resume a rk3399-gru-* device and it would mostly
resume, then would crash with some crazy weird crash.
One could say, perhaps, that the recent pinctrl change was at fault
(and should be fixed) since it changed behavior. ...but that's not
really true. The device tree for rk3399-gru is really to blame.
Specifically since the pinctrl is defined in the hog and not in the
"wlan-pd-n" node then the actual user of this pin doesn't have a
pinctrl entry for it. That's bad.
Let's fix our problems by just moving the control of
"wlan_module_reset_l pinctrl" out of the hog and put them in the
proper place.
NOTE: in theory, I think it should actually be possible to have a pin
controlled _both_ by the hog and by an actual device. Once the device
claims the pin I think the hog is supposed to let go. I'm not 100%
sure that this works and in any case this solution would be more
complex than is necessary.
Reported-by: Marc Zyngier <marc.zyngier@arm.com>
Fixes: 48f4d9796d ("arm64: dts: rockchip: add Gru/Kevin DTS")
Fixes: 981ed1bfbc ("pinctrl: Really force states during suspend/resume")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable cdn_dp and create a cdn-dp-sound for the DP audio. Delete the
endpoints between dp and vopL for gru, since we want the DP only use
VOP big, which can support 4K mode.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
[dropped vop-hacks]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add edp panel and enable related nodes on kevin.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Mark Yao <mark.yao@rock-chips.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Currently we are assigning mic irq to rt5514 i2c driver, which is wrong.
Assign it to rt5514 spi driver instead.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to rt5514 dt-binding, it should be "realtek,dmic-init-delay-ms".
Fixes: 48f4d9796d (arm64: dts: rockchip: add Gru/Kevin DTS)
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch enables the gpu and adds the mali-supply power for RK3399-GRU
devices.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Gru device tree currently contains entries for the regulators
ppvar_bigcpu, ppvar_litcpu, ppvar_gpu and ppvar_centerlogic; however,
the regulators have not been enabled, due to the lack of binding and driver
support for keeping the over-voltage protection (OVP) at bay and
preventing unintended regulator shutdowns on voltage downshifts.
Now, the vctrl regulator driver has been merged, along with new bindings
for asymmetric settling time. The driver is OVP aware, it splits larger
voltage decreases in multiple steps when necessary and adds required
delays.
This change renames each of the aforementioned regulators to
<orig_name>_pwm and adds a new vctrl regulator named <orig_name>.
The vctrl regulators use the voltage of their corresponding PWM regulator
as control voltage. The OVP related values are empirical and stem from
the Chrome OS kernel tree.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
[fixed node names and parent supplies of gpu and centerlogic]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gru derivatives besides Kevin have slightly different voltage ranges for
their CPU regulators. Let's keep the base Gru file accurate and let
Kevin override.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
replace all occurrences of sdmcc with sdmmc in the arm64 rockchip
devicetree files.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The OP1 is a rk3399 variant used in ChromeOS devices with a slightly
higher frequency rating compared to the regular rk3399, but right now
the only available operating points don't match either variant
with both needing adjustments to actually fit their specs.
Therefore introduce separate operting points, from the ChromeOS kernel,
for the OP1 and use it on Gru devices.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Used for Gru/Kevin only, as they're the only ones which have a described
CPU regulator. Also, I'm not sure we've validated this table non-Gru
boards.
At the same time, partially describe PWM regulators for Gru, so cpufreq
doesn't think it can crank up the clock speed without changing the
voltage. However, we don't yet have the DT bindings to fully describe
the Over Voltage Protection (OVP) circuits on these boards. Without that
description, we might end up changing the voltage too much, too fast.
Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
them disabled.
Signed-off-by: Brian Norris <briannorris@chromium.org>
[shared gru/kevin parts on a gru device]
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
[with a bit of reordering]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Kevin is part of a family of boards called Gru. As best as possible, the
properties shared by the Gru family are placed in rk3399-gru.dtsi, while
Kevin-specific bits are in rk3399-gru-kevin.dts. This does not add full
support for the base Gru board.
Working and tested (to some extent):
* EC support -- including keyboard, battery, PWM, and probably more
* UART / console
* Thermal
* Touchscreen
* Touchpad
* Digitizer (regulator still WIP)
* PCIe / Wifi
* Bluetooth / Webcam
* SD card
* eMMC
* USB2 on TypeC
- This works much of the time, but USB3 devices may or may not detect
properly. Waiting on proper extcon support for USB3 over TypeC.
- Depends on XHCI/DWC3 fixes for ARM64 that still haven't landed
* Backlight
Not working:
* CPUFreq -- relies on special OVP support for our PWM regulator
circuits
* EC / extcon support -- and with it, USB3/TypeC/DP
* DRM -- won't even build on ARM64, so all display, eDP, etc. is not
enabled
Not tested:
* Audio
Signed-off-by: Brian Norris <briannorris@chromium.org>
[shared gru/kevin parts on a gru device]
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
[with a bit of reordering]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
