| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.
While at it, split out the GPIO group of headers.
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
Now that the regmap can be queried whether it might sleep, we can get
rid of the conservative setting "can_sleep = true". New drivers which
want to use gpio-regmap and can access the registers memory-mapped won't
have the restriction that their consumers have to use the
gpiod_*cansleep() variants anymore.
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
If you only have reg_dat_base set, then it is input-only; if you only
have reg_set_base set, then it is output-only. Thus, we can always set
gpio_chip get_direction to gpio_regmap_get_direction and return
GPIO_LINE_DIRECTION_IN/GPIO_LINE_DIRECTION_OUT given the respective
register base addresses configuration.
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Michael Walle <[email protected]>
Signed-off-by: William Breathitt Gray <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Michael Walle <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
Drop gpio_regmap_set_drvdata() and instead add it to the configuration
data passed to gpio_regmap_register().
gpio_regmap_set_drvdata() can't really be used in a race free way. This
is because the gpio_regmap object which is needed by _set_drvdata() is
returned by gpio_regmap_register(). On the other hand, the callbacks
which use the drvdata might already be called right after the
gpiochip_add() call in gpio_regmap_register(). Therefore, we have to
provide the drvdata early before we call gpiochip_add().
Signed-off-by: Matti Vaittinen <[email protected]>
Signed-off-by: Michael Walle <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
Slightly simplify the devm_gpio_regmap_register() by using the
devm_add_action_or_reset().
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Michael Walle <[email protected]>
Signed-off-by: Matti Vaittinen <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
|
|
This is needed for properly registering GPIO regmap as a child of a regmap
pin controller.
Signed-off-by: Álvaro Fernández Rojas <[email protected]>
Reviewed-by: Michael Walle <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Bartosz Golaszewski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|
|
There are quite a lot simple GPIO controller which are using regmap to
access the hardware. This driver tries to be a base to unify existing
code into one place. This won't cover everything but it should be a good
starting point.
It does not implement its own irq_chip because there is already a
generic one for regmap based devices. Instead, the irq_chip will be
instantiated in the parent driver and its irq domain will be associate
to this driver.
For now it consists of the usual registers, like set (and an optional
clear) data register, an input register and direction registers.
Out-of-the-box, it supports consecutive register mappings and mappings
where the registers have gaps between them with a linear mapping between
GPIO offset and bit position. For weirder mappings the user can register
its own .xlate().
Signed-off-by: Michael Walle <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>
|