GPIOs that attempt to use interrupts get thwarted with a message like:
"pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because
the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's
owned by ACPI.
Fixes: e278dcb704 ("pinctrl: intel: Add Intel Jasper Lake pin controller support")
Cc: stable@vger.kernel.org
Signed-off-by: Evan Green <evgreen@chromium.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
If the group of pins is hidden in the pin list it affects
the register offset calculation despite fixed GPIO base.
Hence, the offsets of all pins after the hidden group
are broken. Instead we have to unhide the group and use a flag
to exclude it from GPIO number space.
Fixes: e278dcb704 ("pinctrl: intel: Add Intel Jasper Lake pin controller support")
Reported-by: Divagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
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: 658b476c74 ("pinctrl: baytrail: Add debounce configuration")
Depends-on: 04ff5a095d ("pinctrl: baytrail: Rectify debounce support")
Depends-on: 827e1579e1 ("pinctrl: baytrail: Rectify debounce support (part 2)")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
On SuperH and ARM SH/R-Mobile SoCs, the pin control driver handles
GPIOs, too. To reduce code size when compiling a kernel supporting only
modern SoCs, most, but not all, of the GPIO functionality is protected
by checks for CONFIG_PINCTRL_SH_FUNC_GPIO.
Factor out the remaining parts when not needed:
1. sh_pfc_soc_info.{in,out}put describe GPIO pins that have input
resp. output capabilities (SuperH and SH/R-Mobile).
2. sh_pfc_soc_info.gpio_irq{,_size} describe the mapping from GPIO
pins to interrupt numbers (SH/R-Mobile).
3. sh_pfc_gpio_set_direction() configures GPIO direction, called from
the GPIO driver through pinctrl_gpio_direction_{in,out}put()
(SH/R-Mobile). Unfortunately this function cannot just be moved to
drivers/pinctrl/renesas/gpio.c, as it relies on knowledge of
sh_pfc_pinctrl, which is internal to
drivers/pinctrl/renesas/pinctrl.c.
While code size reduction is minimal, this does help in documenting
depencies.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028151637.1734130-9-geert+renesas@glider.be
Currently, the rcar_pinmux_[gs]et_bias() helpers handle only SoCs that
have separate LSI Pin Pull-Enable (PUEN) and Pull-Up/Down Control (PUD)
registers, like R-Car Gen3 and RZ/G2. Update the function to handle
SoCs that have only LSI Pin Pull-Up Control Register (PUPR), like R-Car
Gen1/Gen2 and RZ/G1.
Reduce code duplication by converting the R-Car M1A pin control driver
to use the common handler.
Note that this changes behavior in case the (invalid!) option
"bias-pull-down" is used in an R-Car M1A DTS: before, it was ignored
silently; after this change, it is considered the same as
"bias-pull-up".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028151637.1734130-8-geert+renesas@glider.be
The handling of the LSI Pin Pull-Up Control Registers (PUPR) on R-Car
M1A uses register offsets instead of register physical addresses.
This is different from the handling on other R-Car parts.
Convert the bias handling from register offsets to physical addresses.
This increases uniformity, and prepares for consolidation of the bias
handling.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028151637.1734130-7-geert+renesas@glider.be
Shrink sh_pfc_pin_config from 8 to 2 bytes:
- The mux_set flag can be removed, as a non-zero mark value means the
same (zero = PINMUX_RESERVED is an invalid mark value),
- The gpio_enabled flag needs only a single bit,
- Mark values are small integers, and can easily fit in a 15-bit
bitfield.
This saves 6 bytes per pin when allocating the sh_pfc_pinctrl.configs
array, i.e. it reduces run-time memory consumption by ca. 1.5 KiB.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028151637.1734130-5-geert+renesas@glider.be
On arm64, pointer size and alignment is 64-bit, hence a 4-byte hole is
present in between the enum_id and name members of the sh_pfc_pin
structure. Get rid of this hole by sorting the structure's members by
decreasing size.
This saves up to 1.5 KiB per enabled SoC, and reduces the size of a
kernel including support for all R-Car Gen3 SoCs by more than 10 KiB.
This has no size impact on SH and arm32.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20201028151637.1734130-4-geert+renesas@glider.be
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: 4e80c8f505 ("pinctrl: intel: Add Intel Merrifield pin controller support")
Depends-on: 2956b5d94a ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
GPIOs that attempt to use interrupts get thwarted with a message like:
"pin 161 cannot be used as IRQ" (for instance with SD_CD). This is because
the HOSTSW_OWN offset is incorrect, so every GPIO looks like it's
owned by ACPI.
Fixes: e278dcb704 ("pinctrl: intel: Add Intel Jasper Lake pin controller support")
Cc: stable@vger.kernel.org
Signed-off-by: Evan Green <evgreen@chromium.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
If the group of pins is hidden in the pin list it affects
the register offset calculation despite fixed GPIO base.
Hence, the offsets of all pins after the hidden group
are broken. Instead we have to unhide the group and use a flag
to exclude it from GPIO number space.
Fixes: e278dcb704 ("pinctrl: intel: Add Intel Jasper Lake pin controller support")
Reported-by: Divagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
It appears that pin configuration for GPIO chip hasn't been enabled yet
due to absence of ->set_config() callback.
Enable it here for Intel Lynxpoint PCH.
Depends-on: 2956b5d94a ("pinctrl / gpio: Introduce .set_config() callback for GPIO chips")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We have a specific constant to describe a disabled bias,
i.e. GPIWP_NONE. Use it explicitly instead of making
an assumption about its value.
While at it, move argument assignment to the switch-case
in lp_pin_config_get().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
intel-pinctrl for v5.10-2
* Respect bias setting when comes from ACPI
The following is an automated git shortlog grouped by driver:
intel:
- Set default bias in case no particular value given
- Fix 2 kOhm bias which is 833 Ohm
Print the status of debounce filter as follows,
$ cat /sys/kernel/debug/gpio
pin129 interrupt is disabled | interrupt is masked |
disable wakeup in S0i3 state | disable wakeup in S3 state |
disable wakeup in S4/S5 state| input is high | pull-up is disabled |
Pull-down is disabled | output is disabled |
debouncing filter disabled | 0x50000
pin130 interrupt is disabled | interrupt is masked |
disable wakeup in S0i3 state | disable wakeup in S3 state |
disable wakeup in S4/S5 state | input is high | pull-up is disabled |
Pull-down is disabled | output is disabled |
debouncing filter (high) enabled |
debouncing timeout is 124800 (us)| 0x503c8
Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
Link: https://lore.kernel.org/r/20201105231912.69527-4-coiby.xu@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add the "lcd-8bit" group to the "lcd" function.
As "lcd-24bit" is a superset of "lcd-8bit", in theory the former could
be modified to only contain the pins not already included in "lcd-8bit",
just like how it's done for the JZ4740 and JZ4725B platforms. However,
we can't do that without breaking Device Tree ABI, so in that case we
have no choice but to have two groups containing the same pins.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Link: https://lore.kernel.org/r/20201101090104.5088-3-paul@crapouillou.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Abuse the pin function pointer to store the pin function value directly,
when all the pins of a group have the same function value. Now when the
pointer value is <= 3 (unsigned), the pointer value is used as the pin
function; otherwise it is used as a regular pointer.
This drastically reduces the number of pin function tables needed, and
drops .data usage by about 2 KiB. Additionally, the few pin function
tables that are still around now contain u8 instead of int, since the
largest number that will be stored is 3.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Tested-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
Link: https://lore.kernel.org/r/20201101090104.5088-2-paul@crapouillou.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When GPIOs that are routed to PDC are used as output they can still latch
the IRQ pending at GIC. As a result the spurious IRQ was handled when the
client driver change the direction to input to starts using it as IRQ.
Currently such erroneous latched IRQ are cleared with .irq_enable callback
however if the driver continue to use GPIO as interrupt and invokes
disable_irq() followed by enable_irq() then everytime during enable_irq()
previously latched interrupt gets cleared.
This can make edge IRQs not seen after enable_irq() if they had arrived
after the driver has invoked disable_irq() and were pending at GIC.
Move clearing erroneous IRQ to .irq_request_resources callback as this is
the place where GPIO direction is changed as input and its locked as IRQ.
While at this add a missing check to invoke msm_gpio_irq_clear_unmask()
from .irq_enable callback only when GPIO is not routed to PDC.
Fixes: e35a6ae0eb ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Link: https://lore.kernel.org/r/1604561884-10166-1-git-send-email-mkshah@codeaurora.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
