summaryrefslogtreecommitdiff
path: root/src/lib/gpio.c
AgeCommit message (Collapse)Author
2016-05-21gpio: Add a function to map GPIO to ACPI pathDuncan Laurie
Add a new function "gpio_acpi_path()" that can be implemented by SoC/board code to provide a mapping from a "gpio_t" pin to a controller by returning the ACPI path for the controller that owns this particular GPIO. This is implemented separately from the "acpi_name" handler as many SOCs do not have a specific device that handles GPIOs (or may have many devices and the only way to know which is the opaque gpio_t) and the current GPIO library does not have any association with the device tree. If not implemented (many SoCs do not implement the GPIO library abstraction at all in coreboot) then the default handler will return NULL and the caller knows it cannot determine this reliably. Change-Id: Iaa0ff6c8c058f00cddf0909c4b7405a0660d4cfb Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://review.coreboot.org/14842 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-03-22gpio: Add support for binary_first base3 number systemJulius Werner
This patch adds support for an alternative ternary number system in which group of GPIOs can be interpreted. In this system, the digit combinations that would form a binary number (i.e. that contain no 'Z' state) are used to represent the lower values in the way they're used in the normal binary system, and all the combinations that do contain a 'Z' are used to represent values above those. We can use this for boards that originally get strapped with binary board IDs but eventually require more revisions than that representation allows. We can switch their code to binary_first base3 and all old revisions with already produced boards will still get read as the correct numbers. Credit for the algorithm idea goes to Haran Talmon. BRANCH=None BUG=None TEST=Stubbed out the actual GPIO reading and simulated all combinations of 4 ternary digits for both number systems. Change-Id: Ib5127656455f97f890ce2999ba5ac5f58a20cf93 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14116 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-07-29arm, arm64, mips: Add rough static stack size checks with -Wstack-usageJulius Werner
We've seen an increasing need to reduce stack sizes more and more for space reasons, and it's always guesswork because no one has a good idea how little is too litte. We now have boards with 3K and 2K stacks, and old pieces of common code often allocate large temporary buffers that would lead to very dangerous and hard to detect bugs when someone eventually tries to use them on one of those. This patch tries improve this situation at least a bit by declaring 2K as the minimum stack size all of coreboot code should work with. It checks all function frames with -Wstack-usage=1536 to make sure we don't allocate more than 1.5K in a single buffer. This is of course not a perfect test, but it should catch the most common situation of declaring a single, large buffer in some close-to-leaf function (with the assumption that 0.5K is hopefully enough for all the "normal" functions above that). Change one example where we were a bit overzealous and put a 1K buffer into BSS back to stack allocation, since it actually conforms to this new assumption and frees up another kilobyte of that highly sought-after verstage space. Not touching x86 with any of this since it's lack of __PRE_RAM__ BSS often requires it to allocate way more on the stack than would usually be considered sane. BRANCH=veyron BUG=None TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky, made sure they still build as well as before and don't show any stack usage warnings. Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/236978 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-17Add delay before reading GPIOs in gpio_base2_value()David Hendricks
This adds a 10us delay in between (re-)configuring and reading GPIOs in gpio_base2_value() to give the values stored some time to update. As far as I know this hasn't bitten us since the function was added, but adding a short delay here seems like the right thing to do. BUG=none BRANCH=none TEST=built and booted on Brain Change-Id: I869cf375680435ad87729f93d29a623bdf09dfbc Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2484900fc9ceba87220a293de8ef20c3b9b20cfd Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I79616a09d8d2ce4e416ffc94e35798dd25a6250d Original-Reviewed-on: https://chromium-review.googlesource.com/240854 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9725 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: add a function to read GPIO array as base-2 valueDavid Hendricks
This adds gpio_base2_value() which reads an array of 2-state GPIOs and returns a base-2 value, where gpio[0] represents the least significant bit. BUG=none BRANCH=none TEST=tested with follow-up patches for pinky Change-Id: I0d6bfac369da0d68079a38de0988c7b59d269a97 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 27873b7a9ea237d13f0cbafd10033a8d0f821cbe Original-Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228323 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: http://review.coreboot.org/9412 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2015-04-10gpio: cosmetic changes to tristate_gpios.cDavid Hendricks
This patch makes a few cosmetic changes: - Rename tristate_gpios.c to gpio.c since it will soon be used for binary GPIOs as well. - Rename gpio_get_tristates() to gpio_base3_value() - The binary version will be called gpio_base2_value(). - Updates call sites. - Change the variable name "id" to something more generic. BUG=none BRANCH=none TEST=compiled for veyron_pinky and storm Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/228324 Reviewed-on: http://review.coreboot.org/9411 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>