[PATCH] ARM: mvebu: GPIO reset on GlobalScale Mirabox

[Gregory CLEMENT]

On 26/03/2015 00:10, Gregory CLEMENT wrote:
> Hi,
> 
> On 26/03/2015 00:16, Leigh Brown wrote:
>> Hi Andrew,
>>
>> On 2015-03-25 22:36, Andrew Lunn wrote:
>>>> 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 :-(
>>
>> 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.

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


> 
> 
> Thanks,
> 
> Gregory
> 
> 
>>
>> Regards,
>>
>> Leigh.
>>
> 
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com