commit 2f97c20e5f7c3582c7310f65a04465bfb0fd0e85 upstream.
The gpio_chip operations receive a pointer the gpio_chip struct which is
contained in the driver's private struct, yet the container_of call in those
functions point to the mfd struct defined in include/linux/mfd/tps65912.h.
Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 49d2ca84e433dab854c7a866bc6add09cfab682d upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when setting the
gpio-line polarity.
Fixes: 0769746183 ("gpiolib: add support for changing value polarity
in sysfs")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 0f303db08df0df9bd0966443ad6001e63960af16 upstream.
Fix memory leak in the gpio sysfs interface due to failure to drop
reference to device returned by class_find_device when creating a link.
Fixes: a4177ee7f1 ("gpiolib: allow exported GPIO nodes to be named
using sysfs links")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit ebbeba120ab2ec6ac5f3afc1425ec6ff0b77ad6f upstream.
Fix attribute-creation race with userspace by using the default group
to create also the contingent gpio device attributes.
Fixes: d8f388d8dc ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf:
- adjust filename
- call gpio_to_irq() instead of gpiod_to_irq]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.
The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).
Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.
Remove contingent attributes in export error path and on unexport.
Fixes: d8f388d8dc ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf: Backported to 3.4:
- adjust filename
- adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit fc4e251499 upstream.
The gpio_export function uses nested if statements and the status
variable to handle the failure cases. This makes the function logic
difficult to follow. Refactor the code to abort immediately on failure
using goto. This makes the code slightly longer, but significantly
reduces the nesting and number of split lines and makes the code easier
to read.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.
The gpio-chip device attributes were never destroyed when the device was
removed.
Fix by using device_create_with_groups() to create the device attributes
of the chip class device.
Note that this also fixes the attribute-creation race with userspace.
Fixes: d8f388d8dc ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf: Backported to 3.4: adjust filename]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 5539b3c938d64a60cb1fc442ac3ce9263d52de0c upstream.
Memory allocated and references taken by of_gpiochip_add and
acpi_gpiochip_add were never released on errors in gpiochip_add (e.g.
failure to find free gpio range).
Fixes: 391c970c0d ("of/gpio: add default of_xlate function if device
has a node pointer")
Fixes: 664e3e5ac6 ("gpio / ACPI: register to ACPI events
automatically")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[lizf: Backported to 3.4:
- move the call to of_gpiochip_add() into the above if condition.
- remove the call to acpi_gpiochip_remove()]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit a585f87c86 upstream.
The scenario here is that someone calls enable_irq_wake() from somewhere
in the code. This will result in the lockdep producing a backtrace as can
be seen below. In my case, this problem is triggered when using the wl1271
(TI WlCore) driver found in drivers/net/wireless/ti/ .
The problem cause is rather obvious from the backtrace, but let's outline
the dependency. enable_irq_wake() grabs the IRQ buslock in irq_set_irq_wake(),
which in turns calls mxs_gpio_set_wake_irq() . But mxs_gpio_set_wake_irq()
calls enable_irq_wake() again on the one-level-higher IRQ , thus it tries to
grab the IRQ buslock again in irq_set_irq_wake() . Because the spinlock in
irq_set_irq_wake()->irq_get_desc_buslock()->__irq_get_desc_lock() is not
marked as recursive, lockdep will spew the stuff below.
We know we can safely re-enter the lock, so use IRQ_GC_INIT_NESTED_LOCK to
fix the spew.
=============================================
[ INFO: possible recursive locking detected ]
3.10.33-00012-gf06b763-dirty #61 Not tainted
---------------------------------------------
kworker/0:1/18 is trying to acquire lock:
(&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
but task is already holding lock:
(&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&irq_desc_lock_class);
lock(&irq_desc_lock_class);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/0:1/18:
#0: (events){.+.+.+}, at: [<c0036308>] process_one_work+0x134/0x4a4
#1: ((&fw_work->work)){+.+.+.}, at: [<c0036308>] process_one_work+0x134/0x4a4
#2: (&irq_desc_lock_class){-.-...}, at: [<c00685f0>] __irq_get_desc_lock+0x48/0x88
stack backtrace:
CPU: 0 PID: 18 Comm: kworker/0:1 Not tainted 3.10.33-00012-gf06b763-dirty #61
Workqueue: events request_firmware_work_func
[<c0013eb4>] (unwind_backtrace+0x0/0xf0) from [<c0011c74>] (show_stack+0x10/0x14)
[<c0011c74>] (show_stack+0x10/0x14) from [<c005bb08>] (__lock_acquire+0x140c/0x1a64)
[<c005bb08>] (__lock_acquire+0x140c/0x1a64) from [<c005c6a8>] (lock_acquire+0x9c/0x104)
[<c005c6a8>] (lock_acquire+0x9c/0x104) from [<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58)
[<c051d5a4>] (_raw_spin_lock_irqsave+0x44/0x58) from [<c00685f0>] (__irq_get_desc_lock+0x48/0x88)
[<c00685f0>] (__irq_get_desc_lock+0x48/0x88) from [<c0068e78>] (irq_set_irq_wake+0x20/0xf4)
[<c0068e78>] (irq_set_irq_wake+0x20/0xf4) from [<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24)
[<c027260c>] (mxs_gpio_set_wake_irq+0x1c/0x24) from [<c0068cf4>] (set_irq_wake_real+0x30/0x44)
[<c0068cf4>] (set_irq_wake_real+0x30/0x44) from [<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4)
[<c0068ee4>] (irq_set_irq_wake+0x8c/0xf4) from [<c0310748>] (wlcore_nvs_cb+0x10c/0x97c)
[<c0310748>] (wlcore_nvs_cb+0x10c/0x97c) from [<c02be5e8>] (request_firmware_work_func+0x38/0x58)
[<c02be5e8>] (request_firmware_work_func+0x38/0x58) from [<c0036394>] (process_one_work+0x1c0/0x4a4)
[<c0036394>] (process_one_work+0x1c0/0x4a4) from [<c0036a4c>] (worker_thread+0x138/0x394)
[<c0036a4c>] (worker_thread+0x138/0x394) from [<c003cb74>] (kthread+0xa4/0xb0)
[<c003cb74>] (kthread+0xa4/0xb0) from [<c000ee00>] (ret_from_fork+0x14/0x34)
wlcore: loaded
Signed-off-by: Marek Vasut <marex@denx.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4cc629b7a2 upstream.
We should be writing bits here but instead we're writing the
numbers that correspond to the bits we want to write. Fix it by
wrapping the numbers in the BIT() macro. This fixes gpios acting
as interrupts.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1aeef303b5 upstream.
For MPC8572/MPC8536, the status of GPIOs defined as output
cannot be determined by reading GPDAT register, so the code
use shadow data register instead. But the code may give the
wrong status of GPIOs defined as input under some scenarios:
1. If some pins were configured as inputs and were asserted
high before booting the kernel, the shadow data has been
initialized with those pin values.
2. Some pins have been configured as output first and have
been set to the high value, then reconfigured as input.
The above cases will make the shadow data for those input
pins to be set to high. Then reading the pin status will
always return high even if the actual pin status is low.
The code should eliminate the effects of the shadow data to
the input pins, and the status of those pins should be
read directly from GPDAT.
Acked-by: Scott Wood <scottwood@freescale.com>
Acked-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
msm_gpio_update_dual_edge_pos() function will set correct
trigger type based on the current gpio level in case that
the interrupt type is both edge trigger type (IRQF_TRIGGER_RISING
|IRQF_TRIGGER_FALLING). Later again we set the msm_gpio_irq_extn
set_type with mpm to set it as IRQF_TRIGGER_RISING.
Avoid configuring the type with mpm if it is dual edge trigger.
CRs-Fixed: 421325
Change-Id: I049362e7f7eacdeab13d4c6b190262c015419efd
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Use the new license header with The Linux Foundation instead of CAF.
Change-Id: I73afbaf73ba47a7adf2b45f7f2c02fde330d2344
Signed-off-by: Willie Ruan <wruan@codeaurora.org>
Remove the parameter checks in pm_gpio_get and pm_gpio_set
callbacks because they are not necessary as callbacks of gpiolib.
This also removes an issue of NULL pointer check is after being
dereferenced.
Change-Id: Iaca83877fe93ba6335d40c9a36465f909aef2c97
Signed-off-by: Willie Ruan <wruan@codeaurora.org>
In revision 1 of the gpio block, the GPIO_STATUS1 GPIO_OK changes
from bit 1 to bit 7. Update the code to reflect this.
Also verify that PMIC pins have valid types and subtypes upon
probe. This allows us to make assumptions about correctness later
on when checking for capabilities of a pin in question.
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
(cherry picked from commit bfe64c7551275d24cb8eb45ff0b578427d68c2e0)
Change-Id: Idc7464799ff354b83c82e38004aa299356551630
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
If a gpio interrupt is already enabled, do not re-enable it again and do not
clear the interrupt status.
Before this patch: if an edge interrupt is marked as wakeup, the gpio sys
suspend will enable it. On resume, the gpio sys resume would clear the
intr_status of the wakeup irq. Thus, if this particular wakeup irq triggered
and woke us up, we would lose its intr_status before calling the gpio summary
handler. Now, when the summary handler is finally called, the irq handler for
the wakeup interrupt is never called.
With this change: we are *not* re-enabling the gpio-irq again to make sure that
when the irq framework unmasks all irqs on resume, it does not clear the
intr_status.
Change-Id: Ia5a9c6b00173a56b1abbdd4d4821becb7311d7f6
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Ajay Dudani <adudani@codeaurora.org>
Signed-off-by: Iliyan Malchev <malchev@google.com>
When gpios are set to input, we return the input buffer status
from the STATUS1 register when the 'get' gpiochip callback is
invoked. This register also includes a bit that indicates whether
the pin is enabled.
Check to verify the pin is enabled, and if it is then return the
properly masked 1-bit value. Otherwise return an error, since the
API is not valid in this state.
Change-Id: I715e17f076d0dbd67397812f98e308f863c59b7c
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
-fix address value updates when writing to register blocks
greater than 8 bytes.
-fix an invalid shift value being passed in for the 'invert' parameter.
-fix invalid use of MODE_CTL macros
-cleanup the control register read / write routines to
remove unused parameters.
Change-Id: I42223f30a8c6490370d9a8006ee13e028fe774e6
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
According to the TLMM_v3 hardware spec the INTR_POL_CTL bit
is to be set:
Low for level low interrupts;
High for level high interrupts;
High for all edge interrupts.
Make sure the software configures it as desired.
Change-Id: I3369def7bd00e427c7dfe109bcdd4b6e207ad239
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The reset state for the INTR_CFG register is 0xE2. We need
the upper nibble to specify the target processor for the
gpio interrupt (Value 0x4 for APPS). But we were ORing
0x4 with 0xE still keeps it as 0xE. Get rid of the
incorrect read, modify, write cycle. Make sure the
reset state is wiped off before setting the interrupt
configuration bits.
Change-Id: I3deee9fcebe9eec78f89635313c5f3d0923fede5
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The subtypes defined in the documentation have changed again.
Update both GPIO and MPP subtype values in the qpnp-pin driver to
reflect this.
Change-Id: I22e22414a74d724259706c927582d1573dc58875
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
GPIOs has only three modes where as MPP has seven. Change the
constraint check to check for the appropriate value based on the
pin type.
Change-Id: I53c85b4a5e852ef3b9d5dbe939a496053fa26197
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Print the reason why a parameter constraint check failed to
improve debug capability.
Change-Id: Icd4a6457592bb4a73df61431dfcff63358bd7064
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
With TLMM-V3, the GPIO_INTR_STATUS register now requires
us to write 0 to clear the interrupt status. Earlier TLMM
versions required us to write 1 to clear the interrupt status.
Change-Id: Ic96ab6f3850fd4ac1164761c8f71c88e57fd4de5
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The documentation followed to enumerate the subtype values was
found to differ from the actual implementation in hardware.
Update to the values actually found in the hardware.
Change-Id: I3a6d3027593bfb043b87d9c072c882981c649a6e
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
The gpio driver was not a true platform driver and hence wasn't
supported by device tree. This patch fixes that for non-DT targets
by making sure the device gets added early on during board init.
For DT-targets, adding the gpio-controller property for the device
makes sure the msmgpio device gets probed.
This change is done for all TLMM_v2 targets (msm8660 and future)
TLMM_V1 targets remain unaffected.
Change-Id: I8a55ab1e2af0366b3e6893b334ba2396d2a83190
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
After the change to keep the RAW_STATUS_EN always on, the
interrupt status bit was latched and could be set during
other (non-interrupt) activity on the GPIO line. This would
end up triggering the interrupt as soon as it was unmasked.
Hence, clear the interrupt status before unmasking the gpio
interrupt. This keeps the behavior and expectations same as
when the RAW_STATUS_EN was toggled and it prevented the
interrupt status to be updated while the interrupt was masked.
Change-Id: I3ccb31b5d8a7efe93f8253d4aff4a1c44281163f
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Move enabling the RAW_STATUS_EN at the very beginning.
Hardware team clarified that it is better to write to
RAW_STATUS_EN before writing to any other INTR_CFG bits
in order to prevent spurious interrupts.
Removing writing to the GPIO_INTR_CFG_SU register for
gpio-v2 and remove modifying any other bits except
INTR_ENABLE in mask/unmask calls as it could cause spurious
interrupts as well.
Change-Id: Ia025b324ee3be8073960eac73899f733336cac4c
CRs-Fixed: 346861
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
The current code sets up irq attributes at postcore_init. But
with irqdomains, irqs are mapped later at runtime. Thus we need
to set these parameters within the irqdomain map routine for
systems that are using Device Tree.
Change-Id: I185ebc4efdb194d690ecbec75171709bd09e0588
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
TLMM v3 version has dedicated pads for only SDC1
and SDC2 among all SDC slots as opposed to v2 version.
Change-Id: I73c54f0a2799e6ffca74e5b846ac8339d0af3bb8
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
The official name for copper is MSM8974.
Switch to it.
Change-Id: Ifb241232111139912477bf7b5f2e9cf5d38d0f9e
Signed-off-by: Abhimanyu Kapur <abhimany@codeaurora.org>
Add mpp support to the qpnp-pin driver. MPP support allows for
additional devices to be specified in the Device Tree topology.
This support is implemented in the same driver as the GPIO
support since the address map is very close between them.
The addition of this support does not change the existing gpio
support.
Default MPP configuration can be specified in the Device Tree
using the three new bindings for mpp. Any attribute not specified
in the Device Tree will assume its default configuration.
It's also possible to configure an MPP at runtime using the
existing qpnp_pin_config() API. If a given configuration feature
is not supported by the underlying hardware pin, then that
particular request is silently dropped with no error. This allows
for gpio users to continue specifying only a subset of the full
qpnp_pin_cfg structure.
Change-Id: I2b72768647de2a371edfa05c52fc1ed776c215c0
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
There are two types of failures given a config parameter and a
requested value. The first type occurs due to a requested
configuration not being supported by the harware. The second case
happens when there is ample hardware support, but the
configuration value requested is out of spec.
Change the behavior so that a failure due to a lack of hardware
support does *not* trigger an error in either the probe of
default pin configuration, or the qpnp_pin_config() API.
The main motivation here is so that the pin configuration can be
extended to support mpp in addition to gpio. Users should be able
to only specify parameters for configuration items they care
about. For example, it would not be reasonable for a gpio pin to
receive configuration specification for mpp parameters. Given
that there's only one data structure in this scenario, this
cannot allow the config request to fail.
This change also has the added benefit of restructuring the code
so that there is no duplicated checks for the same error
conditions in the driver.
Change-Id: I88776b304b25cf4bb0a49ff305b398209aaade2a
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
qpnp-gpio manages gpio_chip queries based on the slave
ID. This has a limitation in that it restricts the number of
gpio_chips per slave ID to one. However, some PMICs have both MPP
and GPIO on the same slave, and thus the slave ID is not a
meaningful unit to search for.
Instead, make use of the 'label' binding to give the
primary dev-container node a name. This name will serve as the
gpio_chip label, which can be used in lookups.
Change-Id: Ic20caeb4622d73449a983992275446c733ddd89a
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Since QPNP PMICs also include support for MPP, and since we
intend to support MPPs in the same code base, it's not
appropriate to limit this the scope of this driver to 'gpio'.
Change the driver name to 'pin' since it more accurately
describes the potential for this driver.
Also update the Device Tree include files for the name changes.
Remove a superflous 'gpio-pin' definition in the msmcopper
specific include file, since such configuration shall never
change. This binding should be defined in the PMIC specific
include only.
Change-Id: Id1d6407039908e3cf44dfc19af71f0cdc7aff8e6
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Pointers are more flexible than index numbers, since index
numbers depend upon an additional reference to the array in
question. In particular, we'd like to add a new API to lookup a
devnode based on a predefined name in the Device Tree. This API
will return a spmi_resource, and so it's natural to want to use
this pointer directly with the other existing APIs.
Also introduce a new API spmi_for_each_devnode that can be used
to iterate each spmi_resource in the dev_node array. This
abstracts the traversal of the array, which was previously done
within the existing APIs.
Change-Id: I18f9397e5d78770e840a9f95dd8061201931df6e
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
It turns out that the only use cases for the qpnp library use
the existing spmi data structures. As such, there's really
no justification for having the library not be called 'spmi'.
There is nothing Qualcomm specific about this code.
Also cleanup some inconsistencies in the Kernel Doc comments
while we're here.
Change-Id: I1c73c88be740b6f5d38ba2de62de1737981b30fa
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
The following merge commit chose the irq_domain implementation
from AU_LINUX_ANDROID_ICS.04.00.04.00.126 instead of the version
in v3.4.
commit f132c6cf77251e011e1dad0ec88c0b1fda16d5aa
Merge: 23016de 3f6240f
Author: Steve Muckle <smuckle@codeaurora.org>
Date: Wed Jun 6 18:30:57 2012 -0700
Merge commit 'AU_LINUX_ANDROID_ICS.04.00.04.00.126' into
msm-3.4
Since this version is inconsistent with the upstream,
port the irq_domain framework to the version in v3.4 and
makes all necessary changes to clients that are out of spec.
Details of client ports are below.
-Update the qpnp-int driver for revmap irq_domain API. The revmap
irq_domain implementation introduces a reverse lookup scheme using
a radix tree. This scheme is useful for controllers like qpnp-int
that require a large range of hwirqs.
-Bring the ARM GIC driver up to v3.4, being careful
to port existing CAF changes.
-Partially port the gpio-msm-common driver to the new irq_domain API.
Enable the gpio-msm-common driver to work with the new irq_domain
API using a linear revmap. It is not a full port since irq_domain
is still only registered for Device Tree configurations. It should
be registered even for legacy configurations.
In addition, the irq_domains .map function should be setting all
the fields currently done in msm_gpio_probe(). That's not
currently possible since msm_gpio_probe is invoked
unconditionally - even from Device Tree configurations.
Finally, gpio-msm-common should be converted into a real
platform_device so that probe() is invoked due to driver and
device matching.
Change-Id: I19fa50171bd244759fb6076e3cddc70896d8727b
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
To unmask a gpio interrupt, the gpio driver sets the
INTR_RAW_STATUS_EN and INTR_ENABLE bits in the INTR_CFG register.
As soon as the INTR_RAW_STATUS_EN is set, the INTR_STATUS is updated
and this causes a spurious interrupt when the irq is enabled.
This is noticed frequently when the gpio is pulled high and requests
a rising edge interrupt or pulled low and is requesting a falling edge
interrupt.
Due the internal circuit design of the TLMM IRQ block, the above method
causes a spurious interrupt when the irq was initialized.
Hence, to avoid this behavior we set the INTR_RAW_STATUS_EN, clear the
INTR_STATUS only once during setup. Every mask and unmask only toggles
the INTR_ENABLE bit.
CRs-Fixed: 346861
Change-Id: I1c9852ed91432582c3d050ccf933053fd368b216
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Update the gpio_xlate callback due to prototype changes
introduced by this change:
commit 15c9a0acc3
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Mon Dec 12 09:25:57 2011 -0700
of: create of_phandle_args to simplify return of phandle
parsing data
Change-Id: I9d6aa57d32388aa21c1a621bf49a7f78769ae06d
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Add a gpio_chip driver to support the Qualcomm SPMI PMIC
architecture called QPNP. The driver supports Device Tree
and allows a device_node to be registered as a gpio-controller.
The driver also specifies APIs to allow a non-Device Tree user
the ability to configure the PMIC GPIOs.
This driver does not handle interrupts for GPIOs directly.
Instead, that work is handled by the existing qpnp-int driver.
This is feasible since the interrupt register map for all
QPNP peripherals is the same.
Change-Id: I04eb39d9855b0957f0647010fcb203ec2fc83c7c
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
In the process we replace the upstream versions of the file with
our own and introduce gpio-msm-v3.c and gpio-msm-common.c.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add support for multi-purpose pins (MPPs) on Qualcomm PM8xxx
PMIC chips.
PM8xxx MPPs can be configured as digital or analog inputs or
outputs, current sinks, or buffers.
Note that mpp pins appear as gpio lines to the kernel. However they
are implemented separately from the pmic's gpio driver as
mpps have different configuration attributes and have different
register controls than the pmic's gpio controller. Basically they are
different set of pins.
Change-Id: Iab39b2f7c2ba3f35ef6ac74d37ee7add8c70681f
Signed-off-by: David Collins <collinsd@codeaurora.org>
Add support for GPIO on Qualcomm PM8xxx PMIC chips.
Change-Id: I5c00baeedc6c40ed40065d15c83577051e6ac9c6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
commit ad2fab36d7 upstream.
gpios requested with invalid numbers, or gpios requested from userspace via sysfs
should not try to be deferred on failure.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
