coreboot-kgpe-d16/src/mainboard/google/storm/boardid.c

44 lines
1.2 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
#include <boardid.h>
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 <gpio.h>
#include <console/console.h>
/*
* Storm boards dedicate to the board ID three GPIOs in tertiary mode: 29, 30
* and 68. On proto0 GPIO68 is used and tied low, so it reads as 'zero' by
* gpio_base3_value(), whereas the other two pins are not connected
* and read as 'two'. This results in gpio_base3_value() returning
* 8 on proto0.
*
* Three tertitiary signals could represent 27 different values. To make
* calculated board ID value continuous and starting at zero, offset the
* calculated value by 19 (i.e. 27 - 8) and return modulo 27 of the offset
* number. This results in proto0 returning zero as the board ID, the future
* revisions will have the inputs configured to match the actual board
* revision.
*/
static int board_id_value = -1;
static uint8_t get_board_id(void)
{
uint8_t bid;
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_t hw_rev_gpios[] = {[2] = 68, [1] = 30, [0] = 29}; /* 29 is LSB */
int offset = 19;
bid = gpio_base3_value(hw_rev_gpios, ARRAY_SIZE(hw_rev_gpios));
bid = (bid + offset) % 27;
printk(BIOS_INFO, "Board ID %d\n", bid);
return bid;
}
uint32_t board_id(void)
{
if (board_id_value < 0)
board_id_value = get_board_id();
return board_id_value;
}