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

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>

show more ...

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

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>

show more ...

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

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>

show more ...

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 Kozlowsk

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>

show more ...

arm64: dts: rockchip: Assign RK3399 VDU clock rate

Before commit 9998943f6dfc ("media: rkvdec: Stop overclocking the
decoder"), the rkvdec driver was forcing the VDU clock rate. After that
commit, w

arm64: dts: rockchip: Assign RK3399 VDU clock rate

Before commit 9998943f6dfc ("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: 9998943f6dfc ("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>

show more ...

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 H

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>

show more ...

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

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>

show more ...

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

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>

show more ...

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,

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>

show more ...

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 Zh

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>

show more ...

arm64: dts: rockchip: fix regulator-gpio states array

[ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ]

A test with the command below gives this error:

/arch/arm64/boot/dts/rockchip/rk3

arm64: dts: rockchip: fix regulator-gpio states array

[ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

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.yam

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>

show more ...

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 cr5

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

show more ...

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 underlyin

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>

show more ...

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

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>

show more ...

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 diff

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>

show more ...

arm64: dts: rockchip: fix regulator-gpio states array

[ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ]

A test with the command below gives this error:

/arch/arm

arm64: dts: rockchip: fix regulator-gpio states array

[ Upstream commit b82f8e2992534aab0fa762a37376be30df263701 ]

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>
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

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-o

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>

show more ...

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 node

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

show more ...

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, t

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>

show more ...

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 gpi

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>

show more ...

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 t

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>

show more ...