The GIC interrupt should not be firing when the arbiter interrupts
(peripheral interrupts) are disabled. So enabling/disabling the GIC
interrupt is not necessary. Remove those calls, and corresponding
reference counter logic.
Change-Id: Ice8d76ef255ec6c154c546dbd17807012558fe84
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
<linux/pm_runtime.h> should be included to fix any compilation errors
associated with enabling the PM_RUNTIME config.
Change-Id: Ided562e1351ccb5eef8957c305060275a5679d42
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
MSM_QPNP provides the qpnp_get_irq() API that is used by
client drivers using QPNP interrupts.
Change-Id: I4556b07a2c6b8dfeda860ebac57be6eb14f216b1
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
The spmi-dev-container binding is intended for SPMI
configurations that have multiple device nodes associated with
only one spmi_device. By default, if this flag is not specified,
each device node will create a new spmi_device.
Sometimes having multiple spmi_devices for SPMI device nodes is
superfluous. One example of this is gpios. In some architectures,
a single gpio is treated as a unique device. But from a gpio_chip
perspective, the chip is comprised of many gpios. Beyond wasting
memory allocating a unique spmi_device per gpio, the implication
of not coalescing spmi_devices is that the clients probe() routine
would be called N number of times. But this sort of behavior makes
it difficult to realize when a gpio_chip starts and stops. If we
assume that one gpio_chip represents one call to probe(), then
this problem is solved, since all gpios in that chip will be
passed as resources.
In order to support multiple device nodes per spmi_device, we
also need to extend the data structures for spmi_resources.
This change also makes an effort to cleanup some of the error
handling for illegal combinations of device bindings, as well as
adding some additional documentation.
Change-Id: If3ce2aaaa07bdf79e0d9fdedf16419e74a00fbec
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
QPNP is a Qualcomm SPMI based implementation that specifies 256
devices per SPMI slave ID, with up to 8 interrupts per device.
This brings the theoretical max interrupt support to 32768 per
bus for this architecture.
This driver implements the standard irq chip interfaces to
support QPNP. The chip driver is informed of Device Tree
configuration through a notifier interface. Once informed of an
interrupt, it will allocate resources on the fly. In order to
support this large logical interrupt range, we require SPARSE_IRQ
to be enabled.
This driver supports Device Tree interrupt specs with a cell size
of three. These are comprised of the the slave ID, peripheral ID
and irq number.
Change-Id: Ic7847bafe6598a84ab3650df7c95bb605aefbe62
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
QPNP is a SPMI based PMIC architecture developed by Qualcomm.
This library constitutes routines that should be necessary for
most, if not all QPNP based devices. The goal is to minimize the
amount of code duplication.
Change-Id: I0fddfcef88416bba488480d790d1cf361d9e67ac
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
reduce memory by compressing two values into one 32 bit integer.
Change-Id: I7c0bf7007df082fac53c1138ba45f1ecf77b2f83
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Qualcomm's PMIC Arbiter SPMI controller functions as a bus master and
is used to communication with one or more PMIC (slave) devices on the
SPMI bus. The PMIC Arbiter is actually a hardware wrapper around the
SPMI controller that provides concurrent and autonomous PMIC access
to various entities that need to communicate with the PMIC.
The SPMI controller hardware handles all of the SPMI bus activity (bus
arbitration, sequence start condition, transmission of frames, etc).
This software driver uses the PMIC Arbiter register interface to
initiate command sequences on the SPMI bus. The status register is
read to determine when the command sequence has completed and whether
or not it completed successfully.
Request Capable Slave (RCS) devices can initiate a master write
command sequence on the SPMI bus that the can be decoded by the
bus master and used to generate interrupts.
Change-Id: I037fefc946ccb5b8e0b04da856a3a96effe1c7e4
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
SPMI (System Power Management Interface) is a specification
developed by the MIPI (Mobile Industry Process Interface) Alliance
optimized for the real time control of Power Management ICs (PMIC).
SPMI is a two-wire serial interface that supports up to 4 master
devices and up to 16 logical slaves. A physical PMIC device may
consist of multiple logical slave interfaces.
The framework supports message APIs, multiple busses (1 controller
per bus) and multiple clients/slave devices per controller.
Change-Id: Ib6319047b4ab9cea6dfb0879312c4c1f63462439
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
