Message ID | 20170117030611.23827-2-afaerber@suse.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Am 17.01.2017 um 04:06 schrieb Andreas Färber: > + leds { > + compatible = "gpio-leds"; > + > + blue { > + label = "rbox-pro:blue:on"; > + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>; > + default-state = "on"; > + }; > + > + red { > + label = "rbox-pro:red:standby"; > + gpios = <&gpio GPIODV_28 GPIO_ACTIVE_HIGH>; > + default-state = "off"; > + retain-state-suspended; > + panic-indicator; > + }; > + }; The original property names for these two were led and red. If anyone has better label names than the above, please speak up. Ditto for vega-s95. On the odroidc2 it's called alive but uses heartbeat there. The vendor device tree had a third "mcu" GPIO in the sysled node, GPIOAO_6, which leads to immediate power-off. I tried using "gpio-poweroff" to configure this pin, but that driver fails to initialize because some pm callback is already registered - I assume from psci, which apparently succeeds to power-off the system, too. For comparison, the S905 based Vega S95 Telos has no such mcu property. Any thoughts? Also, any ideas how best to switch from blue to red for suspend? Add pinctrl properties above? systemd service doing echo from userspace? I assume in Android the Amlogic sysled driver handles all that logic - didn't find any suspend equivalent to gpio-poweroff. Regards, Andreas
Am 17.01.2017 um 04:06 schrieb Andreas Färber: > diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile > index 0d7bfbf7d922..66bc809a5eae 100644 > --- a/arch/arm64/boot/dts/amlogic/Makefile > +++ b/arch/arm64/boot/dts/amlogic/Makefile > @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb > dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb > dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb > dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1? Should it be renamed to include -s912 for consistency? > +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb Should this new board use meson-gxm-s912-? > > always := $(dtb-y) > subdir-y := $(dts-dirs) Regards, Andreas
Andreas Färber <afaerber@suse.de> writes: > Am 17.01.2017 um 04:06 schrieb Andreas Färber: >> + leds { >> + compatible = "gpio-leds"; >> + >> + blue { >> + label = "rbox-pro:blue:on"; >> + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>; >> + default-state = "on"; >> + }; >> + >> + red { >> + label = "rbox-pro:red:standby"; >> + gpios = <&gpio GPIODV_28 GPIO_ACTIVE_HIGH>; >> + default-state = "off"; >> + retain-state-suspended; >> + panic-indicator; >> + }; >> + }; > > The original property names for these two were led and red. If anyone > has better label names than the above, please speak up. Ditto for > vega-s95. On the odroidc2 it's called alive but uses heartbeat there. > > The vendor device tree had a third "mcu" GPIO in the sysled node, > GPIOAO_6, which leads to immediate power-off. I tried using > "gpio-poweroff" to configure this pin, but that driver fails to > initialize because some pm callback is already registered - I assume > from psci, which apparently succeeds to power-off the system, too. For > comparison, the S905 based Vega S95 Telos has no such mcu property. Any > thoughts? > > Also, any ideas how best to switch from blue to red for suspend? Add > pinctrl properties above? systemd service doing echo from userspace? I > assume in Android the Amlogic sysled driver handles all that logic - > didn't find any suspend equivalent to gpio-poweroff. in leds-gpio, when retain-state-suspended is not set, the LED is automatically set to value 0. I wonder if leds-gpio should grow support to make the suspend value configurable? Or a property like "toggle-state-suspended" ? Kevin
Andreas Färber <afaerber@suse.de> writes: > Am 17.01.2017 um 04:06 schrieb Andreas Färber: >> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile >> index 0d7bfbf7d922..66bc809a5eae 100644 >> --- a/arch/arm64/boot/dts/amlogic/Makefile >> +++ b/arch/arm64/boot/dts/amlogic/Makefile >> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb >> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb >> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb >> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb > > What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1? > Should it be renamed to include -s912 for consistency? Oops, I think it should be renamed for consistency. I believe there's only one chip in the GXM family (S912) so it might be that we could either drop the -s912 from the q20x boards or, add it to the nexbox. I lean towards dropping the -s912 since there's a single chip in GXM. (FWIW, GXL has more than one chip in the family so we added the chip there.) >> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb > > Should this new board use meson-gxm-s912-? No. Unless Neil or you thing otherwise, I think we should send a patch to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;) Kevin
Hi Andreas, Kevin, On 01/18/2017 11:27 PM, Kevin Hilman wrote: > Andreas Färber <afaerber@suse.de> writes: > >> Am 17.01.2017 um 04:06 schrieb Andreas Färber: >>> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile >>> index 0d7bfbf7d922..66bc809a5eae 100644 >>> --- a/arch/arm64/boot/dts/amlogic/Makefile >>> +++ b/arch/arm64/boot/dts/amlogic/Makefile >>> @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb >>> dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb >> >> What is the logic behind meson-gxm-s912-q201 vs. meson-gxm-nexbox-a1? >> Should it be renamed to include -s912 for consistency? It followed the GXL logic... until I posted the nexbox-a1 without ! Since the q20x and p23x boards are the same, it was to enforce the fact that the S912 was on the q200 and q201 boards. > Oops, I think it should be renamed for consistency. > > I believe there's only one chip in the GXM family (S912) so it might be > that we could either drop the -s912 from the q20x boards or, add it to > the nexbox. I believe this aswell AFAIK. > > I lean towards dropping the -s912 since there's a single chip in GXM. > (FWIW, GXL has more than one chip in the family so we added the chip > there.) > >>> +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb >> >> Should this new board use meson-gxm-s912-? > > No. Unless Neil or you thing otherwise, I think we should send a patch > to drop the -s912 from the q20x boards instead. (where "we" == Neil) ;) Ok, will do. > > Kevin Neil
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile index 0d7bfbf7d922..66bc809a5eae 100644 --- a/arch/arm64/boot/dts/amlogic/Makefile +++ b/arch/arm64/boot/dts/amlogic/Makefile @@ -12,6 +12,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxl-nexbox-a95x.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q200.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-s912-q201.dtb dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb +dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb always := $(dtb-y) subdir-y := $(dts-dirs) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts new file mode 100644 index 000000000000..9f04fa4e5aec --- /dev/null +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts @@ -0,0 +1,240 @@ +/* + * Copyright (c) 2016-2017 Andreas Färber + * + * Based on nexbox-a1: + * + * Copyright (c) 2016 BayLibre, SAS. + * Author: Neil Armstrong <narmstrong@baylibre.com> + * + * Copyright (c) 2016 Endless Computers, Inc. + * Author: Carlo Caione <carlo@endlessm.com> + * + * This file is dual-licensed: you can use it either under the terms + * of the GPL or the X11 license, at your option. Note that this dual + * licensing only applies to this file, and not this project as a + * whole. + * + * a) This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of the + * License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Or, alternatively, + * + * b) Permission is hereby granted, free of charge, to any person + * obtaining a copy of this software and associated documentation + * files (the "Software"), to deal in the Software without + * restriction, including without limitation the rights to use, + * copy, modify, merge, publish, distribute, sublicense, and/or + * sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following + * conditions: + * + * The above copyright notice and this permission notice shall be + * included in all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR + * OTHER DEALINGS IN THE SOFTWARE. + */ + +/dts-v1/; + +#include "meson-gxm.dtsi" + +/ { + compatible = "amlogic,s912", "amlogic,meson-gxm"; + model = "R-Box Pro"; + + aliases { + serial0 = &uart_AO; + }; + + chosen { + stdout-path = "serial0:115200n8"; + }; + + memory@0 { + device_type = "memory"; + reg = <0x0 0x0 0x0 0x80000000>; /* 2 GiB or 3 GiB */ + }; + + leds { + compatible = "gpio-leds"; + + blue { + label = "rbox-pro:blue:on"; + gpios = <&gpio_ao GPIOAO_9 GPIO_ACTIVE_HIGH>; + default-state = "on"; + }; + + red { + label = "rbox-pro:red:standby"; + gpios = <&gpio GPIODV_28 GPIO_ACTIVE_HIGH>; + default-state = "off"; + retain-state-suspended; + panic-indicator; + }; + }; + + vddio_boot: regulator-vddio-boot { + compatible = "regulator-fixed"; + regulator-name = "VDDIO_BOOT"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + vddao_3v3: regulator-vddao-3v3 { + compatible = "regulator-fixed"; + regulator-name = "VDDAO_3V3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + vcc_3v3: regulator-vcc-3v3 { + compatible = "regulator-fixed"; + regulator-name = "VCC_3V3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + emmc_pwrseq: emmc-pwrseq { + compatible = "mmc-pwrseq-emmc"; + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>; + }; + + wifi32k: wifi32k { + compatible = "pwm-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */ + }; + + sdio_pwrseq: sdio-pwrseq { + compatible = "mmc-pwrseq-simple"; + reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>; + clocks = <&wifi32k>; + clock-names = "ext_clock"; + }; +}; + +ðmac { + status = "okay"; + + pinctrl-0 = <ð_pins>; + pinctrl-names = "default"; + + /* Select external PHY by default */ + phy-handle = <&external_phy>; + + snps,reset-gpio = <&gpio GPIOZ_14 0>; + snps,reset-delays-us = <0 10000 1000000>; + snps,reset-active-low; + + amlogic,tx-delay-ns = <2>; + + /* External PHY is in RGMII */ + phy-mode = "rgmii"; +}; + +&external_mdio { + external_phy: ethernet-phy@0 { + compatible = "ethernet-phy-id001c.c916", "ethernet-phy-ieee802.3-c22"; + reg = <0>; + max-speed = <1000>; + }; +}; + +&ir { + status = "okay"; + pinctrl-0 = <&remote_input_ao_pins>; + pinctrl-names = "default"; +}; + +&pwm_ef { + status = "okay"; + pinctrl-0 = <&pwm_e_pins>; + pinctrl-names = "default"; + clocks = <&clkc CLKID_FCLK_DIV4>; + clock-names = "clkin0"; +}; + +/* Wireless SDIO Module */ +&sd_emmc_a { + status = "okay"; + pinctrl-0 = <&sdio_pins>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + bus-width = <4>; + cap-sd-highspeed; + max-frequency = <100000000>; + + non-removable; + disable-wp; + + mmc-pwrseq = <&sdio_pwrseq>; + + vmmc-supply = <&vddao_3v3>; + vqmmc-supply = <&vddio_boot>; + + brcmf: brcmf@1 { + reg = <1>; + compatible = "brcm,bcm4329-fmac"; + }; +}; + +/* SD card */ +&sd_emmc_b { + status = "okay"; + pinctrl-0 = <&sdcard_pins>; + pinctrl-names = "default"; + + bus-width = <4>; + cap-sd-highspeed; + max-frequency = <100000000>; + disable-wp; + + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>; + cd-inverted; + + vmmc-supply = <&vddao_3v3>; + vqmmc-supply = <&vddio_boot>; +}; + +/* eMMC */ +&sd_emmc_c { + status = "okay"; + pinctrl-0 = <&emmc_pins>; + pinctrl-names = "default"; + + bus-width = <8>; + cap-sd-highspeed; + cap-mmc-highspeed; + max-frequency = <200000000>; + non-removable; + disable-wp; + mmc-ddr-1_8v; + mmc-hs200-1_8v; + + mmc-pwrseq = <&emmc_pwrseq>; + vmmc-supply = <&vcc_3v3>; + vqmmc-supply = <&vddio_boot>; +}; + +&uart_AO { + status = "okay"; + pinctrl-0 = <&uart_ao_a_pins>; + pinctrl-names = "default"; +};
The R-Box Pro is a TV box derived from Amlogic q200 reference design. It uses an AP6255 Wifi module. It features an LED tube that lights a surrounding stripe and the top logo in blue or red or pink'ish - blue is on by default, and red (i.e., pink) is configured as panic indicator. This device is available in at least two models, with 2 GB vs. 3 GB RAM as well as varying eMMC size. The intent is to handle this with a single .dts that gets the actual RAM size from U-Boot. The vendor prefix remains to be clarified, therefore no dedicated board compatible string yet. Signed-off-by: Andreas Färber <afaerber@suse.de> --- arch/arm64/boot/dts/amlogic/Makefile | 1 + arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts | 240 +++++++++++++++++++++ 2 files changed, 241 insertions(+) create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxm-rbox-pro.dts