aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpio/gpio-mmio.c
Commit message (Collapse)AuthorAgeFilesLines
* refactor(gpio): change set functions to return intsaturneric2025-10-171-2/+3
| | | | | | | * Update `bgpio_set_direct` and `bgpio_set_multiple_direct` to return an integer instead of void for better error handling. * This change allows the caller to check for success or failure of the operations.
* Merge tag 'v6.17'saturneric2025-10-161-54/+54
|\ | | | | | | Linux 6.17
| * treewide: rename GPIO set callbacks back to their original namesBartosz Golaszewski2025-08-071-12/+12
| | | | | | | | | | | | | | | | | | | | | | The conversion of all GPIO drivers to using the .set_rv() and .set_multiple_rv() callbacks from struct gpio_chip (which - unlike their predecessors - return an integer and allow the controller drivers to indicate failures to users) is now complete and the legacy ones have been removed. Rename the new callbacks back to their original names in one sweeping change. Signed-off-by: Bartosz Golaszewski <[email protected]>
| * Merge tag 'gpio-mmio-remove-bgpio-pdata-for-v6.17-rc1' into gpio/for-nextBartosz Golaszewski2025-07-071-42/+19
| |\ | | | | | | | | | | | | | | | | | | Immutable branch between GPIO, MFD and ARM-SoC for v6.17-rc1 Remove struct bgpio_pdata after converting its users to generic device properties.
| | * gpio: mmio: remove struct bgpio_pdataBartosz Golaszewski2025-07-071-54/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With no more users, we can now remove struct bgpio_pdata. Move the relevant bits from bgpio_parse_fw() into bgpio_pdev_probe() while maintaining the logical ordering (get flags before calling bgpio_init()). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| | * gpio: mmio: get chip label and GPIO base from device propertiesBartosz Golaszewski2025-07-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ahead of removing struct bgpio_pdata support from the gpio-mmio generic module, let's add support for getting the relevant values from generic device properties. "label" is a semi-standardized property in some GPIO drivers so let's go with it. There's no standard "base" property, so let's use the name "gpio-mmio,base" to tie it to this driver specifically. The number of GPIOs will be retrieved using gpiochip_get_ngpios() so there's no need to look it up in the software node. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| | * gpio: mmio: drop the big-endian platform device variantBartosz Golaszewski2025-07-071-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | There are no more users of the "basic-mmio-gpio-be" platform device ID in the kernel. We can safely drop it. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * | gpio: mmio: don't use legacy GPIO chip settersBartosz Golaszewski2025-06-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've converted this driver to using the new GPIO line value setters but missed the instances where the legacy callback is accessed directly using the function pointer. This will lead to a NULL-pointer dereference as this pointer is no longer populated. The issue needs fixing locally as well as in the already converted previously users of gpio-mmio. Fixes: b908d35d0003 ("gpio: mmio: use new GPIO line value setter callbacks") Reported-by: Klara Modin <[email protected]> Closes: https://lore.kernel.org/all/2rw2sncevdiyirpdovotztlg77apcq2btzytuv5jnm55aqhlne@swtts3hl53tw/ Tested-by: Klara Modin <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Tested-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * | Merge tag 'gpio-mmio-bgpiof-no-input-flag-for-v6.17' into gpio/for-nextBartosz Golaszewski2025-06-191-1/+10
| |\ \ | | | | | | | | | | | | | | | | | | | | Immutable tag for the pinctrl tree to pull from Add the BGPIOF_NO_INPUT to the gpio-mmio API.
| | * | gpio: mmio: add BGPIOF_NO_INPUT flag for GPO gpiochipClément Le Goffic2025-06-191-1/+10
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using bgpio_init with a gpiochip acting as a GPO (output only), the gpiochip ops `direction_input` was set to `bgpio_simple_dir_in` by default but we have no input ability. Adding this flag allows to set a valid ops for the `direction_output` ops without setting a valid ops for `direction_input` by default. Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Clément Le Goffic <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
| * / gpio: mmio: use new GPIO line value setter callbacksBartosz Golaszewski2025-06-171-20/+33
| |/ | | | | | | | | | | | | | | | | | | struct gpio_chip now has callbacks for setting line values that return an integer, allowing to indicate failures. Convert the driver to using them. Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | Merge remote-tracking UNTIL 21. Apr. 2025saturneric2025-04-211-8/+29
|\|
| * gpio: mmio: Add flag for calling pinctrl back-endLinus Walleij2025-02-241-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that with this flag we can switch over an entire driver to use gpio-mmio instead of a bunch of custom code, also providing get/set_multiple() to it in the process, so it seems like a reasonable feature to add. The generic pin control backend requires us to call the gpiochip_generic_request(), gpiochip_generic_free(), pinctrl_gpio_direction_output() and pinctrl_gpio_direction_input() callbacks, so if the new flag for a pin control back-end is set, we make sure these functions get called as expected. Signed-off-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bartosz Golaszewski <[email protected]>
* | fix: drivers patch make raspberry pi 5 work properlysaturneric2025-01-121-5/+119
|/
* gpio: mmio: do not calculate bgpio_bits via "ngpios"Shiji Yang2024-07-031-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | bgpio_bits must be aligned with the data bus width. For example, on a 32 bit big endian system and we only have 16 GPIOs. If we only assume bgpio_bits=16 we can never control the GPIO because the base address is the lowest address. low address high address ------------------------------------------------- | byte3 | byte2 | byte1 | byte0 | ------------------------------------------------- | NaN | NaN | gpio8-15 | gpio0-7 | ------------------------------------------------- Fixes: 55b2395e4e92 ("gpio: mmio: handle "ngpios" properly in bgpio_init()") Fixes: https://github.com/openwrt/openwrt/issues/15739 Reported-by: Mark Mentovai <[email protected]> Signed-off-by: Shiji Yang <[email protected]> Suggested-By: Mark Mentovai <[email protected]> Reviewed-by: Jonas Gorski <[email protected]> Tested-by: Lóránd Horváth <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/TYCP286MB089577B47D70F0AB25ABA6F5BCD52@TYCP286MB0895.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: mmio: Clean up headersAndy Shevchenko2023-12-181-13/+11
| | | | | | | | | | | | There is a few things done: - include only the headers we are direct user of - add missing headers - group generic headers and subsystem headers - sort each group alphabetically Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: mmio: Make use of device propertiesAndy Shevchenko2023-12-181-18/+7
| | | | | | | | | Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: Use device_get_match_data()Rob Herring2023-10-091-2/+2
| | | | | | | | | Use preferred device_get_match_data() instead of of_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: mmio: handle "ngpios" properly in bgpio_init()Asmaa Mnebhi2023-07-181-1/+8
| | | | | | | | | | | | | | | | | | bgpio_init() uses "sz" argument to populate ngpio, which is not accurate. Instead, read the "ngpios" property from the DT and if it doesn't exist, use the "sz" argument. With this change, drivers no longer need to overwrite the ngpio variable after calling bgpio_init(). If the "ngpios" property is specified, bgpio_bits is calculated as the round up value of ngpio. At the moment, the only requirement specified is that the round up value must be a multiple of 8 but it should also be a power of 2 because we provide accessors based on the bank size in bgpio_setup_accessors(). Signed-off-by: Asmaa Mnebhi <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: use raw spinlock for gpio chip shadowed dataSchspa Shi2022-04-251-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of PREEMPT_RT, there is a raw_spinlock -> spinlock dependency as the lockdep report shows. __irq_set_handler irq_get_desc_buslock __irq_get_desc_lock raw_spin_lock_irqsave(&desc->lock, *flags); // raw spinlock get here __irq_do_set_handler mask_ack_irq dwapb_irq_ack spin_lock_irqsave(&gc->bgpio_lock, flags); // sleep able spinlock irq_put_desc_busunlock Replace with a raw lock to avoid BUGs. This lock is only used to access registers, and It's safe to replace with the raw lock without bad influence. [ 15.090359][ T1] ============================= [ 15.090365][ T1] [ BUG: Invalid wait context ] [ 15.090373][ T1] 5.10.59-rt52-00983-g186a6841c682-dirty #3 Not tainted [ 15.090386][ T1] ----------------------------- [ 15.090392][ T1] swapper/0/1 is trying to lock: [ 15.090402][ T1] 70ff00018507c188 (&gc->bgpio_lock){....}-{3:3}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090470][ T1] other info that might help us debug this: [ 15.090477][ T1] context-{5:5} [ 15.090485][ T1] 3 locks held by swapper/0/1: [ 15.090497][ T1] #0: c2ff0001816de1a0 (&dev->mutex){....}-{4:4}, at: __device_driver_lock+0x98/0x104 [ 15.090553][ T1] #1: ffff90001485b4b8 (irq_domain_mutex){+.+.}-{4:4}, at: irq_domain_associate+0xbc/0x6d4 [ 15.090606][ T1] #2: 4bff000185d7a8e0 (lock_class){....}-{2:2}, at: _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090654][ T1] stack backtrace: [ 15.090661][ T1] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.59-rt52-00983-g186a6841c682-dirty #3 [ 15.090682][ T1] Hardware name: Horizon Robotics Journey 5 DVB (DT) [ 15.090692][ T1] Call trace: ...... [ 15.090811][ T1] _raw_spin_lock_irqsave+0x1c/0x28 [ 15.090828][ T1] dwapb_irq_ack+0xb4/0x300 [ 15.090846][ T1] __irq_do_set_handler+0x494/0xb2c [ 15.090864][ T1] __irq_set_handler+0x74/0x114 [ 15.090881][ T1] irq_set_chip_and_handler_name+0x44/0x58 [ 15.090900][ T1] gpiochip_irq_map+0x210/0x644 Signed-off-by: Schspa Shi <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Doug Berger <[email protected]> Acked-by: Serge Semin <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: mmio: replace open-coded for_each_set_bit()Andy Shevchenko2020-07-161-13/+7
| | | | | | | | Use for_each_set_bit() instead of open-coding it to simplify the code. Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: introduce BGPIOF_NO_SET_ON_INPUTChuanhong Guo2020-03-251-4/+19
| | | | | | | | | | | | | | | Some gpio controllers ignores pin value writing when that pin is configured as input mode. As a result, bgpio_dir_out should set pin to output before configuring pin values or gpio pin values can't be set up properly. Introduce two variants of bgpio_dir_out: bgpio_dir_out_val_first and bgpio_dir_out_dir_first, and assign direction_output according to a new flag: BGPIOF_NO_SET_ON_INPUT. Signed-off-by: Chuanhong Guo <[email protected]> Tested-by: René van Dorst <[email protected]> Reviewed-by: Sergio Paracuellos <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: mmio: remove untrue leftover commentMatti Vaittinen2019-11-131-1/+0
| | | | | | | | | | The comment should have been removed when new GPIO direction definitions were taken in use as the function logic was changed. It is now perfectly valid and Ok to hit the return from the bottom of the direction getting function. Signed-off-by: Matti Vaittinen <[email protected]> Signed-off-by: Bartosz Golaszewski <[email protected]>
* gpio: Use new GPIO_LINE_DIRECTIONMatti Vaittinen2019-11-071-6/+15
| | | | | | | | | | | | | | | | | | | | | It's hard for occasional GPIO code reader/writer to know if values 0/1 equal to IN or OUT. Use defined GPIO_LINE_DIRECTION_IN and GPIO_LINE_DIRECTION_OUT to help them out. NOTE - for gpio-amd-fch and gpio-bd9571mwv: This commit also changes the return value for direction get to equal 1 for direction INPUT. Prior this commit these drivers might have returned some other positive value but 1 for INPUT. Signed-off-by: Matti Vaittinen <[email protected]> Acked-by: Scott Branden <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Reviewed-by: Michal Simek <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Acked-by: William Breathitt Gray <[email protected]> Acked-by: Kuppuswamy Sathyanarayanan <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Drop bgpio_dir_invertedLinus Walleij2019-04-081-7/+0
| | | | | | | | | | 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 <[email protected]> Reviewed-by: Jan Kotas <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Fix bgpio_get_set & bgpio_get_set_multipleJan Kotas2019-04-041-19/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During my regression testing I noticed the cadence GPIO driver fails on the latest gpio for-next tree. I think the reason is this patch: commit 96cd559817f2 ("Merge branch 'devel' into for-next") Here is a part of the test log: Loopback 8 -> 24 TESTING: gpio: 488: output direction PASSED TESTING: gpio: 504: input direction PASSED TESTING: gpio: 488: 0 PASSED TESTING: gpio: 488 -> 504: 0 PASSED TESTING: gpio: 488: 1 FAILED TESTING: gpio: 488 -> 504: 1 FAILED TESTING: gpio: 488: 0 PASSED TESTING: gpio: 488 -> 504: 0 PASSED It looks like the issue is that gc->bgpio_dir has changed its meaning. It used to be set to the register value (so it was being inverted). Now it's always set to 1 for output and 0 for input. However the bgpio_get_set functions were not updated. So they invert the bit again, which means a wrong register is being accessed. This patch fixes that by removing the unnecessary inversion. Signed-off-by: Jan Kotas <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Support two direction registersLinus Walleij2019-04-041-29/+56
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]> Cc: Shravan Kumar Ramani <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: Use SPDX header for core libraryLinus Walleij2018-09-251-5/+1
| | | | | | | Use the SPDX headers and cut down on boilerplate to indicate the license in the core gpiolib implementation. Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Fix up inverted direction registersLinus Walleij2018-08-101-45/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bgpio_init() takes one of two arguments to specify a register to set the direction of the GPIO line: either dirout that indicates that a 1 in the bit in that register sets the corresponding line to output, or dirin which indicates that a 1 in the bit in that register sets the corresponding line to input. Conversely setting the bit to 0 on these will turn the line into input and output respectively. One of these can be defined but not both. This means that a platform that sets a bit to 1 for output only defines dirout and a platform that sets a bit to 0 for output only defines dirin. In short this defines the polarity of the direction register. Both can also be left as NULL meaning the GPIO chip is either input only or output only. Tomer Maimon discovered that for get/set chips (those where the get and set registers are defined but no separate clear register, and specifying BGPIOF_READ_OUTPUT_REG_SET so that we say we want to read the output value from the SET register) we are unconditionally reading the value from the SET register when the direction bit is 1 and from the DAT register when the direction bit is 0, not taking the direction bit polarity into account. It would be expected that when the direction bit is inverted (dirin is defined but not dirout) we read the current value from the DAT register when the bit is 1 and from the SET register when the bit is 0. Currently only some versions of ATH79, brcmstb, some versions of CLP711x, GE, IOP and Loongson use the dirin mode (a 1 in the register means input). They are unaffected because BGPIOF_READ_OUTPUT_REG_SET is not set on any of them. (They do not read back the SET register to figure out the output value.) So this is no regression with current drivers. However the behaviour is wrong and does not work with Tomer's new driver where he needs to use the BGIOF_READ_OUTPUT_REG_SET. This fixes the above issue by: - Instead of defining separate functions for the inverted case, set up a flag in the gpio_chip that indicates that the direction is inverted. - Remove the special inverted functions for setting input/output and getting the direction, rely on the flag instead. - Respect this flag in bgpio_get_set() and bgpio_get_set_multiple() Reported-by: Tomer Maimon <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Also read bits that are zeroLinus Walleij2018-01-161-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code for .get_multiple() has bugs: 1. The simple .get_multiple() just reads a register, masks it and sets the return value. This is not correct: we only want to assign values (whether 0 or 1) to the bits that are set in the mask. Fix this by using &= ~mask to clear all bits in the mask and then |= val & mask to set the corresponding bits from the read. 2. The bgpio_get_multiple_be() call has a similar problem: it uses the |= operator to set the bits, so only the bits in the mask are affected, but it misses to clear all returned bits from the mask initially, so some bits will be returned erroneously set to 1. 3. The bgpio_get_set_multiple() again fails to clear the bits from the mask. 4. find_next_bit() wasn't handled correctly, use a totally different approach for one function and change the other function to follow the design pattern of assigning the first bit to -1, then use bit + 1 in the for loop and < num_iterations as break condition. Fixes: 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback") Cc: Bartosz Golaszewski <[email protected]> Reported-by: Clemens Gruber <[email protected]> Tested-by: Clemens Gruber <[email protected]> Reported-by: Lukas Wunner <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio-mmio: Use the new .get_multiple() callbackLinus Walleij2017-10-301-3/+84
| | | | | | | | | | | | | | | | | It is possible to read all lines of a generic MMIO GPIO chip with a single register read so support this if we are in native endianness. Add an especially quirky callback to read multiple lines for the variants that require you to read values from the output registers if and only if the line is set as output. We managed to do that with a maximum of two register reads, and just one read if the requested lines are all input or all output. Cc: Anton Vorontsov <[email protected]> Cc: Lukas Wunner <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: Make pin2mask() a private businessLinus Walleij2017-10-251-26/+19
| | | | | | | | | | | | | | The vtable call pin2mask() was introducing a vtable function call in every gpiochip callback for a generic MMIO GPIO chip. This was not exactly efficient. (Maybe link-time optimization could get rid of it, I don't know.) After removing all external calls into this API we can make it a boolean flag in the struct gpio_chip call and sink the function into the gpio-mmio driver yielding encapsulation and potential speedups. Cc: Anton Vorontsov <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: add support for NI 169445 NAND GPIONathan Sullivan2017-03-231-0/+1
| | | | | | | | The GPIO-based NAND controller on National Instruments 169445 hardware exposes a set of simple lines for the control signals. Signed-off-by: Nathan Sullivan <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: add brcm,bcm6345 supportChristian Lamparter2016-08-111-0/+4
| | | | | | | | | | | This patch adds support for the GPIO found in Broadcom's bcm63xx-gpio chips. This GPIO controller is used in the following Broadcom SoCs: BCM6338, BCM6345. It can be used in newer SoCs, without the capability of pin multiplexing. Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Álvaro Fernández Rojas <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: add MyBook Live GPIO supportChristian Lamparter2016-06-081-0/+4
| | | | | | | | | | | | This patch adds support for the Western Digital's MyBook Live memory-mapped GPIO controllers. The GPIOs will be supported by the generic driver for memory-mapped GPIO controllers. Signed-off-by: Christian Lamparter <[email protected]> Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: mmio: add DT support for memory-mapped GPIOsÁlvaro Fernández Rojas2016-06-081-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for defining memory-mapped GPIOs which are compatible with the existing gpio-mmio interface. The generic library provides support for many memory-mapped GPIO controllers that are found in various on-board FPGA and ASIC solutions that are used to control board's switches, LEDs, chip-selects, Ethernet/USB PHY power, etc. For setting GPIOs there are three configurations: 1. single input/output register resource (named "dat"), 2. set/clear pair (named "set" and "clr"), 3. single output register resource and single input resource ("set" and dat"). The configuration is detected by which resources are present. For the single output register, this drives a 1 by setting a bit and a zero by clearing a bit. For the set clr pair, this drives a 1 by setting a bit in the set register and clears it by setting a bit in the clear register. For setting the GPIO direction, there are three configurations: a. simple bidirectional GPIOs that requires no configuration. b. an output direction register (named "dirout") where a 1 bit indicates the GPIO is an output. c. an input direction register (named "dirin") where a 1 bit indicates the GPIO is an input. Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Álvaro Fernández Rojas <[email protected]> Signed-off-by: Christian Lamparter <[email protected]> Acked-by: Alexandre Courbot <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
* gpio: rename gpio-generic.c into gpio-mmio.cChristian Lamparter2016-04-291-0/+660
This patch renames the gpio-generic.c into gpio-mmio.c. This is because currently the file only contains code for a memory-mapped GPIO driver. There isn't any support for ioports or other resource type. Signed-off-by: Christian Lamparter <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-01 01:57:33 +0000