| Message ID | 20210110035846.9155-1-wens@kernel.org |
|---|---|
| Headers | show |
| Series | arm64: rockchip: rk3328: Add Radxa ROCK Pi E | expand |
On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner <heiko@sntech.de> wrote: > > Hi, > > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai: > > > > + vcc_sd: sdmmc-regulator { > > > > + compatible = "regulator-fixed"; > > > > + gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>; > > > > + pinctrl-names = "default"; > > > > + pinctrl-0 = <&sdmmc0m1_pin>; > > > > > > > + regulator-boot-on; > > > > + regulator-name = "vcc_sd"; > > > > > > regulator-name above other regulator properties > > > > That is actually what I was used to, but some other rockchip dts files > > have all the properties sorted alphabetically. So I stuck with what I > > saw. > > I try to keep it alphabetical except for the exceptions :-D . > > regulator-name is such an exception. Similar to compatibles, the > regulator-name is an entry needed to see if you're at the right node, > so I really like it being the topmost regulator-foo property - just makes > reading easier. > > (same for the compatible first, then regs, interrupts parts, as well > as "status-last") > > But oftentimes, I just fix the ordering when applying - but seem to have > missed this somewhere in those "other Rockchip dts files" ;-) . I was slightly confused. I looked again and yes regulator-name is always the first regulator related property. What's off is that in some cases min/max voltage comes before always-on/boot-on, and in others vice versa. For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed regulators, always-on/boot-on come before min/max voltage, while in the PMIC the other order is used. ChenYu
Am Montag, 11. Januar 2021, 04:27:47 CET schrieb Chen-Yu Tsai: > On Mon, Jan 11, 2021 at 4:06 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > Hi, > > > > Am Sonntag, 10. Januar 2021, 16:37:15 CET schrieb Chen-Yu Tsai: > > > > > + vcc_sd: sdmmc-regulator { > > > > > + compatible = "regulator-fixed"; > > > > > + gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>; > > > > > + pinctrl-names = "default"; > > > > > + pinctrl-0 = <&sdmmc0m1_pin>; > > > > > > > > > + regulator-boot-on; > > > > > + regulator-name = "vcc_sd"; > > > > > > > > regulator-name above other regulator properties > > > > > > That is actually what I was used to, but some other rockchip dts files > > > have all the properties sorted alphabetically. So I stuck with what I > > > saw. > > > > I try to keep it alphabetical except for the exceptions :-D . > > > > regulator-name is such an exception. Similar to compatibles, the > > regulator-name is an entry needed to see if you're at the right node, > > so I really like it being the topmost regulator-foo property - just makes > > reading easier. > > > > (same for the compatible first, then regs, interrupts parts, as well > > as "status-last") > > > > But oftentimes, I just fix the ordering when applying - but seem to have > > missed this somewhere in those "other Rockchip dts files" ;-) . > > I was slightly confused. I looked again and yes regulator-name is always the > first regulator related property. What's off is that in some cases min/max > voltage comes before always-on/boot-on, and in others vice versa. > > For example in the Rock64 and ROC-RK3328-CC device trees, in the fixed > regulators, always-on/boot-on come before min/max voltage, while in the > PMIC the other order is used. That's likely undecidednes on my part ;-) There could be an argument for a "name, voltages, flags" sorting, but on the other hand just keeping it alphabetical with the naming on top creates less special cases. Heiko
From: Chen-Yu Tsai <wens@csie.org> Hi everyone, This series adds support for the Radxa ROCK Pi E. This is a router oriented SBC based on Rockchip's RK3328 SoC. As the official wiki page puts it, "E for Ethernets". It features the RK3328 SoC, gigabit and fast Ethernet RJ45 ports, both directly served by Ethernet controllers in the SoC, a USB 3.0 host port, a power-only USB type-C port, a 3.5mm headphone jack for audio output, two LEDs, a 40-pin Raspberry Pi style GPIO header, and optional WiFi+BT and PoE header. The board comes in multiple configurations, differing in the amount of onboard RAM, the level of WiFi+BT (none, 802.11n 2.4GHz, or 802.11ac 2.4 GHz & 5 GHz), and whether PoE is supported or not. These variants can all share the same device tree. Currently, the 802.11ac chip lacks an in-kernel driver. The USB 2.0 OTG controller is available on the 40-pin header. This is not enabled in the device tree, since it is possible to use it in a host-only configuration, or in OTG mode with an extra pin from the header as the ID pin. The device tree is based on the one of the Rock64, with various parts modified to match the ROCK Pi E, and some parts updated to newer styles, such as the gmac2io node's mdio sub-node. Patch 1 adds the clock_in_out property to the gmac2phy node. This would always have the same setting for gmac2phy, which uses an integrated PHY in RMII mode. Having this set by default makes enabling gmac2phy at the board level simpler. Patch 2 adds a compatible string for this board to the list of Rockchip based devices. Patch 3 adds a device tree file for this board. This is based on the one for the Rock64, with many modifications to adapt it to the new board, as well as style updates. Please have a look. Regards ChenYu Chen-Yu Tsai (3): arm64: dts: rockchip: rk3328: Add clock_in_out property to gmac2phy node dt-bindings: arm: rockchip: Add Radxa ROCK Pi E arm64: dts: rockchip: rk3328: Add Radxa ROCK Pi E .../devicetree/bindings/arm/rockchip.yaml | 5 + arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts | 369 ++++++++++++++++++ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 + 4 files changed, 376 insertions(+) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts