[PATCH linux] Add debounce for power button, pull down gpioQ7 to unlock identify LED

Andrew Jeffery andrew at aj.id.au
Fri May 13 12:33:35 AEST 2016


On Thu, 2016-05-12 at 16:40 +0930, Joel Stanley wrote:
> 
> ping
> 
> On Mon, May 2, 2016 at 11:12 AM, Joel Stanley <joel at jms.id.au> wrote:
> > 
> > 
> > On Fri, Apr 29, 2016 at 3:10 PM, OpenBMC Patches
> > <openbmc-patches at stwcx.xyz> wrote:
> > > 
> > > 
> > > From: Ken <ken.sk.lai at mail.foxconn.com>
> > > 
> > We need to include a description of why this change is being made.
> > What does it fix? Why does the previous behaviour need to be
> > modified?

+1

> > > 
> > > ---
> > >  arch/arm/mach-aspeed/aspeed.c | 8 ++++++--
> > >  1 file changed, 6 insertions(+), 2 deletions(-)
> > >  mode change 100644 => 100755 arch/arm/mach-aspeed/aspeed.c
> > > 
> > > diff --git a/arch/arm/mach-aspeed/aspeed.c b/arch/arm/mach-
> > > aspeed/aspeed.c
> > > old mode 100644
> > > new mode 100755
> > > index 594a781..fa5d467
> > > --- a/arch/arm/mach-aspeed/aspeed.c
> > > +++ b/arch/arm/mach-aspeed/aspeed.c
> > > @@ -138,9 +138,10 @@ static void __init do_barreleye_setup(void)
> > >         /* GPIO setup */
> > >         writel(0x9E82FCE7, AST_IO(AST_BASE_GPIO | 0x00));
> > >         writel(0x0370E677, AST_IO(AST_BASE_GPIO | 0x04));
> > > -
> > > +       writel(0x00001080, AST_IO(AST_BASE_GPIO | 0x84));
> > We have a GPIO driver that handles setting this register.

Agreed - superficially it looks like we should be doing this in e.g.
bin/Barreleye.py in the skeleton repo.

So looking there, R4 was previously described:

    GPIO_CONFIG['HEART_BEAT']       = { 'gpio_pin': 'R4', 'direction':
'out' }

But was removed by Adriana in skeleton's "9c75104b Implement new LED
driver" commit. Presumably this should've taken care of the
configuration of R4.

The register write is also configuring GPIOQ7 as output, but I can't
find mention of it in the skeleton history. Given the title of the
pull-req and the configuration of the Habanero and Palmetto it sounds
like this is BMC_IDBTN_IN_OUT_N. Should this also be handled by the
'new LED driver'? It seems like we could avoid configuring it in the
board-file.

> > > 
> > >         /* SCU setup */
> > >         writel(0x01C00000, AST_IO(AST_BASE_SCU | 0x88));
> > > +       writel(0x010FFFFF, AST_IO(AST_BASE_SCU | 0xA8));
> > Can you explain each of these you're setting each of these bits?
> > 
> > > 
> > > 
> > >         /*
> > >          * Do read/modify/write on power gpio to prevent
> > > resetting power on
> > > @@ -150,7 +151,10 @@ static void __init do_barreleye_setup(void)
> > >         reg |= 0xCFC8F7FD;
> > >         writel(reg, AST_IO(AST_BASE_GPIO | 0x20));
> > >         writel(0xC738F20A, AST_IO(AST_BASE_GPIO | 0x24));
> > > -       writel(0x0031FFAF, AST_IO(AST_BASE_GPIO | 0x80));
> > > +       writel(0x0031FF2F, AST_IO(AST_BASE_GPIO | 0x80));

So here we're bringing Q7 low. Can we deal with it as mentioned above?

> 
> > 
> > > 
> > > +       writel(0x00000001, AST_IO(AST_BASE_GPIO | 0x48));
> > > +       writel(0x00000001, AST_IO(AST_BASE_GPIO | 0x4C));
> > > +       writel(0x00075300, AST_IO(AST_BASE_GPIO | 0x58));
> > As above; we have a GPIO driver that handles setting this register.
> > Changing these states needs to be done from userspace. See
> > https://github.com/openbmc/skeleton/blob/master/bin/Barreleye.py#L5
> > 31

Right, so these registers configure debounce. I'm not sure why we
chose timer 3, but regardless, my understanding is that debounce cannot
be configured from userspace via sysfs. This leaves us with doing it
via the pinctrl driver which isn't yet ready (along with some changes
to gpio-aspeed), sticking the hacks here in the board-file, or
spreading the hacks to the gpio-aspeed driver. From those options, this
approach looks to me to be the least bad in at least it keeps the
board-related hacks in one file.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20160513/70e7855f/attachment.sig>


More information about the openbmc mailing list