Work around hardware race condition when setting DAT and OE in same
transaction. Also clean up license boilerplate and use SPDX.
I was not sure if it was preferred to make it a series or individual
patches. I went with series because "gpio: ts4900: Use SPDX header"
cannot cleanly apply by itself due to copyright year changes in the fix
commit. If this is not preferred, please let me know.
V3:
- Move addition of SPDX identifier to separate commit
- Remove license boilerplate in file
V2:
- Add Fixes tag
Kris Bahnsen (1):
gpio: ts4900: Use SPDX header
Mark Featherston (1):
gpio: ts4900: Do not set DAT and OE together
drivers/gpio/gpio-ts4900.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
--
2.11.0
From: Mark Featherston <[email protected]>
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.
Fixes: 9c6686322d74 ("gpio: add Technologic I2C-FPGA gpio support")
Signed-off-by: Mark Featherston <[email protected]>
Signed-off-by: Kris Bahnsen <[email protected]>
---
drivers/gpio/gpio-ts4900.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-ts4900.c b/drivers/gpio/gpio-ts4900.c
index d885032cf814..d918d2df4de2 100644
--- a/drivers/gpio/gpio-ts4900.c
+++ b/drivers/gpio/gpio-ts4900.c
@@ -1,7 +1,7 @@
/*
* 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 +55,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, ®);
+ 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
On Thu, Mar 10, 2022 at 2:16 AM Kris Bahnsen <[email protected]> wrote:
>
> From: Mark Featherston <[email protected]>
>
> 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.
>
> Fixes: 9c6686322d74 ("gpio: add Technologic I2C-FPGA gpio support")
>
> Signed-off-by: Mark Featherston <[email protected]>
> Signed-off-by: Kris Bahnsen <[email protected]>
> ---
> drivers/gpio/gpio-ts4900.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/gpio-ts4900.c b/drivers/gpio/gpio-ts4900.c
> index d885032cf814..d918d2df4de2 100644
> --- a/drivers/gpio/gpio-ts4900.c
> +++ b/drivers/gpio/gpio-ts4900.c
> @@ -1,7 +1,7 @@
> /*
> * 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 +55,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, ®);
> + 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
>
Applied for fixes, thanks!
Bart
On Thu, Mar 10, 2022 at 2:22 PM Kris Bahnsen <[email protected]> wrote:
>
> From: Mark Featherston <[email protected]>
Same comments as per v2.
--
With Best Regards,
Andy Shevchenko
On Thu, 2022-03-10 at 16:48 +0200, Andy Shevchenko wrote:
> On Thu, Mar 10, 2022 at 2:22 PM Kris Bahnsen <[email protected]> wrote:
> >
> > From: Mark Featherston <[email protected]>
>
> Same comments as per v2.
>
Thanks, I'll get a v4 put together shortly to clean that up.
On Thu, 2022-03-10 at 20:30 +0100, Bartosz Golaszewski wrote:
> On Thu, Mar 10, 2022 at 6:36 PM Kris Bahnsen <[email protected]> wrote:
> >
> > On Thu, 2022-03-10 at 16:48 +0200, Andy Shevchenko wrote:
> > > On Thu, Mar 10, 2022 at 2:22 PM Kris Bahnsen <[email protected]> wrote:
> > > >
> > > > From: Mark Featherston <[email protected]>
> > >
> > > Same comments as per v2.
> > >
> >
> > Thanks, I'll get a v4 put together shortly to clean that up.
>
> Hey Kris,
>
> I already sent it out to Linus, please create a follow-up patch for that.
>
> Bart
Can you please clarify what that entails since Andy had requested changes to the
commit message. Should I just create a new patch on top of the commit already on
master to address the comment changes? How would I address commit message changes,
or is that not my responsibility at this point?
Thanks for all the help on learning this process thus far!
Kris
On Thu, Mar 10, 2022 at 6:36 PM Kris Bahnsen <[email protected]> wrote:
>
> On Thu, 2022-03-10 at 16:48 +0200, Andy Shevchenko wrote:
> > On Thu, Mar 10, 2022 at 2:22 PM Kris Bahnsen <[email protected]> wrote:
> > >
> > > From: Mark Featherston <[email protected]>
> >
> > Same comments as per v2.
> >
>
> Thanks, I'll get a v4 put together shortly to clean that up.
Hey Kris,
I already sent it out to Linus, please create a follow-up patch for that.
Bart
On Thu, Mar 10, 2022 at 9:47 PM Kris Bahnsen <[email protected]> wrote:
> On Thu, 2022-03-10 at 20:30 +0100, Bartosz Golaszewski wrote:
> > On Thu, Mar 10, 2022 at 6:36 PM Kris Bahnsen <[email protected]> wrote:
...
> > Hey Kris,
> >
> > I already sent it out to Linus, please create a follow-up patch for that.
> Can you please clarify what that entails since Andy had requested changes to the
> commit message. Should I just create a new patch on top of the commit already on
> master to address the comment changes?
Address the comments.
> How would I address commit message changes,
> or is that not my responsibility at this point?
It's impossible.
--
With Best Regards,
Andy Shevchenko