Gpio reset handling

[Michal Simek]

Grant Likely wrote:
> On Tue, Sep 15, 2009 at 4:40 PM, John Williams
> <john.williams at petalogix.com> wrote:
>> 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:
>>>> 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