Граф коммитов

16 Коммитов

Автор SHA1 Сообщение Дата
Javier Martinez Canillas 3adf89324a arm64: dts: rockchip: Remove non-existing pwm-delay-us property
There is neither a driver that parses this nor a DT binding schema that
documents it, so let's remove from the DTS files that make use of this.

The properties that exist are post-pwm-on-delay-ms and pwm-off-delay-ms,
defined in the pwm-backlight DT binding. If the delays are really needed
then those properties should be used instead.

Brian Norris mentioned though that looking at the first downstream usage
of the pwm-delay-us property for RK3399 Gru systems in ChromiumOS tree,
he couldn't find a spec reference that said that this was really needed.

So perhaps it was unnecessary added and a simple removal would be enough.

Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20230330231924.2404747-1-javierm@redhat.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2023-03-31 02:44:27 +02:00
Brian Norris ef40e88d1b arm64: dts: rockchip: Drop RK3399-Scarlet's repeated ec_ap_int_l definition
This is repeated a few lines down.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20221013213336.1779917-1-briannorris@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-10-17 13:49:11 +02:00
Judy Hsiao 91419ae042 arm64: dts: rockchip: use BCLK to GPIO switch on rk3399
We discoverd that the state of BCLK on, LRCLK off and SD_MODE on
may cause the speaker melting issue. Removing LRCLK while BCLK
is present can cause unexpected output behavior including a large
DC output voltage as described in the Max98357a datasheet.

In order to:
  1. prevent BCLK from turning on by other component.
  2. keep BCLK and LRCLK being present at the same time

This patch adjusts the device tree to allow BCLK to switch
to GPIO func before LRCLK output, and switch back during
LRCLK is output.

Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20220708080726.4170711-1-judyhsiao@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-09-10 01:08:48 +02:00
Linus Torvalds 3976d758e0 ARM: DT changes for 6.0
As usual, the bulk of the changes for the SoC tree are devicetree file
 updates, and most of these changes are for 64-bit embedded machines.
 As before, there are a ton of style cleanups, and additional hardware
 support for existing machines.
 
 Looking only at the new SoC, the notable additions are:
 
  - A whole family of Broadcom broadband SoCs, both 32-bit and 64-bit:
    BCM63178, BCM63158, BCM4912, BCM6858, BCM6878, BCM6846, BCM63146,
    BCM6856, BCM6855, BCM6756, BCM63148, and BCM6813.
    Each SoC comes with a corresponding reference board.
 
  - The new NXP i.MX93 SoC, the follow-up to the popular i.MX6 and
    i.MX8 embedded SoCs, now using Cortex-A55 cores and the
    Ethos-U65 NPU.
 
  - Qualcomm Snapdragon 8cx Gen3 (SC8280XP), the current high end
    of Arm based Laptop SoCs, and its automotive cousin, the
    SA8540P. The SC8280XP is used in the Lenovo Thinkpad X13s
    laptop that also gets added here in addition to the reference
    boards.
 
  - Allwinner H616, a newer version of the H6 SoC, targeted at
    Set-top-box applications. It comes with dts files for the
    Orange Pi zero2 single-board computer and the X96 Mate
    set-top-box
 
  - Marvell Prestera 98DX2530 (AlleyCat5), a network switch chip
    in the Armada SoC family based on the Cortex-A55 core.
 
 New machines based on previously supported SoCs include:
 
  - Several new machines on NXP i.MX platforms: multiple Toradex
    Colibri boards using the "Iris" and "Ixora" carriers,
    DH electronics i.MX8M Plus DHCOM and PDK2, TQ-Systems
    TQMa8MPQL, and phytech phyBOARD-Polis-i.MX8MM.
 
  - Google Chameleon v3 FPGA board based on Intel Arria10 and
    Stratix 10 Software Virtual platform, both in the SoCFPGA
    platform.
 
  - Two new wireless devices based on Broadcom SoCs:
    The Asus GT-AX6000 Router and the Cisco Meraki MR26 access point
 
  - Improved Chromebook support for both the Mediatek and Qualcomm
    SoC families brought added machines: Acer Chromebook 514 (MT8192),
    Acer Chromebook Spin 513 (MT8195) and a couple of SC7180 based
    machines including the Lenovo IdeaPad Chromebook Duet 3.
 
  - Xiaomi Mi Mix2s, LG G7 and LG V35 are mobile phones based on
    Qualcomm SDM845, while Mi 5s Plus is based on MSM8996.
 
  - Finally, there are a few development board on other chips:
    PCB8309 (Microchip lan966x), Radxa Rock Pi S (Rockchips RK3308)
    DH DRC Compact (ST STM32MP1) and Inforce IFC6560 (Qualcomm
    SDM660)
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLo+7MACgkQmmx57+YA
 GNlTQQ//QnOoW3fl2l4TvuBuP1Vxp7KW3GxZEkWBEfy7lfgkfBzksJ2GT+c96fxk
 +XEvSJcDsSo8zNYXXu/q0jjVKW4lEkiBtaB53NbLayNTFtJccKPiL4hccUkwSg1K
 zOhfu6SEgkwuYNAhtcQOfIec+gdF2PvpZSWUfuGvM2Z3rNhhyfhgoRRZCpc62eeS
 VQ+bVJH/7hG4XAJEcwmNK+8GoCcLbOclCa14oa9/LuEVjfYwOblfPjSflmfALzbM
 BoTDdeMbZoOdy3LOmLpT26Wv7zWQxLhTpiSYiSV0CI4NHUfzJj8ncNh+w9OiN+KO
 Z7cblHhveW5WSEP/jDp9YTf2XXA5UgpFQQjuXS8zQVECw5YxrSBB96GroQhvpcmT
 oSS0BVvlmp5snBRx4Oev2ldJ0BuyYYljF0DmmTrQ6s2gvB4WBlRSqplCAkDy59Im
 +mc5BBTqZYoxzCpzXEZR7VPzk1jzAO5wnYYd1mLJSHVExlSw8CQijy1a4YXxsvmK
 4Sysrm8UbmPN/0anbiyPKeIkuNuufFUvUCR3Vm2HnMzNPza8YBJ0xm6zr8J7ecXe
 QcucpXyLi17GTLOm+pcyj2fQ19yVqO3xbutP4sy9StctEXLZe3rH2hY+GPK6N+Uj
 83MbABMCmpUAyPMzR0AwTKx/RwWbf1jjYvcKg2VW8NNV5kkQQzM=
 =X6mA
 -----END PGP SIGNATURE-----

Merge tag 'arm-dt-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull ARM DT updates from Arnd Bergmann:
 "As usual, the bulk of the changes for the SoC tree are devicetree file
  updates, and most of these changes are for 64-bit embedded machines.
  As before, there are a ton of style cleanups, and additional hardware
  support for existing machines.

  Looking only at the new SoC, the notable additions are:

   - A whole family of Broadcom broadband SoCs, both 32-bit and 64-bit:
     BCM63178, BCM63158, BCM4912, BCM6858, BCM6878, BCM6846, BCM63146,
     BCM6856, BCM6855, BCM6756, BCM63148, and BCM6813. Each SoC comes
     with a corresponding reference board.

   - The new NXP i.MX93 SoC, the follow-up to the popular i.MX6 and
     i.MX8 embedded SoCs, now using Cortex-A55 cores and the Ethos-U65
     NPU.

   - Qualcomm Snapdragon 8cx Gen3 (SC8280XP), the current high end of
     Arm based Laptop SoCs, and its automotive cousin, the SA8540P. The
     SC8280XP is used in the Lenovo Thinkpad X13s laptop that also gets
     added here in addition to the reference boards.

   - Allwinner H616, a newer version of the H6 SoC, targeted at
     Set-top-box applications. It comes with dts files for the Orange Pi
     zero2 single-board computer and the X96 Mate set-top-box

   - Marvell Prestera 98DX2530 (AlleyCat5), a network switch chip in the
     Armada SoC family based on the Cortex-A55 core.

  New machines based on previously supported SoCs include:

   - Several new machines on NXP i.MX platforms: multiple Toradex
     Colibri boards using the "Iris" and "Ixora" carriers, DH
     electronics i.MX8M Plus DHCOM and PDK2, TQ-Systems TQMa8MPQL, and
     phytech phyBOARD-Polis-i.MX8MM.

   - Google Chameleon v3 FPGA board based on Intel Arria10 and Stratix
     10 Software Virtual platform, both in the SoCFPGA platform.

   - Two new wireless devices based on Broadcom SoCs: The Asus GT-AX6000
     Router and the Cisco Meraki MR26 access point

   - Improved Chromebook support for both the Mediatek and Qualcomm SoC
     families brought added machines: Acer Chromebook 514 (MT8192), Acer
     Chromebook Spin 513 (MT8195) and a couple of SC7180 based machines
     including the Lenovo IdeaPad Chromebook Duet 3.

   - Xiaomi Mi Mix2s, LG G7 and LG V35 are mobile phones based on
     Qualcomm SDM845, while Mi 5s Plus is based on MSM8996.

   - Finally, there are a few development board on other chips: PCB8309
     (Microchip lan966x), Radxa Rock Pi S (Rockchips RK3308) DH DRC
     Compact (ST STM32MP1) and Inforce IFC6560 (Qualcomm SDM660)"

