Gpio reset handling

[John Williams]

Hi Grant,

On Wed, Sep 16, 2009 at 8:27 AM, Grant Likely <grant.likely at secretlab.ca> wrote:
> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr at monstr.eu> wrote:
>> Hi All,
>>
>> I would like to find out proper way how to handle xilinx reset gpio.
>> We are using gpio for soft reset.
> [...]
>> Ok and here about description of reset port
>> I see two option to write new trigger
>> 1. new reset trigger and add it to gpio-leds node - but this should be in gpio-leds node which make
>> no sense to me
>>
>>        reset {
>>                label = "Heartbeat";
>>                gpios = <&gpio_res 3 1>;
>>                linux,default-trigger = "reset";
>>        }
>
> This looks like an abuse of the LED infrastructure.

I agree - we created this idea as a strawman to motivate what follows :)

>> 2. create own reset node
>>
>> reset {
>>        compatible = "gpio-reset";
>>        reset0 {
>>                label "Soft reset";
>>                gpios = <&gpio_res 1 1>;
>>        }
>>
>>        reset1 {
>>                label "Phy reset";
>>                gpios = <&gpio_res 2 1>;
>>        }
>> }
>>
>> For this node there should be better reset description not just label with different description.
>> I expect that it will be useful soft and hard reset and maybe you can find some others.
>
> It sounds like what you are doing is very board specific.  It is
> probably premature to design a 'generic' binding for something that
> may very well not turn out to be very generic at all.

On the contrary - the MicroBlaze CPU itself has no provision for a
self-initiated soft reset.  Instead, the way it is achieved is by
connecting one bit of a GPIO to the AUX_RESET input of Xilinx's
proc_sys_reset IP (also used in PPC designs as you know).  We are
looking for a sensible, flexible way of binding this structure that we
instantiate in almost all MicroBlaze Linux systems.

BTW - how do you handle soft-reset on Xilinx/PPC designs?

> What I'd do is
> create yourself a node for holding board specific properties (like the
> binding to the gpio reset line) and parse that data from your board
> specific setup code.  I suppose you could also do it from an
> of_platform driver, but like irq controllers, it probably doesn't make
> a lot of sense to.

We are trying to avoid board-specific platform code at all costs - the
ability to fully configure a standard kernel onto arbitrary boards via
a DTB is proving very useful, and as I said above we see this
reset-gpio capability as a generic thing that will be used across many
platforms.  We just want to do it right.

>
> So, something like this perhaps:
>
>    machine {
>        compatible = "<vendor>,<board>-machine";
>        soft-reset-gpio = <&gpio_res 1 1>;
>        phy-reset-gpio = <&gpio_res 2 1>;
>    };
>
> I don't much like the node name "machine", but I can't think of
> anything better at the moment.
>
> Note, this suggestion uses "soft-reset-gpio" and "phy-reset-gpio"
> properties instead of the currently documented "gpios" property.  This
> usage isn't supported by the current gpio support code, but that code
> can be modified, and I think this approach is clearer (as long as the
> expected usage of "<vendor>,<board>-machine" is documented.

Given my justification above, can you spare some of your bountiful
neurons on considering how we might do it generically?  Does flattery
work on you? :)

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663