2014-07-23 18:40:02 +02:00
|
|
|
/*
|
|
|
|
* This file is part of the coreboot project.
|
|
|
|
*
|
|
|
|
* Copyright 2014 Google Inc.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; version 2 of the License.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*/
|
|
|
|
|
gpio: Extend common GPIO header, simplify function names
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
#ifndef __SRC_INCLUDE_GPIO_H__
|
|
|
|
#define __SRC_INCLUDE_GPIO_H__
|
2014-07-23 18:40:02 +02:00
|
|
|
|
gpio: Extend common GPIO header, simplify function names
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
#include <soc/gpio.h>
|
|
|
|
#include <types.h>
|
|
|
|
|
|
|
|
/* <soc/gpio.h> must typedef a gpio_t that fits in 32 bits. */
|
|
|
|
_Static_assert(sizeof(gpio_t) <= sizeof(u32), "gpio_t doesn't fit in lb_gpio");
|
|
|
|
|
|
|
|
/* The following functions must be implemented by SoC/board code. */
|
|
|
|
int gpio_get(gpio_t gpio);
|
|
|
|
void gpio_set(gpio_t gpio, int value);
|
|
|
|
void gpio_input_pulldown(gpio_t gpio);
|
|
|
|
void gpio_input_pullup(gpio_t gpio);
|
|
|
|
void gpio_input(gpio_t gpio);
|
|
|
|
void gpio_output(gpio_t gpio, int value);
|
2016-03-17 01:11:55 +01:00
|
|
|
int _gpio_base3_value(gpio_t gpio[], int num_gpio, int binary_first);
|
2014-07-23 18:40:02 +02:00
|
|
|
|
2016-05-10 01:09:25 +02:00
|
|
|
/*
|
|
|
|
* This function may be implemented by SoC/board code to provide
|
|
|
|
* a mapping from a GPIO pin to controller by returning the ACPI
|
|
|
|
* path for the controller that owns this GPIO.
|
|
|
|
*
|
|
|
|
* If not implemented the default handler will return NULL.
|
|
|
|
*/
|
|
|
|
const char *gpio_acpi_path(gpio_t gpio);
|
|
|
|
|
2016-06-29 19:47:22 +02:00
|
|
|
/*
|
|
|
|
* This function may be implemented by SoC/board code to provide
|
|
|
|
* a mapping from the internal representation of a GPIO to the 16bit
|
|
|
|
* value used in an ACPI GPIO pin table entry.
|
|
|
|
*
|
|
|
|
* If not implemented by the SOC the default handler will return 0
|
|
|
|
* because the underlying type of gpio_t is unknown.
|
|
|
|
*/
|
|
|
|
uint16_t gpio_acpi_pin(gpio_t gpio);
|
|
|
|
|
2014-11-07 00:05:35 +01:00
|
|
|
/*
|
|
|
|
* Read the value presented by the set of GPIOs, when each pin is interpreted
|
|
|
|
* as a base-2 digit (LOW = 0, HIGH = 1).
|
|
|
|
*
|
|
|
|
* gpio[]: pin positions to read. gpio[0] is less significant than gpio[1].
|
|
|
|
* num_gpio: number of pins to read.
|
2016-07-07 05:37:10 +02:00
|
|
|
*
|
|
|
|
* There are also pulldown and pullup variants which default each gpio to
|
|
|
|
* be configured with an internal pulldown and pullup, respectively.
|
2014-11-07 00:05:35 +01:00
|
|
|
*/
|
|
|
|
int gpio_base2_value(gpio_t gpio[], int num_gpio);
|
2016-07-07 05:37:10 +02:00
|
|
|
int gpio_pulldown_base2_value(gpio_t gpio[], int num_gpio);
|
|
|
|
int gpio_pullup_base2_value(gpio_t gpio[], int num_gpio);
|
2014-11-07 00:05:35 +01:00
|
|
|
|
2014-07-23 18:40:02 +02:00
|
|
|
/*
|
|
|
|
* Read the value presented by the set of GPIOs, when each pin is interpreted
|
gpio: Remove non-ternary tristate mode, make ternaries easier
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d
Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219901
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
* as a base-3 digit (LOW = 0, HIGH = 1, Z/floating = 2).
|
2014-11-07 00:09:27 +01:00
|
|
|
* Example: X1 = Z, X2 = 1 -> gpio_base3_value({GPIO(X1), GPIO(X2)}) = 5
|
gpio: Remove non-ternary tristate mode, make ternaries easier
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d
Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219901
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
* BASE3() from <base3.h> can generate numbers to compare the result to.
|
2014-07-23 18:40:02 +02:00
|
|
|
*
|
gpio: Remove non-ternary tristate mode, make ternaries easier
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d
Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219901
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
* gpio[]: pin positions to read. gpio[0] is less significant than gpio[1].
|
2014-08-09 00:38:52 +02:00
|
|
|
* num_gpio: number of pins to read.
|
2014-07-23 18:40:02 +02:00
|
|
|
*/
|
2016-03-17 01:11:55 +01:00
|
|
|
static inline int gpio_base3_value(gpio_t gpio[], int num_gpio)
|
|
|
|
{
|
|
|
|
return _gpio_base3_value(gpio, num_gpio, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read the value presented by the set of GPIOs, when each pin is interpreted
|
|
|
|
* as a base-3 digit (LOW = 0, HIGH = 1, Z/floating = 2) in a non-standard
|
|
|
|
* ternary number system where the first 2^n natural numbers are represented
|
|
|
|
* as they would be in a binary system (without any Z digits), and the following
|
|
|
|
* 3^n-2^n numbers use the remaining ternary representations in the normal
|
|
|
|
* ternary system order (skipping the values that were already used up).
|
|
|
|
* This is useful for boards which initially used a binary board ID and later
|
|
|
|
* decided to switch to tri-state after some revisions have already been built.
|
|
|
|
* Example: For num_gpio = 2 we get the following representation:
|
|
|
|
*
|
|
|
|
* Number X1 X0
|
|
|
|
* 0 0 0
|
|
|
|
* 1 0 1
|
|
|
|
* 2 1 0
|
|
|
|
* 3 1 1 // Start counting ternaries back at 0 after this
|
|
|
|
* 4 0 2 // Skipping 00 and 01 which are already used up
|
|
|
|
* 5 1 2 // Skipping 10 and 11 which are already used up
|
|
|
|
* 6 2 0
|
|
|
|
* 7 2 1
|
|
|
|
* 8 2 2
|
|
|
|
*
|
|
|
|
* gpio[]: pin positions to read. gpio[0] is less significant than gpio[1].
|
|
|
|
* num_gpio: number of pins to read.
|
|
|
|
*/
|
|
|
|
static inline int gpio_binary_first_base3_value(gpio_t gpio[], int num_gpio)
|
|
|
|
{
|
|
|
|
return _gpio_base3_value(gpio, num_gpio, 1);
|
|
|
|
}
|
2014-07-23 18:40:02 +02:00
|
|
|
|
gpio: Extend common GPIO header, simplify function names
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-25 00:40:49 +02:00
|
|
|
#endif /* __SRC_INCLUDE_GPIO_H__ */
|