linux-stable.git/drivers/pinctrl/intel, branch linux-4.9.y

pinctrl: baytrail: Avoid clearing debounce value when turning it off

2020-12-29T12:44:50+00:00

[ Upstream commit 0b74e40a4e41f3cbad76dff4c50850d47b525b26 ]

Baytrail pin control has a common register to set up debounce timeout.
When a pin configuration requested debounce to be disabled, the rest
of the pins may still want to have debounce enabled and thus rely on
the common timeout value. Avoid clearing debounce value when turning
it off for one pin while others may still use it.

Fixes: 658b476c742f ("pinctrl: baytrail: Add debounce configuration")
Depends-on: 04ff5a095d66 ("pinctrl: baytrail: Rectify debounce support")
Depends-on: 827e1579e1d5 ("pinctrl: baytrail: Rectify debounce support (part 2)")
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Sasha Levin

pinctrl: merrifield: Set default bias in case no particular value given

2020-12-29T12:44:50+00:00

[ Upstream commit 0fa86fc2e28227f1e64f13867e73cf864c6d25ad ]

When GPIO library asks pin control to set the bias, it doesn't pass
any value of it and argument is considered boolean (and this is true
for ACPI GpioIo() / GpioInt() resources, by the way). Thus, individual
drivers must behave well, when they got the resistance value of 1 Ohm,
i.e. transforming it to sane default.

In case of Intel Merrifield pin control hardware the 20 kOhm sounds plausible
because it gives a good trade off between weakness and minimization of leakage
current (will be only 50 uA with the above choice).

Fixes: 4e80c8f50574 ("pinctrl: intel: Add Intel Merrifield pin controller support")
Depends-on: 2956b5d94a76 ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Sasha Levin

pinctrl: baytrail: Fix pin being driven low for a while on gpiod_get(..., GPIOD_OUT_HIGH)

2020-12-11T12:37:58+00:00

commit 156abe2961601d60a8c2a60c6dc8dd6ce7adcdaf upstream

The pins on the Bay Trail SoC have separate input-buffer and output-buffer
enable bits and a read of the level bit of the value register will always
return the value from the input-buffer.

The BIOS of a device may configure a pin in output-only mode, only enabling
the output buffer, and write 1 to the level bit to drive the pin high.
This 1 written to the level bit will be stored inside the data-latch of the
output buffer.

But a subsequent read of the value register will return 0 for the level bit
because the input-buffer is disabled. This causes a read-modify-write as
done by byt_gpio_set_direction() to write 0 to the level bit, driving the
pin low!

Before this commit byt_gpio_direction_output() relied on
pinctrl_gpio_direction_output() to set the direction, followed by a call
to byt_gpio_set() to apply the selected value. This causes the pin to
go low between the pinctrl_gpio_direction_output() and byt_gpio_set()
calls.

Change byt_gpio_direction_output() to directly make the register
modifications itself instead. Replacing the 2 subsequent writes to the
value register with a single write.

Note that the pinctrl code does not keep track internally of the direction,
so not going through pinctrl_gpio_direction_output() is not an issue.

This issue was noticed on a Trekstor SurfTab Twin 10.1. When the panel is
already on at boot (no external monitor connected), then the i915 driver
does a gpiod_get(..., GPIOD_OUT_HIGH) for the panel-enable GPIO. The
temporarily going low of that GPIO was causing the panel to reset itself
after which it would not show an image until it was turned off and back on
again (until a full modeset was done on it). This commit fixes this.

This commit also updates the byt_gpio_direction_input() to use direct
register accesses instead of going through pinctrl_gpio_direction_input(),
to keep it consistent with byt_gpio_direction_output().

