ARM: mvebu: GPIO reset on GlobalScale Mirabox
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Add support for the system reset button on the GlobalScale Mirabox. The reset button is connected via GPIO so add a gpio-keys entry for it in the device tree file. Patch is based on the implementation in armada-370-netgear-rn102.dts but using the GPIO pin specified in the original patch by Ezequiel Garcia from 2013.
Tested with the triggerhappy daemon.
--- arch/arm/boot/dts/armada-370-mirabox.dts | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
arch/arm/boot/dts/armada-370-mirabox.dts +18 -0
@@ -9,6 +9,7 @@ */ /dts-v1/; +#include <dt-bindings/input/input.h> #include <dt-bindings/gpio/gpio.h> #include "armada-370.dtsi"
@@ -78,6 +79,18 @@ }; }; + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&reset_button_pin>; + pinctrl-names = "default"; + + reset-button { + label = "Reset Button"; + linux,code = <KEY_RESTART>; + gpios = <&gpio1 26 GPIO_ACTIVE_LOW>; + }; + }; + mdio { pinctrl-0 = <&mdio_pins>; pinctrl-names = "default";
@@ -168,5 +181,10 @@ marvell,pins = "mpp64", "mpp65"; marvell,function = "gpio"; }; + + reset_button_pin: reset-button-pin { + marvell,pins = "mpp58"; + marvell,function = "gpio"; + }; };
Signature · 1 line
2.1.4
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Hi Leigh,
Quoted 6 lines · Leigh Brown
Add support for the system reset button on the GlobalScale Mirabox. The reset button is connected via GPIO so add a gpio-keys entry for it in the device tree file. Patch is based on the implementation in
armada-370-netgear-rn102.dtsbut using the GPIO pin specified in the original patch by Ezequiel Garcia from 2013.
Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button triggers an hardware reset. My concern is that for some board the dts representation would be wrong.
I am not really against this patch, first because it is possible that the board I got was an exception, but as we don't have any feedback from GlobalScale, it is hard to figure out. Then, I am not sure that exposing this reset button when it was not trigger by software was a problem. I have to test it and also think about it.
I would like to have the opinion of other people about it.
Thanks,
Gregory
Quoted 50 lines
Tested with the triggerhappy daemon.
Signed-off-by Leigh Brown <[email protected]>--- arch/arm/boot/dts/armada-370-mirabox.dts | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)arch/arm/boot/dts/armada-370-mirabox.dts +18
-0@@ -9,6 +9,7 @@ */ /dts-v1/; +#include <dt-bindings/input/input.h> #include <dt-bindings/gpio/gpio.h> #include "armada-370.dtsi"@@ -78,6 +79,18 @@ }; }; + gpio-keys { + compatible = "gpio-keys"; + pinctrl-0 = <&reset_button_pin>; + pinctrl-names = "default"; + + reset-button { + label = "Reset Button"; + linux,code = <KEY_RESTART>; + gpios = <&gpio1 26 GPIO_ACTIVE_LOW>; + }; + }; + mdio { pinctrl-0 = <&mdio_pins>; pinctrl-names = "default";@@ -168,5 +181,10 @@ marvell,pins = "mpp64", "mpp65"; marvell,function = "gpio"; }; + + reset_button_pin: reset-button-pin { + marvell,pins = "mpp58"; + marvell,function = "gpio"; + }; };
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Quoted 4 lines
Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button triggers an hardware reset. My concern is that for some board the dts representation would be wrong.
When looking at WiFi issues, it became clear there are two different wifi designs. I would not be too surprised if this reset button changed at the same time.
Gregory, Leigh, is your wifi on the SDIO bus, or the USB bus?
The mirabox i have has an sdio wifi device. But i cannot easily test the reset button, i blew the 5v power rail, so all USB is dead, and my rootfs was on mmc, which is implemented via USB :-(
Andrew
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Hi Andrew,
Quoted 10 lines · Andrew Lunn
Quoted 5 lines
Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button
triggers an hardware reset. My concern is that for some board the dts representation would be wrong.When looking at WiFi issues, it became clear there are two different wifi designs. I would not be too surprised if this reset button changed at the same time.
Quoted 5 lines
Gregory, Leigh, is your wifi on the SDIO bus, or the USB bus?
The mirabox i have has an sdio wifi device. But i cannot easily test the reset button, i blew the 5v power rail, so all USB is dead, and my rootfs was on mmc, which is implemented via USB :-(
The WiFi on my Mirabox is on the SDIO bus.
[ 29.408420] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld [ 29.408430] mwifiex_sdio mmc0:0001:1: WLAN FW is active [ 29.511297] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0
(14.66.35.p52)
Regards,
Leigh.
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Hi,
Quoted 19 lines · Leigh Brown
Hi Andrew,
Quoted 10 lines · Andrew Lunn
Quoted 5 lines
Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button
triggers an hardware reset. My concern is that for some board the dts representation would be wrong.When looking at WiFi issues, it became clear there are two different wifi designs. I would not be too surprised if this reset button changed at the same time.
Quoted 5 lines
Gregory, Leigh, is your wifi on the SDIO bus, or the USB bus?
The mirabox i have has an sdio wifi device. But i cannot easily test the reset button, i blew the 5v power rail, so all USB is dead, and my rootfs was on mmc, which is implemented via USB :-(
Quoted 7 lines
The WiFi on my Mirabox is on the SDIO bus.
[ 29.408420] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld [ 29.408430] mwifiex_sdio mmc0:0001:1: WLAN FW is active [ 29.511297] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0(14.66.35.p52)
I think it is the same for me. I brought my Mirabox at ELC, but it is in my room and just after ELC I will go to the airport. If I find a plug there, I will boot it and I will confirm you, else we will have to wait until Friday morning CET.
Thanks,
Gregory
Quoted 5 lines
Regards,
Leigh.
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
Quoted 30 lines · Gregory CLEMENT
Hi,
Quoted 19 lines · Leigh Brown
Hi Andrew,
Quoted 10 lines · Andrew Lunn
Quoted 5 lines
Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button
triggers an hardware reset. My concern is that for some board the dts representation would be wrong.When looking at WiFi issues, it became clear there are two different wifi designs. I would not be too surprised if this reset button changed at the same time.
Quoted 5 lines
Gregory, Leigh, is your wifi on the SDIO bus, or the USB bus?
The mirabox i have has an sdio wifi device. But i cannot easily test the reset button, i blew the 5v power rail, so all USB is dead, and my rootfs was on mmc, which is implemented via USB :-(
Quoted 7 lines
The WiFi on my Mirabox is on the SDIO bus.
[ 29.408420] mwifiex_sdio mmc0:0001:1: WLAN FW already running! Skip FW dnld [ 29.408430] mwifiex_sdio mmc0:0001:1: WLAN FW is active [ 29.511297] mwifiex_sdio mmc0:0001:1: driver_version = mwifiex 1.0(14.66.35.p52)
Quoted 4 lines
I think it is the same for me. I brought my Mirabox at ELC, but it is in my room and just after ELC I will go to the airport. If I find a plug there, I will boot it and I will confirm you, else we will have to wait until Friday morning CET.
So I checked and I confirm that the Wifi is on the SDIO bus.
Going back to how representing the reset button. We have several option:
1. Modifying the file armada-370-mirabox.dts as done in this patch.
2. Introduce a armada-370-mirabox.dtsi file and adding two new dts file using this one for each variation of the Mirabox
3. Using the Transaction Device Tree + Overlays framwork and creating a device tree fragment.
I already commented about the 1.
For 2., it seems overkill for me and we need to be able to make difference with the different flavor of the board, which doesn't seem possible now.
The 3. could be a good solution, but there is some pending question as where to store this DT fragment and as for 2., how to recognize the board.
Thanks,
Gregory
Quoted 14 lines
Thanks,
Gregory
Quoted 5 lines
Regards,
Leigh.
Signature · 4 lines
Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 ARM: mvebu: GPIO reset on GlobalScale Mirabox
In reply to Gregory CLEMENTHi Gregory,
Quoted 11 lines · Gregory CLEMENT
Quoted 5 lines · Leigh Brown
Add support for the system reset button on the GlobalScale Mirabox. The reset button is connected via GPIO so add a gpio-keys entry for it in the device tree file. Patch is based on the implementation in
armada-370-netgear-rn102.dtsbut using the GPIO pin specified in the original patch by Ezequiel Garcia from 2013.Thanks for your contribution, however the reset button is not always connected to this GPIO. At least on the Mirabox I have the reset button triggers an hardware reset. My concern is that for some board the dts representation would be wrong.
I wish I had your Mirabox, because having the reset button on a GPIO is almost useless :-(
However, I have what I have so it would be nice to find a way to support it.
Regards,
Leigh.