Gpio reset handling

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";
       }

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.

Quoted 4 lines · Michal Simek

Hi All,

I would like to find out proper way how to handle xilinx reset gpio. We are using gpio for soft reset.

[...]

Quoted 5 lines

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

Quoted 5 lines

       reset {
               label = "Heartbeat";
               gpios = <&gpio_res 3 1>;
               linux,default-trigger = "reset";
       }

This looks like an abuse of the LED infrastructure.

Quoted 15 lines

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>;
       }
}

Quoted 2 lines

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.

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.

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.

Hi Grant,

Quoted 7 lines · Grant Likely

Quoted 2 lines · Michal Simek

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?

Quoted 6 lines

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.

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? :)

From what I've heard so far, I'd do it the same way but use something

Quoted 9 lines · John Williams

Hi Grant,

Quoted 6 lines · Grant Likely

Quoted 2 lines · Michal Simek

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.

Quoted 8 lines

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?

It writes the reset command to the DBCR special purpose register. The PPC440 core reset output is wired to the RESETPPC0 bus input on the proc_sys_reset core (which actually consists of three reset request lines IIRC).

Quoted 11 lines

Quoted 6 lines

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.

okay

Quoted 3 lines

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? :)

:-P

From what I've heard so far, I'd do it the same way but use something like "xlnx,microblaze-gpio-reset" for the compatible value. As long as you document the binding and post it to the devicetree-discuss mailing list for review you should have no problem doing what you want to do.

BTW, start with the "xlnx,microblaze-*" value for now. A architecture neutral value can always be chosen at a later date if this proves to be useful.

g.

Quoted 9 lines · Grant Likely

From what I've heard so far, I'd do it the same way but use something like "xlnx,microblaze-gpio-reset" for the compatible value.  As long as you document the binding and post it to the devicetree-discuss mailing list for review you should have no problem doing what you want to do.

BTW, start with the "xlnx,microblaze-*" value for now.  A architecture neutral value can always be chosen at a later date if this proves to be useful.

Here I see some problems if we want to use one reset gpio pin with leds. It not happen in these days but I expect to use it with heartbeat led.

If I want to use new compatible node, I have to change BSP to support this but I can through out this part of code very soon. And if I want to use that node with leds then this is wrong.

Quoted 10 lines · Michal Simek

Quoted 9 lines · Grant Likely

From what I've heard so far, I'd do it the same way but use something like "xlnx,microblaze-gpio-reset" for the compatible value. As long as you document the binding and post it to the devicetree-discuss mailing list for review you should have no problem doing what you want to do.

BTW, start with the "xlnx,microblaze-*" value for now. A architecture neutral value can always be chosen at a later date if this proves to be useful.

Quoted 6 lines

Here I see some problems if we want to use one reset gpio pin with leds. It not happen in these days but I expect to use it with heartbeat led.

If I want to use new compatible node, I have to change BSP to support this but I can through out this part of code very soon. And if I want to use that node with leds then this is wrong.

I think you misunderstand me. I'm saying create a new node which references a gpio from the gpio node. So it would look something like this (adapting your original example):

               gpio_res: gpio@81400000 {
                       compatible = "xlnx,xps-gpio-1.00.a";
                       interrupt-parent = <&xps_intc_0>;
                       interrupts = < 7 2 >;
                       reg = < 0x81400000 0x10000 >;
...
                       xlnx,gpio-width = <0x8>;
...
               } ;

gpio-leds {
       compatible = "gpio-leds";
       heartbeat {
               label = "Heartbeat";
               gpios = <&gpio_res 4 1>;
               linux,default-trigger = "heartbeat";
       };

       green {
               label = "Green";
               gpios = <&gpio_res 5 1>;
       };
};

reset {
       compatible = "xlnx,microblaze-reset";
       soft-reset-gpio = <&gpio_res 1 1>;
       phy-reset-gpio = <&gpio_res 2 1>;
}

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.

On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <[email protected]> wrote:

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.

Quoted 1 line · Grant Likely

On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <[email protected]> wrote:

[snip]

Quoted 8 lines

So, something like this perhaps:

    machine {
        compatible = "<vendor>,<board>-machine";
        soft-reset-gpio = <&gpio_res 1 1>;
        phy-reset-gpio = <&gpio_res 2 1>;
    };

Quoted 2 lines

I don't much like the node name "machine", but I can't think of anything better at the moment.

Why not put the reset properties in the root node? They do pertain to the whole system, after all.