Gpio reset handling

Gpio reset handling

[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.

I read led.txt in Documentation and currently are used/supported some triggers
but reset is not there.

Led gpio is clear because example is in kernel (xpedite5301.dts for example)

Here is description for mixed reset/heartbeat/led gpio
1. line - soft reset
2. line - phy reset for example or any different one
3. line - heartbeat
4. line - led


Not sure if is first line from 1 or 0 - but doesn't matter right now.



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

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.


Thanks for you help,
Michal



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Gpio reset handling

[Grant Likely]

On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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.

> 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.  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.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Gpio reset handling

[John Williams]

Hi Grant,

On Wed, Sep 16, 2009 at 8:27 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> 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

Re: Gpio reset handling

[Grant Likely]

On Tue, Sep 15, 2009 at 4:40 PM, John Williams
<john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org> wrote:
> Hi Grant,
>
> On Wed, Sep 16, 2009 at 8:27 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>>> 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?

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).

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

> 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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Gpio reset handling

[David Gibson]

On Tue, Sep 15, 2009 at 04:27:04PM -0600, Grant Likely wrote:
> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
[snip]
> 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.

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

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: Gpio reset handling

[Martin Donnelly]

On Wed, 2009-09-16 at 08:40 +1000, John Williams wrote:
> 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.

Making this generic would be useful in many of our systems.  I've just
started working on implementing this capability for some of our
platforms and was looking to avoid using board-specific platform code in
doing so.

Cheers
-- 
»Martin Donnelly »GE Fanuc Embedded Systems, Edinburgh, Scotland
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

Re: Gpio reset handling

[Michal Simek]

Grant Likely wrote:
> On Tue, Sep 15, 2009 at 4:40 PM, John Williams
> <john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org> wrote:
>> Hi Grant,
>>
>> On Wed, Sep 16, 2009 at 8:27 AM, Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org> wrote:
>>> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>>>> 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?
> 
> 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).
> 
>>> 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
> 
>> 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.

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.

My expectation is that if has any port special purpose (like reset) and others
different purpose then I should create correct node (which is xilinx gpio) and then
describe that functionality. Exactly as you do for leds.

That gpio has the same behavior as gpio only with all leds but we use one pin
for reset.

I'll do some more tests with gpio handling in latest kernel and then
we can discuss more.

Thanks for your comments,
Michal


> 
> g.
> 



-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Gpio reset handling

[Michal Simek]

David Gibson wrote:
> On Tue, Sep 15, 2009 at 04:27:04PM -0600, Grant Likely wrote:
>> On Tue, Sep 15, 2009 at 12:32 PM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
> [snip]
>> 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.
> 
> Why not put the reset properties in the root node?  They do pertain to
> the whole system, after all.
> 

I looked at powerpc dts in kernel and I haven't found it. Can you send me
example of it?

Thanks,
Michal






-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian

Re: Gpio reset handling

[Grant Likely]

On Thu, Sep 17, 2009 at 12:46 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
> Grant Likely wrote:
>> 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.

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

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Gpio reset handling

[Michal Simek]

Grant Likely wrote:
> On Thu, Sep 17, 2009 at 12:46 AM, Michal Simek <monstr-pSz03upnqPeHXe+LvDLADg@public.gmane.org> wrote:
>> Grant Likely wrote:
>>> 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.
> 
> 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>;
> }

yep, this make sense to me too.

Thanks,
Michal







-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian