The current code uses handle_level_irq flow handler even if the trigger
type of the interrupt is edge. This can lead to missing of an edge
transition that happens when the interrupt is being handled. The level
flow handler masks the interrupt while it is being handled, so if an edge
transition happens at that time, that edge is lost.
Use an edge flow handler for edge type interrupts which ensures that the
interrupt stays enabled while being handled - at least until it triggers
at which point the flow handler sets the IRQF_PENDING flag and only then
masks the interrupt. That IRQF_PENDING state indicates an edge transition
happened while the interrupt was being handled and the handler is called
again.
CRs-Fixed: 1001770
Change-Id: Id2554c9e6ed79188fa1b64728be464bda45f07ec
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
This reverts commit 3b1bda734d ("spmi: pmic_arb: use
handle_fasteoi_irq handler")
PMIC interrupt are not aligned to be used as fasteoi, this
is because
* most of the PMIC interrupts are threaded and are configured as
ONESHOT. Fasteoi handlers do not support ONESHOT semantics
* There is a chance of losing edge interrupts that trigger while
the handler is running. This is because fasteoi handler signals
EOI after the handler is run. So edge interrupts that trigger
while the handler is running get acknowledged without being
handled.
CRs-Fixed: 1001770
Change-Id: I622fd971201b6c0001212a696c3d12aea409c11b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
PMIC bus arbiter v3 supports 512 SPMI peripherals. Add the v3 operators to
support this new arbiter version.
CRs-Fixed: 1001770
Change-Id: Ic36b8e3c01af2fde1827a53c8c52baed240c238e
Signed-off-by: Nicholas Troast <ntroast@codeaurora.org>
The interrupt controller uses level handler for all its interrupt.
The hardware irq controller confirms to the fasteoi handler type in
that it rearms itself when acknowledged. There is no need to
additionally mask the interrupt while being handled.
Use fasteoi handler type for pmic interrupts. Since fasteoi needs
an irq_eoi callback, use the same function used for irq_ack.
Change-Id: I9a941d8b56ad5698da38e16b2afcf87ef920ebfd
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver ensures that no read/write transaction is in progress
while it makes changes to the interrupt regions. This is not necessary
because read/writes over spmi and arbiter interrupt control are
independent operations.
Change-Id: Id6a93eed0aabe55a4b655a2050c31b48327dffe4
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The interrupt controller code in the arbiter disables
the peripheral accumulated interrupt (ACC) bit when none of the
interrupts in the peripheral is enabled.
This is not required since the controller disables the interrupt
at the pmic.
So leave the ACC bit enabled while masking an interrupt. Also
ensure that the ACC bit is enabled while unmasking an interrupt.
There is no issues with enabling ACC bit if it were already enabled.
Change-Id: Idbea562157e65a4dfe0c51b7a25eed5ce000068d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Being able to write to spmi registers via userspace is required
for quick debug and development. Enable it.
The regmap framework uses dev_name to create debugfs dir names.
So update the spmi devices to have proper names.
Change-Id: I8a5da203b212df9a7f1410e3fcf6ee7b429856b6
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
struct pmic_arb_irq_spec serves no real purpose. It is used only
in the translate function and the code is much cleaner without it.
Change-Id: I4daae954b8e01b33a9c7f5a343a31c15b4787382
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
PMIC interrupts each have an internal latched status bit which is
not visible from any register. This status bit is set as soon as
the conditions specified in the interrupt type and polarity
registers are met even if the interrupt is not enabled. When it
is set, nothing else changes within the PMIC and no interrupt
notification packets are sent. If the internal latched status
bit is set when an interrupt is enabled, then the value is
immediately propagated into the interrupt latched status register
and an interrupt notification packet is sent out from the PMIC
over SPMI.
This PMIC hardware behavior can lead to a situation where the
handler for a level triggered interrupt is called immediately
after enable_irq() is called even though the interrupt physically
triggered while it was disabled within the genirq framework.
This situation takes place if the the interrupt fires twice after
calling disable_irq(). The first time it fires, the level flow
handler will mask and disregard it. Unfortunately, the second
time it fires, the internal latched status bit is set within the
PMIC and no further notification is received. When enable_irq()
is called later, the interrupt is unmasked (enabled in the PMIC)
which results in the PMIC immediately sending an interrupt
notification packet out over SPMI. This breaks the semantics
of level triggered interrupts within the genirq framework since
they should be completely ignored while disabled.
The PMIC internal latched status behavior also affects how
interrupts are treated during suspend. While entering suspend,
all interrupts not specified as wakeup mode are masked. Upon
resume, these interrupts are unmasked. Thus if any of the
non-wakeup PMIC interrupts fired while the system was suspended,
then the PMIC will send interrupt notification packets out via
SPMI as soon as they are unmasked during resume. This behavior
violates genirq semantics as well since non-wakeup interrupts
should be completely ignored during suspend.
Modify the qpnpint_irq_unmask() function so that the interrupt
latched status clear register is written immediately before the
interrupt enable register. This clears the internal latched
status bit of the interrupt so that it cannot trigger spuriously
immediately upon being enabled.
Also, while resuming an irq, an unmask could be called even if it
was not previously masked. So, before writing these registers,
check if the interrupt is already enabled within the PMIC. If it
is, then no further register writes are required. This
condition check ensures that a valid latched status register bit
is not cleared until it is properly handled.
Change-Id: Ie05845b692a151c39943aa3e2aad6bcae4194d83
Signed-off-by: David Collins <collinsd@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
irq_enable which is called when the device resumes. Note that the
irq_enable is called regardless of whether the interrupt was
marked enabled/disabled in the descriptor or whether it was
masked/unmaked at the controller while resuming.
The current driver unconditionally clears the interrupt in its
irq_enable callback. This is dangerous as any interrupts that
happen right before the resume could be missed.
Remove the irq_enable callback and use mask/unmask instead.
Change-Id: I58695ae0c4905a699003d35498dc36c2a947f3f0
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
We see a unmapped irqs trigger right around bootup. This could
likely be because the bootloader exited leaving the interrupts
in an unknown or unhandled state. Ack and mask the interrupt
if one is found. A request_irq later will unmask it and also
setup proper mapping structures.
Change-Id: Icc2fc4f1bd9b3333e5856fce2daa5ba2b69e9a87
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver disables/enables the ACC bit when any interrupt
in that peripheral is being masked or unmasked.
However, the ACC bits were meant to be disabled and enabled when
all interrupts in that peripheral are disabled and any interrupts in
it are enabled respt.
The driver ends up masking the peripheral (i.e. all the interrupts
in that peripheral) if any one interrupt in that peripheral is masked.
There could be other interrupts enabled which will not trigger after this.
Fix this by changing the driver to disable or enable when all the
interrupts in the peripheral are disabled or when the first enable of an
interrupt in that peripheral happens.
Note that we will need to keep track of the enabled interrupts for an
apid. There are other things like ppid and owner information tracked per
apid. Introduce a per apid structure to track all the three.
Change-Id: I256546a7a4683a463beb6d0eb360a0edd4e5c11d
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The current driver uses a mix of radix tree and a fwd lookup
table to translate between apid and ppid. It is buggy and confusing.
Instead simply use a radix tree for v1 hardware and use the
forward lookup table for v2.
Change-Id: I74e1dc0c3dbbf2b311786af7d80a9d4810d510d7
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The driver currently uses "apid" and "chan" to mean apid. Remove
the use of chan and use only apid.
On a SPMI bus there is allocation to manage up to 4K peripherals.
However, in practice only few peripherals are instantiated
and only few among the instantiated ones actually interrupt.
APID is CPU's way of keeping track of peripherals that could interrupt.
There is a table that maps the 256 interrupting peripherals to
a number between 0 and 255. This number is called APID.Information about
that interrupting peripheral is stored in registers offset by its
corresponding number between 0 and 255.
Change-Id: Icdb82da24232a5382ed03b7437c3207db1befa94
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Usually *_dev best used for structures that embed a struct device in
them. spmi_pmic_arb_dev doesn't embed one. It is simply a driver data
structure. Use an appropriate name for it.
Change-Id: I432eeb0273cac78638440cd00c64cc568ccd68c5
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
There are many places in the driver that left shift the bit to
generate a bit mask. It is simpler to use BIT() macro.
Change-Id: I05ac8469304458a0f26aafd1292fcbb65d312f0a
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The system crashes due to bad access when reading from an non configured
peripheral and when writing to peripheral which is not owned by current
ee. This patch verifies ownership to avoid crashing on
write.
For reads, since the forward mapping table, data_channel->ppid, is
towards the end of the block, we use the core size to figure the
max number of ppids supported. The table starts at an offset of 0x800
within the block, so size - 0x800 will give us the area used by the
table. Since each table is 4 bytes long (core_size - 0x800) / 4 will
gives us the number of data_channel supported.
This new protection is functional on hw v2.
Change-Id: I74e3452963a7dda9a8c8aaef76de3117cabc454b
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Add support for more than 128 peripherals by taking a lazy
caching approach to the mapping tables. Instead of reading and
caching the tables at boot given some fixed size, read them and
cache them on an as needed basis. We still assume a max size of
512 peripherals, trading off some space for simplicity.
Based on a patch by Gilad Avidov <gavidov@codeaurora.org> and
Sagar Dharia <sdharia@codeaurora.org>.
Change-Id: I90ae4100195eef3303b3d6501d3c3ffdbce085b7
Cc: Gilad Avidov <gavidov@codeaurora.org>
Cc: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
The spmi arbiter device spawns spmi_devices which in turn spawn
platform_devices for pmic peripherals.
Move the arbiter's driver init to arch_initcall so that the subsequent
devices it spawns get instantiated earlier.
Change-Id: Ib96937f274745549ee86f758673aab4db97acbaf
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Here is the big char/misc driver update for 4.4-rc1. Lots of different
driver and subsystem updates, hwtracing being the largest with the
addition of some new platforms that are now supported. Full details in
the shortlog.
All of these have been in linux-next for a long time with no reported issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEABECAAYFAlY6d/oACgkQMUfUDdst+yl93ACcCf91y+ufwU3cmcnq5LpwHPfx
VbkAn08Cn6Wu6IcihoEpR4hqGgIOtjqW
=1a3d
-----END PGP SIGNATURE-----
Merge tag 'char-misc-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver updates from Greg KH:
"Here is the big char/misc driver update for 4.4-rc1. Lots of
different driver and subsystem updates, hwtracing being the largest
with the addition of some new platforms that are now supported. Full
details in the shortlog.
All of these have been in linux-next for a long time with no reported
issues"
* tag 'char-misc-4.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (181 commits)
fpga: socfpga: Fix check of return value of devm_request_irq
lkdtm: fix ACCESS_USERSPACE test
mcb: Destroy IDA on module unload
mcb: Do not return zero on error path in mcb_pci_probe()
mei: bus: set the device name before running fixup
mei: bus: use correct lock ordering
mei: Fix debugfs filename in error output
char: ipmi: ipmi_ssif: Replace timeval with timespec64
fpga: zynq-fpga: Fix issue with drvdata being overwritten.
fpga manager: remove unnecessary null pointer checks
fpga manager: ensure lifetime with of_fpga_mgr_get
fpga: zynq-fpga: Change fw format to handle bin instead of bit.
fpga: zynq-fpga: Fix unbalanced clock handling
misc: sram: partition base address belongs to __iomem space
coresight: etm3x: adding documentation for sysFS's cpu interface
vme: 8-bit status/id takes 256 values, not 255
fpga manager: Adding FPGA Manager support for Xilinx Zynq 7000
ARM: zynq: dt: Updated devicetree for Zynq 7000 platform.
ARM: dt: fpga: Added binding docs for Xilinx Zynq FPGA manager.
ver_linux: proc/modules, limit text processing to 'sed'
...
The struct irq_domain contains a "struct device_node *" field
(of_node) that is almost the only link between the irqdomain
and the device tree infrastructure.
In order to prepare for the removal of that field, convert all
users to use irq_domain_get_of_node() instead.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-and-tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Cc: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Cc: Graeme Gregory <graeme@xora.org.uk>
Cc: Jake Oshins <jakeo@microsoft.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Link: http://lkml.kernel.org/r/1444737105-31573-2-git-send-email-marc.zyngier@arm.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
We don't want to swap bytes that we're reading and writing to the
FIFOs when we're running on a big-endian CPU. Doing so causes
problems like where the qcom-spmi-iadc driver can't detect the
type of device because the bytes are all mixed up. Use the raw IO
accessors for these API instead, and collapse pmic_arb_base_read()
into the byte reading API so that we aren't tempted to read non-FIFO
data like commands with that function.
Cc: Andy Gross <agross@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Populate the owner field of the spmi driver when
spmi_driver_register() is called in a similar fashion to how
other *_driver_register() functions do it. This saves driver
writers from having to do this themselves.
Cc: Andy Gross <agross@codeaurora.org>
Cc: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Most interrupt flow handlers do not use the irq argument. Those few
which use it can retrieve the irq number from the irq descriptor.
Remove the argument.
Search and replace was done with coccinelle and some extra helper
scripts around it. Thanks to Julia for her help!
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Pull irq updates from Thomas Gleixner:
"This updated pull request does not contain the last few GIC related
patches which were reported to cause a regression. There is a fix
available, but I let it breed for a couple of days first.
The irq departement provides:
- new infrastructure to support non PCI based MSI interrupts
- a couple of new irq chip drivers
- the usual pile of fixlets and updates to irq chip drivers
- preparatory changes for removal of the irq argument from interrupt
flow handlers
- preparatory changes to remove IRQF_VALID"
* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (129 commits)
irqchip/imx-gpcv2: IMX GPCv2 driver for wakeup sources
irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2
irqchip: Add documentation for the bcm2836 interrupt controller
irqchip/bcm2835: Add support for being used as a second level controller
irqchip/bcm2835: Refactor handle_IRQ() calls out of MAKE_HWIRQ
PCI: xilinx: Fix typo in function name
irqchip/gic: Ensure gic_cpu_if_up/down() programs correct GIC instance
irqchip/gic: Only allow the primary GIC to set the CPU map
PCI/MSI: pci-xgene-msi: Consolidate chained IRQ handler install/remove
unicore32/irq: Prepare puv3_gpio_handler for irq argument removal
tile/pci_gx: Prepare trio_handle_level_irq for irq argument removal
m68k/irq: Prepare irq handlers for irq argument removal
C6X/megamode-pic: Prepare megamod_irq_cascade for irq argument removal
blackfin: Prepare irq handlers for irq argument removal
arc/irq: Prepare idu_cascade_isr for irq argument removal
sparc/irq: Use access helper irq_data_get_affinity_mask()
sparc/irq: Use helper irq_data_get_irq_handler_data()
parisc/irq: Use access helper irq_data_get_affinity_mask()
mn10300/irq: Use access helper irq_data_get_affinity_mask()
irqchip/i8259: Prepare i8259_irq_dispatch for irq argument removal
...
IRQ_DOMAIN is a hidden config option, so depending on it doesn't
make any sense. Select the config option because it's required to
compile this driver.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Andy Gross <agross@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add tracepoints to retrieve information about read, write
and non-data commands. For performance measurement support
tracepoints are added at the beginning and at the end of
transfers. Following is a list showing the new tracepoint
events. The "cmd" parameter here represents the opcode, SID,
and full 16-bit address.
spmi_write_begin: cmd and data buffer.
spmi_write_end : cmd and return value.
spmi_read_begin : cmd.
spmi_read_end : cmd, return value and data buffer.
spmi_cmd : cmd.
The reason that cmd appears at both the beginning and at
the end event is that SPMI drivers can request commands
concurrently. cmd helps in matching the corresponding
events.
SPMI tracepoints can be enabled like:
echo 1 >/sys/kernel/debug/tracing/events/spmi/enable
and will dump messages that can be viewed in
/sys/kernel/debug/tracing/trace that look like:
... spmi_read_begin: opc=56 sid=00 addr=0x0000
... spmi_read_end: opc=56 sid=00 addr=0x0000 ret=0 len=02 buf=0x[01-40]
... spmi_write_begin: opc=48 sid=00 addr=0x0000 len=3 buf=0x[ff-ff-ff]
Suggested-by: Sagar Dharia <sdharia@codeaurora.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: Ankit Gupta <ankgupta@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
already have a pointer to corresponding irq_desc.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: http://lkml.kernel.org/r/20150713151750.915477120@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Chained irq handlers usually set up handler data as well. We now have
a function to set both under irq_desc->lock. Replace the two calls
with one.
Search and conversion was done with coccinelle.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Link: http://lkml.kernel.org/r/20150713151750.831790045@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Not all architectures have io memory.
Fixes:
drivers/built-in.o: In function `spmi_pmic_arb_probe':
spmi-pmic-arb.c:(.text+0x1ed399): undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qualcomm PMIC arbiter driver already depends on ARCH_QCOM,
which could be either ARM or ARM64. New version of the PMIC
arbiter controller is available on 64 bit platforms.
Remove ARM dependency to allow driver to be build for 64 bit
platforms.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qualcomm PMIC Arbiter version-2 changes from version-1 are:
- Some different register offsets.
- New channel register space, one per PMIC peripheral (ppid).
All tx traffic uses these channels.
- New observer register space. All rx trafic uses this space.
- Different command format for spmi command registers.
Reviewed-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Tested-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
According to spmi spec a slave powers up into startup state and then
transitions into active state. Thus, the wakeup command is not required
before calling the slave's probe. The wakeup command is only needed for
slaves that are in sleep state after receiving the sleep command.
Cc: galak@codeaurora.org
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Sagar Dharia <sdharia@codeaurora.org>
Acked-by: Josh Cartwright <joshc@eso.teric.us>
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Tested-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SPMI defines the behavior of a device in the "SLEEP" state as being
"user-defined or specified by the device manufacturer". Without
clearly-defined bus-level semantics for low-power states, push the
responsibility of transitioning a device into/out of "SLEEP" into SPMI
device drivers.
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
With the split of Qualcomm MSM support into legacy and multiplatform,
the SPMI PMIC arb driver is only relevant on the multiplatform supported
SoCs. Switch the Kconfig depends to ARCH_QCOM.
Acked-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Qualcomm PMIC Arbiter, in addition to being a basic SPMI controller,
also implements interrupt handling for slave devices. Note, this is
outside the scope of SPMI, as SPMI leaves interrupt handling completely
unspecified.
Extend the driver to provide a irq_chip implementation and chained irq
handling which allows for these interrupts to be used.
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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.
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
System Power Management Interface (SPMI) 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.
The framework supports message APIs, multiple busses (1 controller
per bus) and multiple clients/slave devices per controller.
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