* tag 'arm-dt-6.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (829 commits)
  dt-bindings: soc: bcm: use absolute path to other schema
  dt-bindings: soc: bcm: drop quotes when not needed
  dt-bindings: soc: microchip: use absolute path to other schema
  dt-bindings: soc: microchip: drop quotes when not needed
  ARM: dts: lan966x: keep lan966 entries alphabetically sorted
  ARM: dts: lan966x: add support for pcb8309
  dt-bindings: arm: at91: add lan966 pcb8309 board
  ARM: dts: lan966x: Enable network driver on pcb8291
  ARM: dts: lan966x: Disable can0 on pcb8291
  ARM: dts: lan966x: Add gpio-restart
  dt-bindings: arm: aspeed: add Aspeed Evaluation boards
  arm64: dts: qcom: Add support for Xiaomi Mi Mix2s
  dt-bindings: arm: qcom: Add Xiaomi Mi Mix2s bindings
  dt-bindings: arm: qcom: Document lg,judyln and lg,judyp devices
  dt-bindings: arm: qcom: add missing SM6350 board compatibles
  dt-bindings: arm: qcom: add missing SM6125 board compatibles
  dt-bindings: arm: qcom: add missing SDM845 board compatibles
  dt-bindings: arm: qcom: add missing SDM636 board compatibles
  dt-bindings: arm: qcom: add missing SDM630 board compatibles
  dt-bindings: arm: qcom: add missing QCS404 board compatibles
  ...
