The devnode array is currently being used for non
spmi-dev-container devices as a special case where the number of
devnodes is 1. This obfuscates the code and also removes the
ability to store the dev-container's device resource information,
since in that special case the devnode array is dedicated for the
child devices.
Add a new spmi_resource entry used for typical spmi_devices, and
treat the devnode array as the special case for
spmi-dev-container.
Also add a new API spmi_get_primary_dev_name() to return the name
of the device assigned with the 'label' binding if it exists.
Change-Id: Ibe7b12285e37bb0529024558550a96d71393bc10
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Since we support multiple device_nodes per spmi_device when used
with the spmi-dev-container flag, it's often unclear how a driver
should make reference to a particular device. Therefore,
introduce the spmi specific binding spmi-dev-name that specifies
the device name for the device_node.
Also introduce an API that can be used from
the driver to lookup the specific device node associated with a
particular device name.
Note that it may seem at first glance that the binding 'label' is
redundant with device_node->name. However, per the ePAPR,
device_node->name is intended to be as generic as possible,
representing the function of the device and not the precise
programming model. 'label' is used to give a platform
specific name that can be queried from device drivers.
Change-Id: I28eca35d0b625372c26a6d8ad81e7679f200d14b
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
reg-names and interrupt-names are standard bindings to map device
tree reg and interrupt indices to particular names. This way the
driver does not need to be concerned with hard coded assignments.
Therefore, add spmi support for these bindings.
Explicit support for reg-names is required since the
implementation does not make use of of_address_to_resource(),
which happens to already support this.
This is because of_address_to_resource() mandates address
translation, which is not relevant to spmi.
interrupt-names is already implicitly handled by
of_irq_to_resource(), which is used in the spmi implementation.
Add additional documentation to state clearly that this binding
is also supported.
Also add supporting routines to easily lookup a resource by name
for both registers and interrupts.
Change-Id: I94faf950da5106ecd4ff36f47e5b46102d9bd426
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Device Tree allows for devices to be specified as disabled.
This is useful to override SoC specific configuration on boards
that may not have this device.
Change-Id: I77490f6d2f2634c526cf01a2b0da029ff0d51ef0
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
This factors out some code that is executed twice for no reason.
Change-Id: I562f41b05656dc6d8621859ef5b598869a61c28e
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>
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>
Signed-off-by: David Brown <davidb@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>
Signed-off-by: David Brown <davidb@codeaurora.org>
Michael Bohan