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>
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>
This binding is currently used to indicate all devices existing
in the same slave. Let's change the name to be more meaningful.
The real motivation here is that we want to introduce a new
binding to specify all qpnp devices existing in the same
spmi_device. So spmi-dev-container is a more meaningful name for
that usecase, and spmi-slave-container better describes the
former.
Change-Id: I48f834b9cff9ea90d05f5e958ca21bef0ab56a86
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
reduce memory by compressing two values into one 32 bit integer.
Change-Id: I7c0bf7007df082fac53c1138ba45f1ecf77b2f83
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Add the basic attributes in the device tree for the SPMI PMIC
Arbiter.
Change-Id: I73bb32d06de94219e9c3a930939ee69302686356
Signed-off-by: Kenneth Heitke <kheitke@codeaurora.org>
This change adds SPMI Device Tree parsing. The
of_spmi_register_devices() API should be called from the probe()
routine of each SPMI controller to parse the subtree and add the
respective SPMI devices.
The SPMI subtree is nested up to two levels deep. The first level
is the most basic and treats the address as the SPMI slave ID.
This should be used for simple devices that has no notion of
segmented SPMI address spaces.
An optional second level specifies the address as an offset
within the outer layer's slave ID. This is used to specify
multiple devices on the same slave ID that have different address
ranges. In fact, it's reasonable to specify any number of address
ranges at this level.
Devices can also specify any number of interrupts that's decoding
is done by an external interrupt device.
Sections of this code were taken from drivers/of/platform.c.
Change-Id: Ib9f06764a9bd85e3b2aab43b72aa7132885aa044
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