2022-08-02 08:15:25 -07:00
Krzysztof Kozlowski 517ed0ffd3 arm64: dts: rockchip: align gpio-key node names with dtschema
The node names should be generic and DT schema expects certain pattern
(e.g. with key/button/switch).

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220616005333.18491-26-krzysztof.kozlowski@linaro.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-06-22 20:55:57 +02:00
Brian Norris 2d56af33d4 arm64: dts: rockchip: Assign RK3399 VDU clock rate
Before commit 9998943f6d ("media: rkvdec: Stop overclocking the
decoder"), the rkvdec driver was forcing the VDU clock rate. After that
commit, we rely on the default clock rate. That rate works OK on many
boards, with the default PLL settings (CPLL is 800MHz, VDU dividers
leave it at 400MHz); but some boards change PLL settings.

Assign the expected default clock rate explicitly, so that the rate is
consistent, regardless of PLL configuration.

This was particularly broken on RK3399 Gru Scarlet systems, where the
rk3399-gru-scarlet.dtsi assigns PLL_CPLL to 1.6 GHz, and so the VDU
clock ends up at 800 MHz (twice the expected rate), and causes video
artifacts and other issues.

Note: I assign the clock rate in the clock controller instead of the
vdec node, because there are multiple nodes that use this clock, and per
the clock.yaml specification:

  Configuring a clock's parent and rate through the device node that
  consumes the clock can be done only for clocks that have a single
  user. Specifying conflicting parent or rate configuration in multiple
  consumer nodes for a shared clock is forbidden.

  Configuration of common clocks, which affect multiple consumer devices
  can be similarly specified in the clock provider node.

Fixes: 9998943f6d ("media: rkvdec: Stop overclocking the decoder")
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Link: https://lore.kernel.org/r/20220607141535.1.Idafe043ffc94756a69426ec68872db0645c5d6e2@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2022-06-11 17:17:57 +02:00
Lin Huang 80bc6f34c5 arm64: dts: rockchip: Enable dmc and dfi nodes on gru
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>
2022-04-10 19:10:09 +02:00
Arnaud Ferraris 263b39bce2 arm64: dts: rockchip: add 'chassis-type' property
A new 'chassis-type' root node property has recently been approved for
the device-tree specification, in order to provide a simple way for
userspace to detect the device form factor and adjust their behavior
accordingly.

This patch fills in this property for end-user devices (such as laptops,
smartphones and tablets) based on Rockchip ARM64 processors.

Signed-off-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
Link: https://lore.kernel.org/r/20211016102025.23346-5-arnaud.ferraris@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-10-16 21:26:48 +02:00
Brian Norris ae04430959 arm64: dts: rockchip: add RK3399 Gru gpio-line-names
It's convenient to get nice names for GPIOs. In particular, Chrome OS
tooling looks for "AP_FLASH_WP" and "AP_FLASH_WP_L". The rest are
provided for convenience.

Gru-Bob and Gru-Kevin share the gru-chromebook.dtsi, and for the most
part they share pin meanings. I omitted a few areas where components
were available only on one or the other.

Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210820133829.1.Ica46f428de8c3beb600760dbcd63cf879ec24baf@changeid
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2021-09-15 17:50:43 +02:00
Johan Jonker b82f8e2992 arm64: dts: rockchip: fix regulator-gpio states array
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>
2021-05-14 14:11:53 +02:00
Eddie Cai ef098edc9c arm64: dts: rockchip: add isp and sensors for Scarlet
Enable ISP and camera sensor ov2685 and ov5695 for Scarlet Chromebook

Verified with:
    make ARCH=arm64 dtbs_check

Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://lore.kernel.org/r/20201020193850.1460644-10-helen.koike@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-11-30 17:03:38 +01:00
Johan Jonker 2bc65fef4f arm64: dts: rockchip: rename label and nodename pinctrl subnodes that end with gpio
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>
2020-06-17 10:29:48 +02:00
Heiko Stuebner 87d8ae980e arm64: dts: rockchip: add cr50 tpm to rk3399-gru scarlet and bob
Scarlet and Bob use the Google-developed cr50 chip to do things
like TPM and closed-case-debugging.

Add the nodes describing the cr50 and its spi-connection.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20180822120925.12388-1-heiko@sntech.de
2019-10-10 23:19:30 +02:00
Heiko Stuebner d64420e816 arm64: dts: rockchip: bulk convert gpios to their constant counterparts
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>
2019-04-11 14:38:00 +02:00
Brian Norris 5364a0b4f4 arm64: dts: rockchip: move QCA6174A wakeup pin into its USB node
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>
2019-02-27 08:50:15 +01:00
Heiko Stuebner 505a2fd80b arm64: dts: rockchip: add Gru Scarlet devicetrees
Gru-Scarlet is a tablet device using ChomeOS, dual-dsi display
and Wacom touchscreen with stylus.

There exist two variants in the market using different displays
that are differentiated via their sku-id.
The bootloader on them also determines the correct devicetree to
load via the sku-id.

So add a common scarlet dtsi and two minimal board devicetrees
for the two display variants.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Rob Herring <robh@kernel.org>
2018-11-06 09:50:40 +01:00