Note for backporting, this commit depends on:
commit e2b74419e5cc ("pinctrl: baytrail: Replace WARN with dev_info_once
when setting direct-irq pin to output")

Cc: stable@vger.kernel.org
Fixes: 86e3ef812fe3 ("pinctrl: baytrail: Update gpio chip operations")
Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
[sudip: use byt_gpio and vg->pdev->dev for dev_info()]
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Sasha Levin

pinctrl: baytrail: Replace WARN with dev_info_once when setting direct-irq pin to output

2020-12-11T12:37:58+00:00

commit e2b74419e5cc7cfc58f3e785849f73f8fa0af5b3 upstream

Suspending Goodix touchscreens requires changing the interrupt pin to
output before sending them a power-down command. Followed by wiggling
the interrupt pin to wake the device up, after which it is put back
in input mode.

On Cherry Trail device the interrupt pin is listed as a GpioInt ACPI
resource so we can do this without problems as long as we release the
IRQ before changing the pin to output mode.

On Bay Trail devices with a Goodix touchscreen direct-irq mode is used
in combination with listing the pin as a normal GpioIo resource. This
works fine, but this triggers the WARN in byt_gpio_set_direction-s output
path because direct-irq support is enabled on the pin.

This commit replaces the WARN call with a dev_info_once call, fixing a
bunch of WARN splats in dmesg on each suspend/resume cycle.

Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Sasha Levin

pinctrl: cherryview: Add missing spinlock usage in chv_gpio_irq_handler

2020-05-20T06:15:35+00:00

[ Upstream commit 69388e15f5078c961b9e5319e22baea4c57deff1 ]

According to Braswell NDA Specification Update (#557593),
concurrent read accesses may result in returning 0xffffffff and write
instructions may be dropped. We have an established format for the
commit references, i.e.
cdca06e4e859 ("pinctrl: baytrail: Add missing spinlock usage in
byt_gpio_irq_handler")

Fixes: 0bd50d719b00 ("pinctrl: cherryview: prevent concurrent access to GPIO controllers")
Signed-off-by: Grace Kao 
Reported-by: Brian Norris 
Reviewed-by: Brian Norris 
Acked-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin

pinctrl: baytrail: Do not clear IRQ flags on direct-irq enabled pins

2020-02-28T14:42:19+00:00

[ Upstream commit a23680594da7a9e2696dbcf4f023e9273e2fa40b ]

Suspending Goodix touchscreens requires changing the interrupt pin to
output before sending them a power-down command. Followed by wiggling
the interrupt pin to wake the device up, after which it is put back
in input mode.

On Bay Trail devices with a Goodix touchscreen direct-irq mode is used
in combination with listing the pin as a normal GpioIo resource.

This works fine, until the goodix driver gets rmmod-ed and then insmod-ed
again. In this case byt_gpio_disable_free() calls
byt_gpio_clear_triggering() which clears the IRQ flags and after that the
(direct) IRQ no longer triggers.

This commit fixes this by adding a check for the BYT_DIRECT_IRQ_EN flag
to byt_gpio_clear_triggering().

Note that byt_gpio_clear_triggering() only gets called from
byt_gpio_disable_free() for direct-irq enabled pins, as these are excluded
from the irq_valid mask by byt_init_irq_valid_mask().

Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Reviewed-by: Linus Walleij 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin

pinctrl: baytrail: Really serialize all register accesses

2020-01-04T12:41:09+00:00

[ Upstream commit 40ecab551232972a39cdd8b6f17ede54a3fdb296 ]

Commit 39ce8150a079 ("pinctrl: baytrail: Serialize all register access")
added a spinlock around all register accesses because:

"There is a hardware issue in Intel Baytrail where concurrent GPIO register
 access might result reads of 0xffffffff and writes might get dropped
 completely."

Testing has shown that this does not catch all cases, there are still
2 problems remaining

1) The original fix uses a spinlock per byt_gpio device / struct,
additional testing has shown that this is not sufficient concurent
accesses to 2 different GPIO banks also suffer from the same problem.

This commit fixes this by moving to a single global lock.

2) The original fix did not add a lock around the register accesses in
the suspend/resume handling.

Since pinctrl-baytrail.c is using normal suspend/resume handlers,
interrupts are still enabled during suspend/resume handling. Nothing
should be using the GPIOs when they are being taken down, _but_ the
GPIOs themselves may still cause interrupts, which are likely to
use (read) the triggering GPIO. So we need to protect against
concurrent GPIO register accesses in the suspend/resume handlers too.

This commit fixes this by adding the missing spin_lock / unlock calls.

The 2 fixes together fix the Acer Switch 10 SW5-012 getting completely
confused after a suspend resume. The DSDT for this device has a bug
in its _LID method which reprograms the home and power button trigger-
flags requesting both high and low _level_ interrupts so the IRQs for
these 2 GPIOs continuously fire. This combined with the saving of
registers during suspend, triggers concurrent GPIO register accesses
resulting in saving 0xffffffff as pconf0 value during suspend and then
when restoring this on resume the pinmux settings get all messed up,
resulting in various I2C busses being stuck, the wifi no longer working
and often the tablet simply not coming out of suspend at all.

Cc: stable@vger.kernel.org
Fixes: 39ce8150a079 ("pinctrl: baytrail: Serialize all register access")
Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Signed-off-by: Andy Shevchenko 
Signed-off-by: Sasha Levin

pinctrl: intel: Read back TX buffer state

2018-08-06T14:23:02+00:00

commit d68b42e30bbacd24354d644f430d088435b15e83 upstream.

In the same way as it's done in pinctrl-cherryview.c we would provide
a readback TX buffer state.

Fixes: 17fab473693 ("pinctrl: intel: Set pin direction properly")
Reported-by: "Bourque, Francis" 
Signed-off-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Tested-by: "Bourque, Francis" 
Signed-off-by: Linus Walleij 
Cc: Anthony de Boer 
Signed-off-by: Greg Kroah-Hartman

Revert "pinctrl: intel: Initialize GPIO properly when used through irqchip"

2018-04-29T09:31:58+00:00

This reverts commit f5a26acf0162477af6ee4c11b4fb9cffe5d3e257

Mike writes:
	It seems that commit f5a26acf0162 ("pinctrl: intel: Initialize GPIO
	properly when used through irqchip") can cause problems on some Skylake
	systems with Sunrisepoint PCH-H. Namely on certain systems it may turn
	the backlight PWM pin from native mode to GPIO which makes the screen
	blank during boot.

	There is more information here:

	  https://bugzilla.redhat.com/show_bug.cgi?id=1543769

	The actual reason is that GPIO numbering used in BIOS is using "Windows"
	numbers meaning that they don't match the hardware 1:1 and because of
	this a wrong pin (backlight PWM) is picked and switched to GPIO mode.

	There is a proper fix for this but since it has quite many dependencies
	on commits that cannot be considered stable material, I suggest we
	revert commit f5a26acf0162 from stable trees 4.9, 4.14 and 4.15 to
	prevent the backlight issue.

Reported-by: Mika Westerberg 
Fixes: f5a26acf0162 ("pinctrl: intel: Initialize GPIO properly when used through irqchip")
Cc: Daniel Drake 
Cc: Chris Chiu 
Cc: Linus Walleij 
Signed-off-by: Greg Kroah-Hartman

pinctrl: baytrail: Enable glitch filter for GPIOs used as interrupts

2018-04-13T17:48:11+00:00

[ Upstream commit 9291c65b01d1c67ebd56644cb19317ad665c44b3 ]

On some systems, some PCB traces attached to GpioInts are routed in such
a way that they pick up enough interference to constantly (many times per
second) trigger.

Enabling glitch-filtering fixes this.

Signed-off-by: Hans de Goede 
Acked-by: Mika Westerberg 
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman