coreboot-kgpe-d16/src/include/gpio.h

112 lines
4.2 KiB
C
Raw Normal View History

Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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__
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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);
int _gpio_base3_value(gpio_t gpio[], int num_gpio, int binary_first);
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-07-23 18:40:02 +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);
/*
* 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);
/*
* 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.
*
* There are also pulldown and pullup variants which default each gpio to
* be configured with an internal pulldown and pullup, respectively.
*/
int gpio_base2_value(gpio_t gpio[], int num_gpio);
int gpio_pulldown_base2_value(gpio_t gpio[], int num_gpio);
int gpio_pullup_base2_value(gpio_t gpio[], int num_gpio);
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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).
* 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.
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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].
* num_gpio: number of pins to read.
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-07-23 18:40:02 +02: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);
}
Generalize revision number calculation function Some platforms use tertiary interpretation of GPIO input state to increase number of distinct values represented by a limited number of GPIOs. The three states are - external pull down (interpreted as 0) - external pull up (1) - not connected (2) This has been required by Nvidia devices so far, but Exynos and Ipq8086 platforms need this too. This patch moves the function reading the tertiary state into the library and exposes the necessary GPIO API functions in a new include file. The functions are still supposed to be provided by platform specific modules. The function interpreting the GPIO states has been modified to allow to interpret the state either as a true tertiary number or as a set two bit fields. Since linker garbage collection is not happening when building x86 targets, a new configuration option is being added to include the new module only when needed. BUG=chrome-os-partner:30489 TEST=verified that nyan_big still reports proper revision ID. Change-Id: Ib55122c359629b58288c1022da83e6c63dc2264d Original-Change-Id: I243c9f43c82bd4a41de2154bbdbd07df0a241046 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/209673 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit c79ef1c545d073eaad69e6c8c629f9656b8c2f3e) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/8717 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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__ */