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>
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>
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>
