In revision 1 of the gpio block, the GPIO_STATUS1 GPIO_OK changes
from bit 1 to bit 7. Update the code to reflect this.
Also verify that PMIC pins have valid types and subtypes upon
probe. This allows us to make assumptions about correctness later
on when checking for capabilities of a pin in question.
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
(cherry picked from commit bfe64c7551275d24cb8eb45ff0b578427d68c2e0)
Change-Id: Idc7464799ff354b83c82e38004aa299356551630
Signed-off-by: Sudhir Sharma <sudsha@codeaurora.org>
When gpios are set to input, we return the input buffer status
from the STATUS1 register when the 'get' gpiochip callback is
invoked. This register also includes a bit that indicates whether
the pin is enabled.
Check to verify the pin is enabled, and if it is then return the
properly masked 1-bit value. Otherwise return an error, since the
API is not valid in this state.
Change-Id: I715e17f076d0dbd67397812f98e308f863c59b7c
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
-fix address value updates when writing to register blocks
greater than 8 bytes.
-fix an invalid shift value being passed in for the 'invert' parameter.
-fix invalid use of MODE_CTL macros
-cleanup the control register read / write routines to
remove unused parameters.
Change-Id: I42223f30a8c6490370d9a8006ee13e028fe774e6
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
The subtypes defined in the documentation have changed again.
Update both GPIO and MPP subtype values in the qpnp-pin driver to
reflect this.
Change-Id: I22e22414a74d724259706c927582d1573dc58875
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
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>
