arm64: dts: rockchip: fix adc-keys sub node names

Fix adc-keys sub node names on Rockchip boards,
so that they match with regex: '^button-'

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: htt

arm64: dts: rockchip: fix adc-keys sub node names

Fix adc-keys sub node names on Rockchip boards,
so that they match with regex: '^button-'

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/6a6a3603-5540-cacc-2672-c015af1ec684@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Move ep-gpios property to nanopc-t4 from nanopi4

Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion

arm64: dts: rockchip: Move ep-gpios property to nanopc-t4 from nanopi4

Only the NanoPC T4 hs the PCIe reset pin routed to the SoC. For the
NanoPi M4 family, no such signal is routed to the expansion header on
the base board.

As the schematics for the expansion board were not released, it is
unclear how this is handled, but the likely answer is that the signal
is always pulled high.

Move the ep-gpios property from the common nanopi4.dtsi file to the
board level nanopc-t4.dts file. This makes the nanopi-m4 lack ep-gpios,
matching the board design.

A companion patch "PCI: rockchip: make ep_gpio optional" for the Linux
driver is required, as the driver currently requires the property to be
present.

Fixes: e7a095908227 ("arm64: dts: rockchip: Add devicetree for NanoPC-T4")
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20210121162321.4538-4-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Improve nanopi4 PCIe

Expand the power tree description with the 0V9 and 1V8 supplies to the
RK3399 PCIe block. The NanoPis M4 and NEO4 just route 2 lanes to the
user expansion

arm64: dts: rockchip: Improve nanopi4 PCIe

Expand the power tree description with the 0V9 and 1V8 supplies to the
RK3399 PCIe block. The NanoPis M4 and NEO4 just route 2 lanes to the
user expansion pins, so there's not much more to say at the board level
for them; NanoPC-T4 has a standard M.2 connector so we can at least
claim the 3.3V supply to that too.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/a04a17f4b9b12e8698c76b34e7ca22f0c81845ce.1573908195.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Fix NanoPC-T4 cooling maps

Although it appeared to follow logically from the bindings, apparently
the thermal framework can't properly cope with a single cooling device
being s

arm64: dts: rockchip: Fix NanoPC-T4 cooling maps

Although it appeared to follow logically from the bindings, apparently
the thermal framework can't properly cope with a single cooling device
being shared between multiple maps. The CPU zone is probably easier to
overheat, so remove the references to the (optional) fan from the GPU
cooling zone to avoid things getting confused. Hopefully GPU-intensive
tasks will leak enough heat across to the CPU zone to still hit the
fan trips before reaching critical GPU temperatures.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5bb39f3115df1a487d717d3ae87e523b03749379.1573908197.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <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: Add PWM fan for NanoPC-T4

NanoPC-T4 has a dedicated circuit for driving a 12V fan from PWM1,
so let's add that along with some rough empirically-derived thermal
settings for th

arm64: dts: rockchip: Add PWM fan for NanoPC-T4

NanoPC-T4 has a dedicated circuit for driving a 12V fan from PWM1,
so let's add that along with some rough empirically-derived thermal
settings for the benefit of anyone determined enough to hook one up.

The vendor does not currently offer a suitable fan, but this seems as
good a place as any to note that pre-terminated 3-pin JST GH connectors
are readily available online, and if you even have to ask, then splicing
one of those really will be orders of magnitude cheaper and simpler than
getting set up to crimp the teeny-tiny things by hand.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Add NanoPC-T4 IR receiver

In common with most Rockchip reference designs, NanoPC-T4 has a passive
IR receiver connected to PWM3. In lieu of a specialised driver for
PWM-based I

arm64: dts: rockchip: Add NanoPC-T4 IR receiver

In common with most Rockchip reference designs, NanoPC-T4 has a passive
IR receiver connected to PWM3. In lieu of a specialised driver for
PWM-based IR pulse measurement, running the pin as a GPIO with the basic
driver works perfectly well.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Refine nanopi4 differences

The nanopi4 boards differ primarily in their power trees, with the main
5V and 3.3V rails having very different topologies on the smaller USB-C
power

arm64: dts: rockchip: Refine nanopi4 differences

The nanopi4 boards differ primarily in their power trees, with the main
5V and 3.3V rails having very different topologies on the smaller USB-C
powered boards vs. the 12V-powered T4, as well as minor variation in
other regulators related to various external connectors.

Additionally, the recovery key is only present on the T4 - ADC_IN1 is
simply pulled high and not exposed on the other boards - and the lowest
common denominator for MMC speed is actually HS200 according to the
vendor DTs.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Add devicetree for NanoPC-T4

This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
-

arm64: dts: rockchip: Add devicetree for NanoPC-T4

This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least
two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
[rm: various further cleanup]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Improve nanopi4 PCIe

Expand the power tree description with the 0V9 and 1V8 supplies to the
RK3399 PCIe block. The NanoPis M4 and NEO4 just route 2 lanes to the

arm64: dts: rockchip: Improve nanopi4 PCIe

Expand the power tree description with the 0V9 and 1V8 supplies to the
RK3399 PCIe block. The NanoPis M4 and NEO4 just route 2 lanes to the
user expansion pins, so there's not much more to say at the board level
for them; NanoPC-T4 has a standard M.2 connector so we can at least
claim the 3.3V supply to that too.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/a04a17f4b9b12e8698c76b34e7ca22f0c81845ce.1573908195.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Fix NanoPC-T4 cooling maps

Although it appeared to follow logically from the bindings, apparently
the thermal framework can't properly cope with a single cooling de

arm64: dts: rockchip: Fix NanoPC-T4 cooling maps

Although it appeared to follow logically from the bindings, apparently
the thermal framework can't properly cope with a single cooling device
being shared between multiple maps. The CPU zone is probably easier to
overheat, so remove the references to the (optional) fan from the GPU
cooling zone to avoid things getting confused. Hopefully GPU-intensive
tasks will leak enough heat across to the CPU zone to still hit the
fan trips before reaching critical GPU temperatures.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/5bb39f3115df1a487d717d3ae87e523b03749379.1573908197.git.robin.murphy@arm.com
Signed-off-by: Heiko Stuebner <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: Add PWM fan for NanoPC-T4

NanoPC-T4 has a dedicated circuit for driving a 12V fan from PWM1,
so let's add that along with some rough empirically-derived thermal

arm64: dts: rockchip: Add PWM fan for NanoPC-T4

NanoPC-T4 has a dedicated circuit for driving a 12V fan from PWM1,
so let's add that along with some rough empirically-derived thermal
settings for the benefit of anyone determined enough to hook one up.

The vendor does not currently offer a suitable fan, but this seems as
good a place as any to note that pre-terminated 3-pin JST GH connectors
are readily available online, and if you even have to ask, then splicing
one of those really will be orders of magnitude cheaper and simpler than
getting set up to crimp the teeny-tiny things by hand.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Add NanoPC-T4 IR receiver

In common with most Rockchip reference designs, NanoPC-T4 has a passive
IR receiver connected to PWM3. In lieu of a specialised driver for

arm64: dts: rockchip: Add NanoPC-T4 IR receiver

In common with most Rockchip reference designs, NanoPC-T4 has a passive
IR receiver connected to PWM3. In lieu of a specialised driver for
PWM-based IR pulse measurement, running the pin as a GPIO with the basic
driver works perfectly well.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Refine nanopi4 differences

The nanopi4 boards differ primarily in their power trees, with the main
5V and 3.3V rails having very different topologies on the smaller

arm64: dts: rockchip: Refine nanopi4 differences

The nanopi4 boards differ primarily in their power trees, with the main
5V and 3.3V rails having very different topologies on the smaller USB-C
powered boards vs. the 12V-powered T4, as well as minor variation in
other regulators related to various external connectors.

Additionally, the recovery key is only present on the T4 - ADC_IN1 is
simply pulled high and not exposed on the other boards - and the lowest
common denominator for MMC speed is actually HS200 according to the
vendor DTs.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

arm64: dts: rockchip: Add devicetree for NanoPC-T4

This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known w

arm64: dts: rockchip: Add devicetree for NanoPC-T4

This adds a device tree for the NanoPC-T4 SBC, which is based on the
Rockchip RK3399 SoC and marketed by FriendlyELEC.

Known working:

- Serial
- Ethernet
- HDMI
- USB 2.0

All of the interesting stuff is in a .dtsi because there are at least
two other boards that share most of it: NanoPi M4 and NanoPi NEO4.

Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
[rm: various further cleanup]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...