linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kris Bahnsen <kris@embeddedTS.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Featherston <mark@embeddedts.com>
Subject: Re: [PATCH] gpio: ts4900: Do not set DAT and OE together
Date: Mon, 07 Mar 2022 11:40:26 -0800	[thread overview]
Message-ID: <1646682026.7444.2.camel@embeddedTS.com> (raw)
In-Reply-To: <CAMRc=MeHT4pX1ZRbOz0owDDec5rv+FE84rp464ugffbH5PuS5w@mail.gmail.com>

On Mon, 2022-03-07 at 10:13 +0100, Bartosz Golaszewski wrote:
> On Fri, Mar 4, 2022 at 11:15 PM Kris Bahnsen <kris@embeddedts.com> wrote:
> > 
> > From: Mark Featherston <mark@embeddedTS.com>
> > 
> > This works around an issue with the hardware where both OE and
> > DAT are exposed in the same register. If both are updated
> > simultaneously, the harware makes no guarantees that OE or DAT
> > will actually change in any given order and may result in a
> > glitch of a few ns on a GPIO pin when changing direction and value
> > in a single write.
> > 
> > Setting direction to input now only affects OE bit. Setting
> > direction to output updates DAT first, then OE.
> > 
> > Signed-off-by: Mark Featherston <mark@embeddedTS.com>
> > Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
> > ---
> >  drivers/gpio/gpio-ts4900.c | 25 ++++++++++++++++++++-----
> >  1 file changed, 20 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpio-ts4900.c b/drivers/gpio/gpio-ts4900.c
> > index d885032cf814..fbabfca030c0 100644
> > --- a/drivers/gpio/gpio-ts4900.c
> > +++ b/drivers/gpio/gpio-ts4900.c
> > @@ -1,7 +1,8 @@
> > +// SPDX-License-Identifier: GPL-2.0
> >  /*
> >   * Digital I/O driver for Technologic Systems I2C FPGA Core
> >   *
> > - * Copyright (C) 2015 Technologic Systems
> > + * Copyright (C) 2015-2018 Technologic Systems
> >   * Copyright (C) 2016 Savoir-Faire Linux
> >   *
> >   * This program is free software; you can redistribute it and/or
> > @@ -55,19 +56,33 @@ static int ts4900_gpio_direction_input(struct gpio_chip *chip,
> >  {
> >         struct ts4900_gpio_priv *priv = gpiochip_get_data(chip);
> > 
> > -       /*
> > -        * This will clear the output enable bit, the other bits are
> > -        * dontcare when this is cleared
> > +       /* Only clear the OE bit here, requires a RMW. Prevents potential issue
> > +        * with OE and data getting to the physical pin at different times.
> >          */
> > -       return regmap_write(priv->regmap, offset, 0);
> > +       return regmap_update_bits(priv->regmap, offset, TS4900_GPIO_OE, 0);
> >  }
> > 
> >  static int ts4900_gpio_direction_output(struct gpio_chip *chip,
> >                                         unsigned int offset, int value)
> >  {
> >         struct ts4900_gpio_priv *priv = gpiochip_get_data(chip);
> > +       unsigned int reg;
> >         int ret;
> > 
> > +       /* If changing from an input to an output, we need to first set the
> > +        * proper data bit to what is requested and then set OE bit. This
> > +        * prevents a glitch that can occur on the IO line
> > +        */
> > +       regmap_read(priv->regmap, offset, &reg);
> > +       if (!(reg & TS4900_GPIO_OE)) {
> > +               if (value)
> > +                       reg = TS4900_GPIO_OUT;
> > +               else
> > +                       reg &= ~TS4900_GPIO_OUT;
> > +
> > +               regmap_write(priv->regmap, offset, reg);
> > +       }
> > +
> >         if (value)
> >                 ret = regmap_write(priv->regmap, offset, TS4900_GPIO_OE |
> >                                                          TS4900_GPIO_OUT);
> > --
> > 2.11.0
> > 
> 
> This looks like a fix, can you add a Fixes tag?
> 
> Bart
> 

Please excuse my ignorance (and email client issues) I am still learning the
submission process. I'm not sure what kind of Fixes tag to add in this scenario.

This GPIO issue has existed since the driver's inception. It is a quirk of
hardware that has always existed on this platform. The driver was originally
implemented by Savoir-faire Linux. We discovered the issue and have had it
patched in our trees for years and wanted to push it upstream.

There is no public discussion on it, it was found and patched. And, aside from
the first commit of this driver, there is no commit that introduced any issue.

Can you please advise what kind of Fixes tag is appropriate in this situation?

Additionally, if I do add a Fixes tag, would that warrant a v2 patch? Or would
it just need to be an email response that includes it?

Kris

  reply	other threads:[~2022-03-07 19:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 22:15 [PATCH] gpio: ts4900: Do not set DAT and OE together Kris Bahnsen
2022-03-07  9:13 ` Bartosz Golaszewski
2022-03-07 19:40   ` Kris Bahnsen [this message]
2022-03-08  8:38     ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1646682026.7444.2.camel@embeddedTS.com \
    --to=kris@embeddedts.com \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@embeddedts.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).