| Age | Commit message (Collapse) | Author |
|---|
|
commit b5fbaf7d779f5f02b7f75b080e7707222573be2a upstream.
Commit b18c6c3c7768 ("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: b18c6c3c7768 ("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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Rockchip SoCs use 2 different numbering schemes. Where the gpio-
controllers just count 0-31 for their 32 gpios, the underlying
iomux controller splits these into 4 separate entities A-D.
Device-schematics always use these iomux-values to identify pins,
so to make mapping schematics to devicetree easier Andy Yan introduced
named constants for the pins but so far we only used them on new
additions.
Using a sed-script created by Emil Renner Berthing bulk-convert
the remaining raw gpio numbers into their descriptive counterparts
and also gets rid of the unhelpful RK_FUNC_x -> x and RK_GPIOx -> x
mappings:
/rockchip,pins *=/bcheck
b # to end of script
:append-next-line
N
:check
/^[^;]*$/bappend-next-line
s/<RK_GPIO\([0-9]\) /<\1 /g
s/<\([^ ][^ ]* *\)0 /<\1RK_PA0 /g
s/<\([^ ][^ ]* *\)1 /<\1RK_PA1 /g
s/<\([^ ][^ ]* *\)2 /<\1RK_PA2 /g
s/<\([^ ][^ ]* *\)3 /<\1RK_PA3 /g
s/<\([^ ][^ ]* *\)4 /<\1RK_PA4 /g
s/<\([^ ][^ ]* *\)5 /<\1RK_PA5 /g
s/<\([^ ][^ ]* *\)6 /<\1RK_PA6 /g
s/<\([^ ][^ ]* *\)7 /<\1RK_PA7 /g
s/<\([^ ][^ ]* *\)8 /<\1RK_PB0 /g
s/<\([^ ][^ ]* *\)9 /<\1RK_PB1 /g
s/<\([^ ][^ ]* *\)10 /<\1RK_PB2 /g
s/<\([^ ][^ ]* *\)11 /<\1RK_PB3 /g
s/<\([^ ][^ ]* *\)12 /<\1RK_PB4 /g
s/<\([^ ][^ ]* *\)13 /<\1RK_PB5 /g
s/<\([^ ][^ ]* *\)14 /<\1RK_PB6 /g
s/<\([^ ][^ ]* *\)15 /<\1RK_PB7 /g
s/<\([^ ][^ ]* *\)16 /<\1RK_PC0 /g
s/<\([^ ][^ ]* *\)17 /<\1RK_PC1 /g
s/<\([^ ][^ ]* *\)18 /<\1RK_PC2 /g
s/<\([^ ][^ ]* *\)19 /<\1RK_PC3 /g
s/<\([^ ][^ ]* *\)20 /<\1RK_PC4 /g
s/<\([^ ][^ ]* *\)21 /<\1RK_PC5 /g
s/<\([^ ][^ ]* *\)22 /<\1RK_PC6 /g
s/<\([^ ][^ ]* *\)23 /<\1RK_PC7 /g
s/<\([^ ][^ ]* *\)24 /<\1RK_PD0 /g
s/<\([^ ][^ ]* *\)25 /<\1RK_PD1 /g
s/<\([^ ][^ ]* *\)26 /<\1RK_PD2 /g
s/<\([^ ][^ ]* *\)27 /<\1RK_PD3 /g
s/<\([^ ][^ ]* *\)28 /<\1RK_PD4 /g
s/<\([^ ][^ ]* *\)29 /<\1RK_PD5 /g
s/<\([^ ][^ ]* *\)30 /<\1RK_PD6 /g
s/<\([^ ][^ ]* *\)31 /<\1RK_PD7 /g
s/<\([^ ][^ ]* *[^ ][^ ]* *\)0 /<\1RK_FUNC_GPIO /g
s/<\([^ ][^ ]* *[^ ][^ ]* *\)RK_FUNC_\([1-9]\) /<\1\2 /g
Suggested-by: Emil Renner Berthing <esmil@mailme.dk>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Acked-by: Robin Murphy <robin.murphy@arm.com>
|
|
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>
|
|
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 981ed1bfbc6c ("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: 48f4d9796d99 ("arm64: dts: rockchip: add Gru/Kevin DTS")
Fixes: 981ed1bfbc6c ("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>
|
|
Add rt5514 dsp of_node to codec list for Gru boards.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.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: 48f4d9796d99 (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>
|
