Commit 4d5b94cf65 ("BACKPORT: gpio / ACPI: Move event handling
registration to gpiolib irqchip helpers") moved the ACPI interrupt
request/free calls into the gpiolib helper functions,
gpiochip_irqchip_add() and acpi_gpiochip_remove(). The former function
is called by pinctrl-pistachio.c, so there is no need to call it from
acpi_gpiochip_request_interrupts() anymore. And in fact, since the
argument type changed from struct acpi_gpio_chip * to struct gpio_chip *,
the current code is incorrect:
drivers/gpio/gpiolib-acpi.c: In function 'acpi_gpiochip_add':
drivers/gpio/gpiolib-acpi.c:386:2: warning: passing argument 1 of 'acpi_gpiochip_request_interrupts' from incompatible pointer type
acpi_gpiochip_request_interrupts(acpi_gpio);
^
drivers/gpio/gpiolib-acpi.c:218:6: note: expected 'struct gpio_chip *' but argument is of type 'struct acpi_gpio_chip *'
void acpi_gpiochip_request_interrupts(struct gpio_chip *chip)
BUG=chrome-os-partner:30840
TEST=builds without warnings
Change-Id: I730ae9e3fd31d09edd84596554e4390ab4bb0a06
Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255246
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
There is possibility with misconfigured pins that interrupt occurs instantly
after setting irq_set_chained_handler() in gpiochip_set_chained_irqchip().
Now if handler gets called before irq_set_handler_data() the handler gets
NULL handler data.
Fix this by moving irq_set_handler_data() call before
irq_set_chained_handler() in gpiochip_set_chained_irqchip().
Cc: Stable <stable@vger.kernel.org> # 3.15+
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
(cherry picked from commit 324b039878)
[abrestic: resolved merge conflict as was done upstream]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I9adcff381bf164082776aa7aed81f34f24dc4e38
Reviewed-on: https://chromium-review.googlesource.com/238917
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
To unify how we connect cascaded IRQ chips to parent IRQs, if
NULL us passed as handler to the gpiochip_set_chained_irqchip()
function, assume the chips is nested rather than chained, and
we still get the parent set up correctly by way of this function
call.
Alter the drivers for tc3589x and stmpe to use this to set up
their chained handlers as a demonstration of the usage.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 3f97d5fcf9)
[abrestic: dropped updates to tc3589x and stmpe drivers]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I05efd00204fbedc977078ab03ba4c805f757a65b
Reviewed-on: https://chromium-review.googlesource.com/238916
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
There is no guarantee that VIRQs will be allocated sequentially
for gpio irqchip in gpiochip_irqchip_add().
Therefore, it's unsafe to dispose VIRQ in gpiochip_irqchip_remove()
basing on index relatively to stored irq_base value.
Hence, use irq_find_mapping for VIRQ finding in gpiochip_irqchip_remove()
instead of irq_base + index.
Reported-by: Wang, Yalin <Yalin.Wang@sonymobile.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit e3893386b9)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I26a59d615fb89e18c27ea412896a08981e9f8314
Reviewed-on: https://chromium-review.googlesource.com/238914
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Since now we have irqchip helpers that the GPIO chip drivers are supposed
to use if possible, we can move the registration of ACPI events to happen
in these helpers. This seems to be more natural place and might encourage
GPIO chip driver writers to take advantage of the irqchip helpers.
We make the functions available to GPIO chip drivers via private gpiolib.h,
just in case generic irqchip helpers are not suitable.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit afa82fab5e)
[abrestic: fixed conflict due to introduction of ACPI GPIO operating
regions upstream]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I12288d5bd8f4b4c69c086341695210bfe709265e
Reviewed-on: https://chromium-review.googlesource.com/238912
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
gpio_lock/unlock_as_irq() are working with (chip, offset) arguments and
are thus not using the old integer namespace. Therefore, there is no
reason to have gpiod variants of these functions working with
descriptors, especially since the (chip, offset) tuple is more suitable
to the users of these functions (GPIO drivers, whereas GPIO descriptors
are targeted at GPIO consumers).
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit d74be6dfea)
[abrestic: fixed conflicts due to split of gpiolib.c into separate
files upstream]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I91a0fe4a42c8b2d92c9879f8aa5993bcd8556767
Reviewed-on: https://chromium-review.googlesource.com/238911
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Another feature that is duplicated in a number of GPIO irqchips
is that these cascades IRQs are assigned their own lock class
so as to avoid warnings about lockdep recursions. Do this also
in the generic GPIO irqchip helpers for smooth transition to
this core infrastructure.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit e45d1c80c0)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I09edcb5ddc8f1b1f16a3230f71c8312a3a2bc2ee
Reviewed-on: https://chromium-review.googlesource.com/238905
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Some off-chip GPIO expanders need to be communicated by I2C or
SPI traffic, but may still support IRQs. By the sleeping nature
of such buses, such IRQ handlers need to be threaded. Support
such handlers in the gpiochip irqchip helpers by flagging IRQs
as threaded if the .can_sleep property of the gpiochip is
true.
Helpfully deny registration of chained IRQ handlers if the
.can_sleep property is set, as such chips will invariably need
a nested handler rather than a chained handler.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1c8732bb03)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I7d4e53c668470c9282054ddcfa825e43181246fb
Reviewed-on: https://chromium-review.googlesource.com/238904
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
During irq mapping, in irq_set_chip_and_handler() the process
of setting this up may incur calls to lock the irqchip, which
in turn may need to dereference and use the chip data. So set
the data first, then set the chip and handler.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 7633fb959b)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I57dd0f56a660eef091b95d286e5cd68d22d2d3c9
Reviewed-on: https://chromium-review.googlesource.com/238902
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
This provides a function gpiochip_irqchip_add() to set
up an irqchip for a GPIO controller, and a function
gpiochip_set_chained_irqchip() to chain it to a parent
irqchip.
Most GPIOs are of the type where a number of lines form
a cascaded interrupt controller chained onto
the primary system interrupt controller (or further down the
chain) so let's add this helper and factor the code to
request the lines to be used as IRQs, the .to_irq() function
and the irqdomain into the core as well.
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 1425052097)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I36ccc73610ccad29c2c7ee5a69746770223b0293
Reviewed-on: https://chromium-review.googlesource.com/238900
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
The current ACPI GPIO event handling code was never tested against real
hardware with functioning GPIO triggered events (at the time such hardware
wasn't available). Thus it misses certain things like requesting the GPIOs
properly, passing correct flags to the interrupt handler and so on.
This patch reworks ACPI GPIO event handling so that we:
1) Use struct acpi_gpio_event for all GPIO signaled events.
2) Switch to use GPIO descriptor API and request GPIOs by calling
gpiochip_request_own_desc() that we added in a previous patch.
3) Pass proper flags from ACPI GPIO resource to request_threaded_irq().
Also instead of open-coding the _AEI iteration loop we can use
acpi_walk_resources(). This simplifies the code a bit and fixes memory leak
that was caused by missing kfree() for buffer returned by
acpi_get_event_resources().
Since the remove path now calls gpiochip_free_own_desc() which takes GPIO
spinlock we need to call acpi_gpiochip_remove() outside of that lock
(analogous to acpi_gpiochip_add() path where the lock is released before
those funtions are called).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 6072b9dcf9)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: Ib9b42dc0f07a81c3ba9ba6dab374092aa7cbe916
Reviewed-on: https://chromium-review.googlesource.com/238839
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
We are going to add more ACPI specific data to accompany GPIO chip so
instead of allocating it per each use-case we allocate it once when
acpi_gpiochip_add() is called and release it when acpi_gpiochip_remove() is
called.
Doing this allows us to add more ACPI specific data by merely adding new
fields to struct acpi_gpio_chip.
In addition we embed evt_pins member directly to the structure instead of
having it as a pointer. This simplifies the code a bit since we don't need
to check against NULL.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit aa92b6f689)
[abrestic: fixed compile error from missing semicolon]
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I1e34126ada81ff3cf66d942e32fd8b7d52f39593
Reviewed-on: https://chromium-review.googlesource.com/238837
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Sometimes it is useful to allow GPIO chips themselves to request GPIOs they
own through gpiolib API. One use case is ACPI ASL code that should be able
to toggle GPIOs through GPIO operation regions.
We can't use gpio_request() because it will pin the module to the kernel
forever (it calls try_module_get()). To solve this we move module refcount
manipulation to gpiod_request() and let __gpiod_request() handle the actual
request. This changes the sequence a bit as now try_module_get() is called
outside of gpio_lock (I think this is safe, try_module_get() handles
serialization it needs already).
Then we provide gpiolib internal functions gpiochip_request/free_own_desc()
that do the same as gpio_request() but don't manipulate module refrence
count. This allows the GPIO chip driver to request and free descriptors it
owns without being pinned to the kernel forever.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit 77c2d7929d)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: I08296d1b7bc3a1d59234fd1ea6719bcc304b30d0
Reviewed-on: https://chromium-review.googlesource.com/238836
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Some drivers dealing with a gpio_chip might need to act on its
descriptors directly; one example is pinctrl drivers that need to lock a
GPIO for being used as IRQ using gpiod_lock_as_irq().
This patch exports a gpiochip_get_desc() function that returns the
GPIO descriptor at the requested index. It also sweeps the
gpio_to_chip() function out of the consumer interface since any holder
of a gpio_chip reference can manipulate its GPIOs way beyond what a
consumer should be allowed to do.
As a result, gpio_chip is not visible anymore to simple GPIO consumers.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit bb1e88ccb7)
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:30840
TEST=builds
Change-Id: Ie34b086797aa45efebc7c4eeffeb42f7b2ef9684
Reviewed-on: https://chromium-review.googlesource.com/238834
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
The documentation was not clear about whether
gpio_direction_output should take a logical value or the physical
level on the output line, i.e. whether the ACTIVE_LOW status
would be taken into account.
This converts gpiod_direction_output to use the logical level
and adds a new gpiod_direction_output_raw for the raw value.
BUG=chrome-os-partner:31528
TEST=gpio-restart changes do not reboot machine at boot
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
(cherry picked from commit ef70bbe1aa)
Signed-off-by: David Riley <davidriley@chromium.org>
Change-Id: Ib9c6eb77a2f8fbba9be00032a50fbef63c440d81
Reviewed-on: https://chromium-review.googlesource.com/214278
Reviewed-by: Olof Johansson <olofj@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Commit-Queue: David Riley <davidriley@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Anatol Pomazau <anatol@google.com>
These are used by upcoming devices and without it crossystem is
unable to read GPIO values on the chipset.
BUG=chrome-os-partner:11540,chrome-os-partner:11323
TEST=manual test on Parrot device
1) Verify that a GPIO can be exported and read:
> echo $(( 160 + 70 )) > /sys/class/gpio/export
> cat /sys/class/gpio/gpio$(( 160 + 70 ))/value
0
2) Verify that crossystem does not report any errors:
> crossystem | grep -c error
0
Change-Id: Iebdc2396bf401c6df6b7802cbd05832b53f0e0c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/28183
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
These PCI device IDs describe various variants of the Ivy Bridge
chipset South Bridge LPC device (00:1f.0), which includes the GPIO
controller.
BUG=none
TEST=manual
. with this fix the driver installs on the most recent hardware
where it was failing to install before
Change-Id: Iaff6c1f1bdc7ec977329b0693e672d302824fa58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/22517
Reviewed-by: Olof Johansson <olofj@chromium.org>
The order of operations in the driver remove method is wrong, which
prevents the driver from de-installing.
BUG=none
TEST=manual
. try 'rmmod nm10_gpio' and 'modprobe nm10_gpio' a few times in a
row, check the dmesg output to see that the driver installs and
removes cleanly
Change-Id: I7ab5161f224722f4f23fec97c99116184959a64e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19019
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Mandeep Singh Baines <msb@chromium.org>
The nm10 gpio driver is being modified to recognize the Panther Point
LPC device as one of valid GPIO controllers.
BUG=chrome-os-partner:8612
TEST=manual
. build the new kernel
. observe that the gpio driver gets installed:
localhost ~ # dmesg | grep gpio
[ 7.020200] nm10_gpio version 0.04 built on Mar 22 2012 at 20:47:08
[ 7.020220] gpiochip_find_base: found new base at 160
. enable the write protect GPIO (#57)
localhost ~ # echo 217 > /sys/class/gpio/export
. examine its value
localhost ~ # cat /sys/class/gpio/gpio217/value
0
. short the pins and examine the value again
localhost ~ # cat /sys/class/gpio/gpio217/value
1
. observe value change when the pins status changes
Change-Id: Idf354a64d5b964a37ee72b8e14fcedd3aab83654
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/18928
The Intel 6 Series chipset supports 96 GPIOs while NM10 supports 64.
Added support for 64 or 96 GPIOs based on device ID.
BUG=chrome-os-partner:5368
TEST=run crossystem and ensure that the current values of dev, recovery and
write protect switches are correctly reported.
Change-Id: I60f778117349766a82867db664765911e27bc9e2
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7004
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Adding more LPC device IDs of the Intel 6 Series and C200 Series
chipsets.
This has been tested and works on HM65 and HM67 variants.
BUG=none
TEST=run crossystem and ensure that the current values of recovery and
dev switches are correct
Change-Id: I895fca9bd5c23caeb2b4a3b06bbb20bc46d8691a
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5682
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The GPIO access mechanism on the HM65 PCH is the same a NM10. Simply
adding the device ID of HM65 to this driver instead of writing a new
driver that essentially does the same thing.
BUG=chrome-os-partner:4977
TEST=crossystem should report the correct values of recoverysw_cur and
devsw_cur with this driver in place,
Change-Id: I5bb0082b77dc4dec8739f9e24d92be485e3f28ae
Signed-off-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/4272
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
gpio-tb10x driver uses generic irq chip APIs (irq_alloc_domain_generic_chips,
irq_remove_generic_chip), so it needs to select GENERIC_IRQ_CHIP to avoid build
error.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
commit 55fe14ab87 "GPIO: clps711x: Rewrite driver for using generic GPIO code"
allows this driver to be built as a module.
Thus add module alias to support module auto loading.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
In xtensa coprocessors may exist without coprocessor context, i.e. they cannot
be disabled/enabled. In this case the RSR_CPENABLE/WSR_CPENABLE are undefined,
thus breaking the build. Fix the build by adding dummy versions of
enable_cp/disable_cp in this case.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull ARM driver updates from Olof Johansson:
"Updates of SoC-near drivers and other driver updates that makes more
sense to take through our tree.
The largest part of this is a conversion of device registration for
some renesas shmobile/sh devices over to use resources. This has
required coordination with the corresponding arch/sh changes, and
we've agreed to merge the arch/sh changes through our tree.
Added in this branch is support for Trusted Foundations secure
firmware, which is what is used on many of the commercial Nvidia Tegra
products that are in the market, including the Nvidia Shield. The
code is local to arch/arm at this time since it's uncertain whether it
will be shared with arm64 longer-term, if needed we will refactor
later.
A couple of new RTC drivers used on ARM boards, merged through our
tree on request by the RTC maintainer.
... plus a bunch of smaller updates across the board, gpio conversions
for davinci, etc"
* tag 'drivers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (45 commits)
watchdog: davinci: rename platform driver to davinci-wdt
tty: serial: Limit msm_serial_hs driver to platforms that use it
mmc: msm_sdcc: Limit driver to platforms that use it
usb: phy: msm: Move mach dependent code to platform data
clk: versatile: fixup IM-PD1 clock implementation
clk: versatile: pass a name to ICST clock provider
ARM: integrator: pass parent IRQ to the SIC
irqchip: versatile FPGA: support cascaded interrupts from DT
gpio: davinci: don't create irq_domain in case of unbanked irqs
gpio: davinci: use chained_irq_enter/chained_irq_exit API
gpio: davinci: add OF support
gpio: davinci: remove unused variable intc_irq_num
gpio: davinci: convert to use irqdomain support.
gpio: introduce GPIO_DAVINCI kconfig option
gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
serial: sh-sci: Add OF support
serial: sh-sci: Add device tree bindings documentation
serial: sh-sci: Remove platform data mapbase and irqs fields
serial: sh-sci: Remove platform data scbrr_algo_id field
...
Pull MFD changes from Lee Jones:
"New drivers
- Samsung Maxim 14577; Micro USB, Regulator, IRQ Controller and
Battery Charger
- TI/National Semiconductor LP3943 I2C GPIO Expander and PWM
Generator
Existing driver adaptions
- Expansion of Wolfson Arizona DSP and High-Pass filter controls
- TI TWL6040 default Regmap support and Regcache addition/bypass
- Some nice Smatch catch fixes
- Conversion of TI OMAP-USB and TI TWL6030 to endian neutralness
- ChromeOS EC timing (delay) adaptions and added dependency on OF
- Many constifications of 'struct {mfd_cell,regmap_irq,et.al}'
- Watchdog support added for NVIDIA AS3722
- Convert functions to static in TI AM335x
- Realigned previously defeated functionality in TI AM335x
- IIO ADC-TSC concurrency dead-lock/timeout resolution
- Addition of Power Management and Clock support for Samsung core
- DEFINE_PCI_DEVICE_TABLE macro removal from MFD Subsystem
- Greater use of irqdomain functionality in ST-E AB8500
- Removal of 'include/linux/mfd/abx500/ab8500-gpio.h'
- Wolfson WM831x PMIC Power Management changes s/poweroff/shutdown/
- Device Tree documentation added for TI/Nat Semi LP3943
- Version detection and voltage tables for TI TPS6586x PMIC devices
- Simplification of Freescale MC13XXX (de-)initialisation routines
- Clean-up and simplification of the Realtek parent driver
- Added support for RTL8402 Realtek PCI-Express card reader
- Resource leak fix for Maxim 77686
- Possible suspend BUG() fix in OMAP USB TLL
- Support for new Wolfson WM5110 Revision (D)
- Testing of automatic assignment of of_node in mfd_add_device()
- Reversion of the above when it started to cause issues
- Remove legacy Platform Data from;
TI TWL Core, Qualcomm SSBI and ST-E ABx500 Pinctrl
- Clean-ups; tabbing issues, function name changes, 'drvdata = NULL'
removal, unused uninitialised warning mitigation, error
message clarity, removal of redundant/duplicate checks,
licensing (GPL -> GPL2), coding consistency, duplicate
function declaration, ret checks, commit corrections,
redundant of_match_ptr() helper removal, spelling,
#if-deffery removal and header guards name changes"
* tag 'mfd-3.14-1' of git://git.linaro.org/people/ljones/mfd: (78 commits)
mfd: wm5110: Add register patch for rev D chip
mfd: omap-usb-tll: Don't hold lock during pm_runtime_get/put_sync()
gpio: lp3943: Remove redundant of_match_ptr helper
mfd: sta2x11-mfd: Use named constants for pci_power_t values
Documentation: mfd: Fix LDO index in s2mps11.txt
mfd: Cleanup mfd-mcp-sa11x0.h header
mfd: max8997: Use "IS_ENABLED(CONFIG_OF)" for DT code.
mfd: twl6030: Fix endianness problem in IRQ handler
mfd: sec-core: Add cells for S5M8767-clocks
mfd: max14577: Remove redundant of_match_ptr helper
mfd: twl6040: Fix sparse non static symbol warning
mfd: Revert "mfd: Always assign of_node in mfd_add_device()"
mfd: rtsx: Fix sparse non static symbol warning
mfd: max77693: Set proper maximum register for MUIC regmap
mfd: max77686: Fix regmap resource leak on driver remove
mfd: Represent correct filenames in file headers
mfd: rtsx: Add support for card reader rtl8402
mfd: rtsx: Add set pull control macro and simplify rtl8411
mfd: max8997: Enforce mfd_add_devices() return value check
mfd: mc13xxx: Simplify probe() & remove()
...
Pull GPIO tree bulk changes from Linus Walleij:
"A big set this merge window, as we have much going on in this
subsystem. The changes to other subsystems (notably a slew of ARM
machines as I am doing away with their custom APIs) have all been
ACKed to the extent possible.
Major changes this time:
- Some core improvements and cleanups to the new GPIO descriptor API.
This seems to be working now so we can start the exodus to this
API, moving gradually away from the global GPIO numberspace.
- Incremental improvements to the ACPI GPIO core, and move the few
GPIO ACPI clients we have to the GPIO descriptor API right *now*
before we go any further. We actually managed to contain this
*before* we started to litter the kernel with yet another hackish
global numberspace for the ACPI GPIOs, which is a big win.
- The RFkill GPIO driver and all platforms using it have been
migrated to use the GPIO descriptors rather than fixed number
assignments. Tegra machine has been migrated as part of this.
- New drivers for MOXA ART, Xtensa GPIO32 and SMSC SCH311x. Those
should be really good examples of how I expect a nice GPIO driver
to look these days.
- Do away with custom GPIO implementations on a major part of the ARM
machines: ks8695, lpc32xx, mv78xx0. Make a first step towards the
same in the horribly convoluted Samsung S3C include forest. We
expect to continue to clean this up as we move forward.
- Flag GPIO lines used for IRQ on adnp, bcm-kona, em, intel-mid and
lynxpoint.
This makes the GPIOlib core aware that a certain GPIO line is used
for IRQs and can then enforce some semantics such as disallowing a
GPIO line marked as in use for IRQ to be switched to output mode.
- Drop all use of irq_set_chip_and_handler_name(). The name provided
in these cases were just unhelpful tags like "mux" or "demux".
- Extend the MCP23s08 driver to handle interrupts.
- Minor incremental improvements for rcar, lynxpoint, em 74x164 and
msm drivers.
- Some non-urgent bug fixes here and there, duplicate #includes and
that usual kind of cleanups"
Fix up broken Kconfig file manually to make this all compile.
* tag 'gpio-v3.14-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio: (71 commits)
gpio: mcp23s08: fix casting caused build warning
gpio: mcp23s08: depend on OF_GPIO
gpio: mcp23s08: Add irq functionality for i2c chips
ARM: S5P[v210|c100|64x0]: Fix build error
gpio: pxa: clamp gpio get value to [0,1]
ARM: s3c24xx: explicit dependency on <plat/gpio-cfg.h>
ARM: S3C[24|64]xx: move includes back under <mach/> scope
Documentation / ACPI: update to GPIO descriptor API
gpio / ACPI: get rid of acpi_gpio.h
gpio / ACPI: register to ACPI events automatically
mmc: sdhci-acpi: convert to use GPIO descriptor API
ARM: s3c24xx: fix build error
gpio: f7188x: set can_sleep attribute
gpio: samsung: Update documentation
gpio: samsung: Remove hardware.h inclusion
gpio: xtensa: depend on HAVE_XTENSA_GPIO32
gpio: clps711x: Enable driver compilation with COMPILE_TEST
gpio: clps711x: Use of_match_ptr()
net: rfkill: gpio: convert to descriptor-based GPIO interface
leds: s3c24xx: Fix build failure
...
This is one of LP3943 MFD driver.
LP3943 is configurable as a GPIO expander, up to 16 GPIOs.
* Application note: how to configure LP3943 as a GPIO expander
http://www.ti.com/lit/an/snva287a/snva287a.pdf
* Supported GPIO controller operations
request, free, direction_input, direction_output, get and set
* GPIO direction register not supported
LP3943 doesn't have the GPIO direction register. It only provides input and
output status registers.
So, private data for the direction should be handled manually.
This variable is updated whenever the direction is changed and
used in 'get' operation.
* Pin assignment
A driver data, 'pin_used' is checked when a GPIO is requested.
If the GPIO is already assigned, then returns as failure.
If the GPIO is available, 'pin_used' is set.
When the GPIO is not used anymore, then it is cleared.
It is defined as unsigned long type for atomic bit operation APIs,
but only LSB 16bits are used because LP3943 has 16 outputs.
Signed-off-by: Milo Kim <milo.kim@ti.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The MCP drivers fails to compile on trial builds due to missing
Kconfig dependency on OF_GPIO. Fix it.
Cc: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This adds interrupt functionality for i2c chips to the driver.
They can act as a interrupt-controller and generate interrupts, if
the inputs change.
This is tested with a mcp23017 chip on an arm based platform.
v3:
- be a bit more clear that the irq functionality is also available
on spi versions of the chips, but the linux driver does not support
this yet
v2:
- some more word about irq-mirror property in binding doc
- use of_read_bool instead of of_find_property for
"interrupt-contrller" and "irq-mirror"
- cache the "interrupt-controller" for remove function
- do set the irq-mirror bit only if device is marked as
interrupt-controller
- do create the irq mapping and setup of irq_desc of all possible
interrupts in probe path instead of in gpio_to_irq
- mark gpios as in use as interrupts in irq in irq_startup and
unlock it in irq_shutdown
- rename virq to child_irq
- remove dev argument from mcp23s08_irq_setup function
- move gpiochip_add before mcp23s08_irq_setup in probe path
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
gpio-samsung.h header file introduced by commit 93177be0910c
("ARM: S3C[24|64]xx: move includes back under <mach/> scope")
is required only by S3C[24|64]xx machines. Include them conditionally
to avoid the following build errors for other machine configurations.
drivers/gpio/gpio-samsung.c:35:31: fatal error: mach/gpio-samsung.h: No such file or directory
arch/arm/plat-samsung/pm-gpio.c:22:31: fatal error: mach/gpio-samsung.h: No such file or directory
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
