FAILED: patch "[PATCH] pinctrl: intel: Avoid potential glitches if pin is in GPIO" failed to apply to 4.19-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 29c2c6aa32405dfee4a29911a51ba133edcedb0f Mon Sep 17 00:00:00 2001
From: Andy Shevchenko <[email protected]>
Date: Mon, 14 Oct 2019 12:51:04 +0300
Subject: [PATCH] pinctrl: intel: Avoid potential glitches if pin is in GPIO
mode
When consumer requests a pin, in order to be on the safest side, we switch it first to GPIO mode followed by immediate transition to the input state. Due to posted writes it's luckily to be a single I/O transaction.
However, if firmware or boot loader already configures the pin to the GPIO mode, user expects no glitches for the requested pin. We may check if the pin is pre-configured and leave it as is till the actual consumer toggles its state to avoid glitches.
Depends-on: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
drivers/pinctrl/intel/pinctrl-intel.c +20 -1
@@ -52,6 +52,7 @@#define PADCFG0_GPIROUTNMI BIT(17)#define PADCFG0_PMODE_SHIFT 10#define PADCFG0_PMODE_MASK GENMASK(13, 10) +#define PADCFG0_PMODE_GPIO 0#define PADCFG0_GPIORXDIS BIT(9)#define PADCFG0_GPIOTXDIS BIT(8)#define PADCFG0_GPIORXSTATE BIT(1)
@@ -332,7 +333,7 @@ static void intel_pin_dbg_show(struct pinctrl_dev *pctldev, struct seq_file *s, cfg1 =readl (intel_get_padcfg (pctrl, pin,PADCFG1 )); mode = (cfg0 &PADCFG0_PMODE_MASK ) >>PADCFG0_PMODE_SHIFT ; -if (!mode) +if (mode ==PADCFG0_PMODE_GPIO )seq_puts (s,"GPIO " );else seq_printf (s,"mode %d " , mode);
@@ -458,6 +459,11 @@ static void __intel_gpio_set_direction(void __iomem *padcfg0, bool input)writel (value, padcfg0); } +static int intel_gpio_get_gpio_mode (void __iomem *padcfg0) +{ +return (readl (padcfg0) &PADCFG0_PMODE_MASK ) >>PADCFG0_PMODE_SHIFT ; +} +static void intel_gpio_set_gpio_mode (void __iomem *padcfg0) {u32 value;
@@ -491,7 +497,20 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev, } padcfg0 =intel_get_padcfg (pctrl, pin,PADCFG0 ); + +/* +* If pin is already configured in GPIO mode, we assume that +* firmware provides correct settings. In such case we avoid +* potential glitches on the pin. Otherwise, for the pin in +* alternative mode, consumer has to supply respective flags. +*/ +if (intel_gpio_get_gpio_mode (padcfg0) ==PADCFG0_PMODE_GPIO ) { +raw_spin_unlock_irqrestore (&pctrl->lock, flags); +return 0 ; + } +intel_gpio_set_gpio_mode (padcfg0); +/* Disable TX buffer and enable RX (this will be input) */ __intel_gpio_set_direction (padcfg0, true);
Sasha Levin
maintainerQuoted 23 lines · On Mon, Nov 11, 2019 at 06:59:53AM +0100, [email protected] wrote:
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
29c2c6aa32405dfee4a29911a51ba133edcedb0fMon Sep 17 00:00:00 2001
From: Andy Shevchenko <[email protected]>
Date: Mon, 14 Oct 2019 12:51:04 +0300
Subject: [PATCH] pinctrl: intel: Avoid potential glitches if pin is in GPIO modeWhen consumer requests a pin, in order to be on the safest side, we switch it first to GPIO mode followed by immediate transition to the input state. Due to posted writes it's luckily to be a single I/O transaction.
Quoted 4 lines
However, if firmware or boot loader already configures the pin to the GPIO mode, user expects no glitches for the requested pin. We may check if the pin is pre-configured and leave it as is till the actual consumer toggles its state to avoid glitches.
I've queued it up for 4.19, it was just a minor conflict with e58926e781d8 ("pinctrl: intel: Use GENMASK() consistently").
However, for 4.14 and older:
Quoted 2 lines
Fixes 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")Depends-on:
f5a26acf0162("pinctrl: intel: Initialize GPIO properly when used through irqchip")
We need to take this "Depends-on" commit, but in the past we have reverted it:
https://lore.kernel.org/lkml/[email protected]/
So I didn't do anything with this patch for <=4.14.
Signature · 2 lines
Thanks, Sasha
Quoted 24 lines · Sasha Levin
Quoted 23 lines · On Mon, Nov 11, 2019 at 06:59:53AM +0100, [email protected] wrote:
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
29c2c6aa32405dfee4a29911a51ba133edcedb0fMon Sep 17 00:00:00 2001
From: Andy Shevchenko <[email protected]>
Date: Mon, 14 Oct 2019 12:51:04 +0300
Subject: [PATCH] pinctrl: intel: Avoid potential glitches if pin is in GPIO modeWhen consumer requests a pin, in order to be on the safest side, we switch it first to GPIO mode followed by immediate transition to the input state. Due to posted writes it's luckily to be a single I/O transaction.
Quoted 7 lines
Quoted 4 lines
However, if firmware or boot loader already configures the pin to the GPIO mode, user expects no glitches for the requested pin. We may check if the pin is pre-configured and leave it as is till the actual consumer toggles its state to avoid glitches.
I've queued it up for 4.19, it was just a minor conflict with
e58926e781d8("pinctrl: intel: UseGENMASK()consistently").
Thank you!
Quoted 9 lines
However, for 4.14 and older:
Quoted 2 lines
Fixes 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")Depends-on:
f5a26acf0162("pinctrl: intel: Initialize GPIO properly when used through irqchip")We need to take this "Depends-on" commit, but in the past we have reverted it:
Yes, as the commit says that we have a lot of dependencies.
Quoted 1 line
So I didn't do anything with this patch for <=4.14.
So far so good, thanks!
P.S. In case we need it in the future, we will prepare a backport patch ourselves.
Signature · 2 lines
With Best Regards, Andy Shevchenko