pm24.git/include/linux/gpio, branch v5.2-rc1

Merge tag 'gpio-v5.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

2019-05-11T14:54:43Z

Pull gpio updates from Linus Walleij: "This is the bulk of the GPIO changes for the v5.2 kernel cycle. A bit later than usual because I was ironing out my own mistakes. I'm holding some stuff back for the next kernel as a result, and this should be a healthy and well tested batch. Core changes: - The gpiolib MMIO driver has been enhanced to handle two direction registers, i.e. one register to set lines as input and one register to set lines as output. It turns out some silicon engineer thinks the ability to configure a line as input and output at the same time makes sense, this can be debated but includes a lot of analog electronics reasoning, and the registers are there and need to be handled consistently. Unsurprisingly, we enforce the lines to be either inputs or outputs in such schemes. - Send in the proper argument value to .set_config() dispatched to the pin control subsystem. Nobody used it before, now someone does, so fix it to work as expected. - The ACPI gpiolib portions can now handle pin bias setting (pull up or pull down). This has been in the ACPI spec for years and we finally have it properly integrated with Linux GPIOs. It was based on an observation from Andy Schevchenko that Thomas Petazzoni's changes to the core for biasing the PCA950x GPIO expander actually happen to fit hand-in-glove with what the ACPI core needed. Such nice synergies happen sometimes. New drivers: - A new driver for the Mellanox BlueField GPIO controller. This is using 64bit MMIO registers and can configure lines as inputs and outputs at the same time and after improving the MMIO library we handle it just fine. Interesting. - A new IXP4xx proper gpiochip driver with hierarchical interrupts should be coming in from the ARM SoC tree as well. Driver enhancements: - The PCA053x driver handles the CAT9554 GPIO expander. - The PCA053x driver handles the NXP PCAL6416 GPIO expander. - Wake-up support on PCA053x GPIO lines. - OMAP now does a nice asynchronous IRQ handling on wake-ups by letting everything wake up on edges, and this makes runtime PM work as expected too. Misc: - Several cleanups such as devres fixes. - Get rid of some languager comstructs that cause problems when compiling with LLVMs clang. - Documentation review and update" * tag 'gpio-v5.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (85 commits) gpio: Update documentation docs: gpio: convert docs to ReST and rename to *.rst gpio: sch: Remove write-only core_base gpio: pxa: Make two symbols static gpiolib: acpi: Respect pin bias setting gpiolib: acpi: Add acpi_gpio_update_gpiod_lookup_flags() helper gpiolib: acpi: Set pin value, based on bias, more accurately gpiolib: acpi: Change type of dflags gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT gpiolib: Make use of enum gpio_lookup_flags consistent gpiolib: Indent entry values of enum gpio_lookup_flags gpio: pca953x: add support for pca6416 dt-bindings: gpio: pca953x: document the nxp,pca6416 gpio: pca953x: add pcal6416 to the of_device_id table gpio: gpio-omap: Remove conditional pm_runtime handling for GPIO interrupts gpio: gpio-omap: configure edge detection for level IRQs for idle wakeup tracing: stop making gpio tracing configurable gpio: pca953x: Configure wake-up path when wake-up is enabled gpio: of: Optimize quirk checks gpio: mmio: Drop bgpio_dir_inverted ...

gpiolib: Introduce GPIO_LOOKUP_FLAGS_DEFAULT

2019-04-23T08:55:10Z

Since GPIO library operates with enumerator when it's subject to handle the GPIO lookup flags, it will be better to clearly see what default means. Thus, introduce GPIO_LOOKUP_FLAGS_DEFAULT entry to describe the default assumptions. While here, replace 0 by newly introduced constant. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij

gpiolib: Make use of enum gpio_lookup_flags consistent

2019-04-23T08:55:07Z

The library uses enum gpio_lookup_flags to define the possible characteristics of GPIO pin. Since enumerator listed only individual bits the common use of it is in a form of a bitmask of gpio_lookup_flags GPIO_* values. The more correct type for this is unsigned long. Due to above convert all users to use unsigned long instead of enum gpio_lookup_flags except enumerator definition. While here, make field and parameter descriptions consistent as well. Suggested-by: Mika Westerberg Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij

gpiolib: Indent entry values of enum gpio_lookup_flags

2019-04-23T08:54:42Z

Indent entry values in the enum gpio_lookup_flags for better readability. No functional change. Signed-off-by: Andy Shevchenko Acked-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Linus Walleij

gpio: mmio: Drop bgpio_dir_inverted

2019-04-08T09:17:43Z

The direction inversion semantics are now handled by simply using the registers for in/out available, no need to keep track of inversion semantics exmplicitly anymore. Reviewed-by: Bartosz Golaszewski Reviewed-by: Jan Kotas Signed-off-by: Linus Walleij

gpio: mmio: Support two direction registers

2019-04-04T17:04:13Z

It turns out that one specific hardware has two direction registers: one to set a GPIO line as input and another one to set a GPIO line as output. So in theory a line can be configured as input and output at the same time. Make the MMIO GPIO helper deal with this: store both registers in the state container, use both in the generic code if present. Synchronize the input register to the output register when we register a GPIO chip, with the output settings taking precedence. Keep the helper variable to detect inverted direction semantics (only direction in register) but augment the code to be more straight-forward for the generic case when setting the registers. Fix some flunky with unreadable direction registers at the same time as we're touching this code. Cc: David Woods Cc: Shravan Kumar Ramani Signed-off-by: Linus Walleij

gpiolib: export devprop_gpiochip_set_names()

2019-03-24T03:48:02Z

This function is needed in mcp23s08. That driver is a special snowflake because it supports several hardware chips as a single "GPIO chip" under Linux. Signed-off-by: Jan Kundrát Cc: Linus Walleij Cc: Phil Reid Acked-by: Mika Westerberg Signed-off-by: Linus Walleij

Merge branch 'ib-pca953x-config' into devel

2019-02-14T07:45:22Z

gpio: add core support for pull-up/pull-down configuration

2019-02-13T08:10:14Z

This commit adds support for configuring the pull-up and pull-down resistors available in some GPIO controllers. While configuring pull-up/pull-down is already possible through the pinctrl subsystem, some GPIO controllers, especially simple ones such as GPIO expanders on I2C, don't have any pinmuxing capability and therefore do not use the pinctrl subsystem. This commit implements the GPIO_PULL_UP and GPIO_PULL_DOWN flags, which can be used from the Device Tree, to enable a pull-up or pull-down resistor on a given GPIO. The flag is simply propagated all the way to the core GPIO subsystem, where it is used to call the gpio_chip ->set_config callback with the appropriate existing PIN_CONFIG_BIAS_* values. Signed-off-by: Thomas Petazzoni Signed-off-by: Linus Walleij

gpio: add irq domain activate/deactivate functions

2019-01-24T14:33:04Z

This adds the two new functions gpiochip_irq_domain_activate and gpiochip_irq_domain_deactivate that can be used as the activate and deactivate functions in the struct irq_domain_ops. This is for situations where only gpiochip_{lock,unlock}_as_irq needs to be called. SPMI and SSBI GPIO are two users that will initially use these functions. Signed-off-by: Brian Masney Suggested-by: Stephen Boyd Reviewed-by: Stephen Boyd Signed-off-by: Linus Walleij