Age | Commit message (Collapse) | Author | Files | Lines |
|
Rather than always using handle_simple_irq() as the gpio_irq_chip
handler, set a more appropriate handler based on the IRQ trigger type
requested. This is important for level triggered interrupts which need
to be masked during handling. Also, fix the interrupt acknowledge so
that it clears only one interrupt instead of all interrupts which are
currently active. Finally there is no need to clear the interrupt during
the interrupt handler, since the edge-triggered handler will do that for
us.
Signed-off-by: Mark Tomlinson <[email protected]>
Reviewed-by: Ray Jui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
This change drops the override in `amd_gpio_irq_set_type()` that
ignores the IRQ trigger type settings from the caller. The device
driver (caller) is in a better position to identify the right trigger
type for the device based on the usage as well as the information
exposed by the BIOS. There are instances where the device driver might
want to configure the trigger type differently in different modes. An
example of this is gpio-keys driver which configures IRQ type as
trigger on both edges (to identify assert and deassert events) when in
S0 and reconfigures the trigger type using the information provided by
the BIOS when going into suspend to ensure that the wake happens on
the required edge.
This override in `amd_gpio_irq_set_type()` prevents the caller from
being able to reconfigure trigger type once it is set either based on
ACPI information or the type used by the first caller for IRQ on a
given GPIO line.
Without this change, pen-insert gpio key (used by garaged stylus on a
Chromebook) works fine in S0 (i.e. insert and eject events are
correctly identified), however, BIOS configuration for wake on only
pen eject i.e. only-rising edge or only-falling edge is not honored.
With this change, it was verified that pen-insert gpio key behavior is
correct in both S0 and for wakeup from S3.
Signed-off-by: Furquan Shaikh <[email protected]>
Signed-off-by: Shyam Sundar S K<[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
The PAT1 register contains information about the IRQ type (edge/level)
for input GPIOs with IRQ enabled, and the direction for non-IRQ GPIOs.
So it makes sense to read it only if the GPIO has no interrupt
configured, otherwise input GPIOs configured for level IRQs are
misdetected as output GPIOs.
Fixes: ebd6651418b6 ("pinctrl: ingenic: Implement .get_direction for GPIO chips")
Reported-by: João Henrique <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Ingenic SoCs don't natively support registering an interrupt for both
rising and falling edges. This has to be emulated in software.
Until now, this was emulated by switching back and forth between
IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING according to the level of
the GPIO. While this worked most of the time, when used with GPIOs that
need debouncing, some events would be lost. For instance, between the
time a falling-edge interrupt happens and the interrupt handler
configures the hardware for rising-edge, the level of the pin may have
already risen, and the rising-edge event is lost.
To address that issue, instead of switching back and forth between
IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING, we now switch back and
forth between IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_LEVEL_HIGH. Since we
always switch in the interrupt handler, they actually permit to detect
level changes. In the example above, if the pin level rises before
switching the IRQ type from IRQ_TYPE_LEVEL_LOW to IRQ_TYPE_LEVEL_HIGH,
a new interrupt will raise as soon as the handler exits, and the
rising-edge event will be properly detected.
Fixes: e72394e2ea19 ("pinctrl: ingenic: Merge GPIO functionality")
Reported-by: João Henrique <[email protected]>
Signed-off-by: Paul Cercueil <[email protected]>
Tested-by: João Henrique <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
In the process, some compatible strings now require a fallback, as the
corresponding SoCs are pin-compatible with their fallback variant.
Signed-off-by: Paul Cercueil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Signed-off-by: Konrad Dybcio <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Add support for pm660(l) SPMI GPIOs. The PMICs feature
13 and 12 GPIOs respectively, though with a lot of
holes inbetween.
Signed-off-by: Konrad Dybcio <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
This add support for Sparx5 pinctrl, using the ocelot drives as
basis. It adds pinconfig support as well, as supported by the
platform.
Signed-off-by: Lars Povlsen <[email protected]>
Reviewed-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
If a GPIO bank has greater than 16 pins, PAD_DS_REG is split into two
or more registers. However, when register and bit were calculated, the
first register defined in the bank was used, and the bit was calculated
based on the first pin. This causes problems in setting the driving
strength.
The following method was used to solve this problem:
A bit is calculated first using predefined strides. Then, If the bit is
32 or more, the register is changed by the quotient of the bit divided
by 32. And the bit is set to the remainder.
Signed-off-by: Hyeonki Hong <[email protected]>
Link: https://lore.kernel.org/r/20200618025916.GA19368@home-desktop
Signed-off-by: Linus Walleij <[email protected]>
|
|
Use the correct the function name in the documentation for
"pcs_parse_one_pinctrl_entry()".
"smux_parse_one_pinctrl_entry()" appears to be an artifact from the
development of a prior patch series ("simple pinmux driver") which
transformed into pinctrl-single.
Fixes: 8b8b091bf07f ("pinctrl: Add one-register-per-pin type device tree based pinctrl driver")
Signed-off-by: Drew Fustini <[email protected]>
Link: https://lore.kernel.org/r/20200617180543.GA4186054@x1
Signed-off-by: Linus Walleij <[email protected]>
|
|
Increase #pinctrl-cells to 2 so that mux and conf be kept separate. This
requires the AM33XX_PADCONF macro in omap.h to also be modified to keep pin
conf and pin mux values separate.
Signed-off-by: Drew Fustini <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Acked-by: Haojian Zhuang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
If "pinctrl-single,pins" has 3 arguments (offset, conf, mux), then
pcs_parse_one_pinctrl_entry() does an OR operation on conf and mux to
get the value to store in the register.
Signed-off-by: Drew Fustini <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Acked-by: Haojian Zhuang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8DXL
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8QM
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8QXP
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MP
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MQ
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MN
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Change configuration to "tristate", add module device table,
author, description and license to support building i.MX8MM
pinctrl driver as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Export necessary APIs to support i.MX8 SCU SoCs pinctrl driver to be
built as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Export necessary APIs to support i.MX8 SoCs pinctrl driver to be
built as module.
Signed-off-by: Anson Huang <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into devel
pinctrl: sh-pfc: Updates for v5.9
- Add RPC (HyperFlash and Octal-SPI Flash) pin groups on R-Car V3H and
V3M.
|
|
Intel Tiger Lake-H has different pin layout than the -LP variant
so add support for this to the existing Tiger Lake driver.
Signed-off-by: Mika Westerberg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
It is useful to control I²S bus 2 pins if we would like to connect
an audio codec.
Reported-by: mouse <[email protected]>
Reported-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Some of the pin names were provided officially to the customers
in different spelling. We update pin names in accordance with
the official list.
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
Add the RPC pins/groups/functions to the R8A77970 PFC driver.
They can be used if an Octal-SPI flash or HyperFlash is connected.
Based on the patch by Dmitry Shifrin <[email protected]>.
Signed-off-by: Sergei Shtylyov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Geert Uytterhoeven <[email protected]>
|
|
Add the RPC pins/groups/functions to the R8A77980 PFC driver.
They can be used if an Octal-SPI flash or HyperFlash is connected.
Based on the patch by Dmitry Shifrin <[email protected]>.
Signed-off-by: Sergei Shtylyov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Geert Uytterhoeven <[email protected]>
|
|
GPIOD_OUT_HIGH)
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: [email protected]
Fixes: 86e3ef812fe3 ("pinctrl: baytrail: Update gpio chip operations")
Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
Since we dependent on ACPI, there is no need to use ACPI_PTR()
which is a no-op in this case.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Since we dependent on ACPI, there is no need to use ACPI_PTR()
which is a no-op in this case.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Introduce couple of helpers to enable or disable input. i.e.
lp_gpio_enable_input() and lp_gpio_disable_input().
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Make use of for_each_requested_gpio() instead of home grown analogue.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Make use of for_each_requested_gpio_in_range() instead of home grown analogue.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Protect IO in intel_gpio_get_direction(), intel_gpio_community_irq_handler(),
intel_config_get_debounce() and intel_config_get_pull() by lock. Even for
simple readl() we better serialize IO to avoid potential problems.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Split intel_config_get() to three functions, i.e. intel_config_get() and
two helpers intel_config_get_pull() and intel_config_get_debounce() to be
symmetrical with intel_config_set*().
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Drop the only label in the code, i.e. in intel_config_set_debounce(),
for consistency with the rest. In entire driver we use multipoint
return.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
In a code like
if (...) {
...
goto label;
} else {
...
}
the 'else' keyword is redundant. Get rid of it for better readability.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Instead of using bitwise operations against returned values,
which is a bit fragile, convert IRQ handler to count amount of
GPIO groups, where at least one interrupt happened, and convert
it to returned value by IRQ_RETVAL() macro.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
In some cases lock covers unneeded calls and operations.
Reduce scope of the lock in such cases.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
It's possible scenario that pin has been in different mode, while
the respective GPIO register has a leftover output buffer enabled.
In such case when we request GPIO it will switch to GPIO mode, and
thus to output with unknown value, followed by switching to input
mode. This can produce a glitch on the pin.
Disable input and output buffer when switching to GPIO to avoid
potential glitches.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
We have some data structures duplicated across the drivers.
Let's deduplicate them by using struct intel_pinctrl_soc_data,
struct intel_community and struct intel_pinctrl_context that
are being provided by pinctrl-intel.h.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Individual drivers may install ACPI OpRegion handlers based on
address space ID which differs from community to community.
Add special field in the struct intel_community for that purpose.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Some of the pin control devices may not be capable to generate IRQ
per each pin in the community. Allow individual drivers to define
total amount of IRQs per community.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
chv_writel() is now solely used for cases where we write data
to the PAD registers. In order to simplify callers, calculate
register address inside chv_writel().
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
Pin control device and effectively the single community in it has
a set of common registers. It's good to have a helpers to IO on them.
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
There are plenty of places where we call
readl(chv_padreg(pctrl, offset, ...));
Replace them with newly introduced chv_readl() helper
chv_readl(pctrl, offset, ...);
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>
|
|
|
|
Make use of for_each_requested_gpio() instead of home grown analogue.
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Ludovic Desroches <[email protected]>
Cc: Nicolas Ferre <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Make use of for_each_requested_gpio() instead of home grown analogue.
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Nandor Han <[email protected]>
Cc: Semi Malinen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
Make use of for_each_requested_gpio() instead of home grown analogue.
Signed-off-by: Andy Shevchenko <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: "Uwe Kleine-König" <[email protected]>
Cc: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|