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 <tmaimon77@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There should not be anything more than stated by the name of newly
introduced constants, i.e.
GPIOD_OUT_LOW_OPEN_DRAIN == GPIOD_OUT_LOW + open drain
and nothing more.
Make it better to read and slightly more robust by using GPIOD_OUT_LOW
and GPIOD_OUT_HIGH constants with open drain flag.
No functional change intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On the Aspeed chip, the GPIOs can be under control of the ARM
chip or of the ColdFire coprocessor. (There's a third command
source, the LPC bus, which we don't use or support yet).
The control of which master is allowed to modify a given
GPIO is per-bank (8 GPIOs).
Unfortunately, systems already exist for which we want to
use GPIOs of both sources in the same bank.
This provides an API exported by the gpio-aspeed driver
that an aspeed coprocessor driver can use to "grab" some
GPIOs for use by the coprocessor, and allow the coprocessor
driver to provide callbacks for arbitrating access.
Once at least one GPIO of a given bank has been "grabbed"
by the coprocessor, the entire bank is marked as being
under coprocessor control. It's command source is switched
to the coprocessor.
If the ARM then tries to write to a GPIO in such a marked bank,
the provided callbacks are used to request access from the
coprocessor driver, which is responsible to doing whatever
is necessary to "pause" the coprocessor or prevent it from
trying to use the GPIOs while the ARM is doing its accesses.
During that time, the command source for the bank is temporarily
switched back to the ARM.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The GPIO (descriptor) API registers a "label" naming what is
currently using the GPIO line. Typically this is taken from
things like the device tree node, so "reset-gpios" will result
in he line being labeled "reset".
The technical effect is pretty much zero: the use is for
debug and introspection, such as "lsgpio" and debugfs files.
However sometimes the user want this cuddly feeling of
listing all GPIO lines and seeing exactly what they are for
and it gives a very fulfilling sense of control. Especially
in the cases when the device tree node doesn't provide a
good name, or anonymous GPIO lines assigned just to
"gpios" in the device tree because the usage is implicit.
For these cases it may be nice to be able to label the
line directly and explicitly.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new challenge is to remove VLAs from the kernel
(see https://lkml.org/lkml/2018/3/7/621) to eventually
turn on -Wvla.
Using a kmalloc array is the easy way to fix this but kmalloc is still
more expensive than stack allocation. Introduce a fast path with a
fixed size stack array to cover most chip with gpios below some fixed
amount. The slow path dynamically allocates an array to cover those
chips with a large number of gpios.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Phil Reid <preid@electromag.com.au>
Reviewed-and-tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Board files constitute a significant part of the users of the legacy
GPIO framework. In many cases they only export a line and set its
desired value. We could use GPIO hogs for that like we do for DT and
ACPI but there's no support for that in machine code.
This patch proposes to extend the machine.h API with support for
registering hog tables in board files.
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some qcom platforms make some GPIOs or pins unavailable for use by
non-secure operating systems, and thus reading or writing the registers
for those pins will cause access control issues. Add support for a DT
property to describe the set of GPIOs that are available for use so that
higher level OSes are able to know what pins to avoid reading/writing.
Non-DT platforms can add support by directly updating the
chip->valid_mask.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Timur Tabi <timur@codeaurora.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull GPIO updates from Linus Walleij:
"The is the bulk of GPIO changes for the v4.16 kernel cycle. It is
pretty calm this time around I think. I even got time to get to things
like starting to clean up header includes.
Core changes:
- Disallow open drain and open source flags to be set simultaneously.
This doesn't make electrical sense, and would the hardware actually
respond to this setting, the result would be short circuit.
- ACPI GPIO has a new core infrastructure for handling quirks. The
quirks are there to deal with broken ACPI tables centrally instead
of pushing the work to individual drivers. In the world of BIOS
writers, the ACPI tables are perfect. Until they find a mistake in
it. When such a mistake is found, we can patch it with a quirk. It
should never happen, the problem is that it happens. So we
accomodate for it.
- Several documentation updates.
- Revert the patch setting up initial direction state from reading
the device. This was causing bad things for drivers that can't read
status on all its pins. It is only affecting debugfs information
quality.
- Label descriptors with the device name if no explicit label is
passed in.
- Pave the ground for transitioning SPI and regulators to use GPIO
descriptors by implementing some quirks in the device tree GPIO
parsing code.
New drivers:
- New driver for the Access PCIe IDIO 24 family.
Other:
- Major refactorings and improvements to the GPIO mockup driver used
for test and verification.
- Moved the AXP209 driver over to pin control since it gained a pin
control back-end. These patches will appear (with the same hashes)
in the pin control pull request as well.
- Convert the onewire GPIO driver w1-gpio to use descriptors. This is
merged here since the W1 maintainers send very few pull requests
and he ACKed it.
- Start to clean up driver headers using <linux/gpio.h> to just use
<linux/gpio/driver.h> as appropriate"
* tag 'gpio-v4.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (103 commits)
gpio: Timestamp events in hardirq handler
gpio: Fix kernel stack leak to userspace
gpio: Fix a documentation spelling mistake
gpio: Documentation update
gpiolib: remove redundant initialization of pointer desc
gpio: of: Fix NPE from OF flags
gpio: stmpe: Delete an unnecessary variable initialisation in stmpe_gpio_probe()
gpio: stmpe: Move an assignment in stmpe_gpio_probe()
gpio: stmpe: Improve a size determination in stmpe_gpio_probe()
gpio: stmpe: Use seq_putc() in stmpe_dbg_show()
gpio: No NULL owner
gpio: stmpe: i2c transfer are forbiden in atomic context
gpio: davinci: Include proper header
gpio: da905x: Include proper header
gpio: cs5535: Include proper header
gpio: crystalcove: Include proper header
gpio: bt8xx: Include proper header
gpio: bcm-kona: Include proper header
gpio: arizona: Include proper header
gpio: amd8111: Include proper header
...
We have been holding back on adding an API for fetching GPIO handles
directly from device nodes, strongly preferring to get it from the
spawn devices instead.
The fwnode interface however already contains an API for doing this,
as it is used for opaque device tree nodes or ACPI nodes for getting
handles to LEDs and keys that use GPIO: those are specified as one
child per LED/key in the device tree and are not individual devices.
However regulators present a special problem as they already have
helper functions to traverse the device tree from a regulator node
and two levels down to fill in data, and as it already traverses
GPIO nodes in its own way, and already holds a pointer to each
regulators device tree node, it makes most sense to export an
API to fetch the GPIO descriptor directly from the node.
We only support the devm_* version for now, hopefully no non-devres
version will be needed.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some pinctrl drivers can use the gpiochip irq valid information
to figure out if certain gpios are exposed to the kernel for
usage or not. Expose this API so we can use it in the
pinmux_ops::request ops.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
General support for state persistence is added to gpiolib with the
introduction of a new pinconf parameter to propagate the request to
hardware. The existing persistence support for sleep is adapted to
include hardware support if the GPIO driver provides it. Persistence
continues to be enabled by default; in-kernel consumers can opt out, but
userspace (currently) does not have a choice.
The *_SLEEP_MAY_LOSE_VALUE and *_SLEEP_MAINTAIN_VALUE symbols are
renamed, dropping the SLEEP prefix to reflect that the concept is no
longer sleep-specific. I feel that renaming to just *_MAY_LOSE_VALUE
could initially be misinterpreted, so I've further changed the symbols
to *_TRANSITORY and *_PERSISTENT to address this.
The sysfs interface is modified only to keep consistency with the
chardev interface in enforcing persistence for userspace exports.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull i2c updates from Wolfram Sang:
"This contains two bigger than usual tree-wide changes this time. They
all have proper acks, caused no merge conflicts in linux-next where
they have been for a while. They are namely:
- to-gpiod conversion of the i2c-gpio driver and its users (touching
arch/* and drivers/mfd/*)
- adding a sbs-manager based on I2C core updates to SMBus alerts
(touching drivers/power/*)
Other notable changes:
- i2c_boardinfo can now carry a dev_name to be used when the device
is created. This is because some devices in ACPI world need fixed
names to find the regulators.
- the designware driver got a long discussed overhaul of its PM
handling. img-scb and davinci got PM support, too.
- at24 driver has way better OF support. And it has a new maintainer.
Thanks Bartosz for stepping up!
The rest is regular driver updates and fixes"
* 'i2c/for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (55 commits)
ARM: sa1100: simpad: Correct I2C GPIO offsets
i2c: aspeed: Deassert reset in probe
eeprom: at24: Add OF device ID table
MAINTAINERS: new maintainer for AT24 driver
i2c: nuc900: remove platform_data, too
i2c: thunderx: Remove duplicate NULL check
i2c: taos-evm: Remove duplicate NULL check
i2c: Make i2c_unregister_device() NULL-aware
i2c: xgene-slimpro: Support v2
i2c: mpc: remove useless variable initialization
i2c: omap: Trigger bus recovery in lockup case
i2c: gpio: Add support for named gpios in DT
dt-bindings: i2c: i2c-gpio: Add support for named gpios
i2c: gpio: Local vars in probe
i2c: gpio: Augment all boardfiles to use open drain
i2c: gpio: Enforce open drain through gpiolib
gpio: Make it possible for consumers to enforce open drain
i2c: gpio: Convert to use descriptors
power: supply: sbs-message: fix some code style issues
power: supply: sbs-battery: remove unchecked return var
...
Pull GPIO updates from Linus Walleij:
"This is the bulk of GPIO changes for the v4.15 kernel cycle:
Core:
- Fix the semantics of raw GPIO to actually be raw. No inversion
semantics as before, but also no open draining, and allow the raw
operations to affect lines used for interrupts as the caller
supposedly knows what they are doing if they are getting the big
hammer.
- Rewrote the __inner_function() notation calls to names that make
more sense. I just find this kind of code disturbing.
- Drop the .irq_base() field from the gpiochip since now all IRQs are
mapped dynamically. This is nice.
- Support for .get_multiple() in the core driver API. This allows us
to read several GPIO lines with a single register read. This has
high value for some usecases: it can be used to create
oscilloscopes and signal analyzers and other things that rely on
reading several lines at exactly the same instant. Also a generally
nice optimization. This uses the new assign_bit() macro from the
bitops lib that was ACKed by Andrew Morton and is implemented for
two drivers, one of them being the generic MMIO driver so everyone
using that will be able to benefit from this.
- Do not allow requests of Open Drain and Open Source setting of a
GPIO line simultaneously. If the hardware actually supports
enabling both at the same time the electrical result would be
disastrous.
- A new interrupt chip core helper. This will be helpful to deal with
"banked" GPIOs, which means GPIO controllers with several logical
blocks of GPIO inside them. This is several gpiochips per device in
the device model, in contrast to the case when there is a 1-to-1
relationship between a device and a gpiochip.
New drivers:
- Maxim MAX3191x industrial serializer, a very interesting piece of
professional I/O hardware.
- Uniphier GPIO driver. This is the GPIO block from the recent
Socionext (ex Fujitsu and Panasonic) platform.
- Tegra 186 driver. This is based on the new banked GPIO
infrastructure.
Other improvements:
- Some documentation improvements.
- Wakeup support for the DesignWare DWAPB GPIO controller.
- Reset line support on the DesignWare DWAPB GPIO controller.
- Several non-critical bug fixes and improvements for the Broadcom
BRCMSTB driver.
- Misc non-critical bug fixes like exotic errorpaths, removal of dead
code etc.
- Explicit comments on fall-through switch() statements"
* tag 'gpio-v4.15-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (65 commits)
gpio: tegra186: Remove tegra186_gpio_lock_class
gpio: rcar: Add r8a77995 (R-Car D3) support
pinctrl: bcm2835: Fix some merge fallout
gpio: Fix undefined lock_dep_class
gpio: Automatically add lockdep keys
gpio: Introduce struct gpio_irq_chip.first
gpio: Disambiguate struct gpio_irq_chip.nested
gpio: Add Tegra186 support
gpio: Export gpiochip_irq_{map,unmap}()
gpio: Implement tighter IRQ chip integration
gpio: Move lock_key into struct gpio_irq_chip
gpio: Move irq_valid_mask into struct gpio_irq_chip
gpio: Move irq_nested into struct gpio_irq_chip
gpio: Move irq_chained_parent to struct gpio_irq_chip
gpio: Move irq_default_type to struct gpio_irq_chip
gpio: Move irq_handler to struct gpio_irq_chip
gpio: Move irqdomain into struct gpio_irq_chip
gpio: Move irqchip into struct gpio_irq_chip
gpio: Introduce struct gpio_irq_chip
pinctrl: armada-37xx: remove unused variable
...
In order to avoid lockdep boilerplate in individual drivers, turn the
gpiochip_add_data() function into a macro that creates a unique class
key for each driver.
Note that this has the slight disadvantage of adding a key for each
driver registered with the system. However, these keys are 8 bytes in
size, which is negligible and a small price to pay for generic
infrastructure.
Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
[renane __gpiochip_add_data() to gpiochip_add_data_with_key]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some GPIO chips cannot support sparse IRQ numbering and therefore need
to manually allocate their interrupt descriptors statically. For these
cases, a driver can pass the first allocated IRQ via the struct
gpio_irq_chip's "first" field and thereby cause the IRQ domain to map
all IRQs during initialization.
Suggested-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The nested field in struct gpio_irq_chip currently has two meanings. On
one hand it marks an IRQ chip as being nested (as opposed to chained),
while on the other hand it also means that an IRQ chip uses nested
thread handlers.
However, nested IRQ chips can already be identified by the fact that
they don't pass a parent handler (the driver would instead already have
installed a nested handler using request_irq()).
Therefore, the only use for the nested attribute is to inform gpiolib
that an IRQ chip uses nested thread handlers (as opposed to regular,
non-threaded handlers). To clarify its purpose, rename the field to
"threaded".
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently GPIO drivers are required to add the GPIO chip and its
corresponding IRQ chip separately, which can result in a lot of
boilerplate. Use the newly introduced struct gpio_irq_chip, embedded in
struct gpio_chip, that drivers can fill in if they want the GPIO core
to automatically register the IRQ chip associated with a GPIO chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In order to consolidate the multiple ways to associate an IRQ chip with
a GPIO chip, move more fields into the new struct gpio_irq_chip.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
