coreboot-kgpe-d16/util/sconfig/sconfig.tab.h_shipped

128 lines
4.7 KiB
Plaintext
Raw Normal View History

sconfig: Allow to specify device operations Currently we only have runtime mechanisms to assign device operations to a node in our devicetree (with one exception: the root device). The most common method is to map PCI IDs to the device operations with a `struct pci_driver`. Another accustomed way is to let a chip driver assign them. For very common drivers, e.g. those in soc/intel/common/blocks/, the PCI ID lists grew very large and are incredibly error-prone. Often, IDs are missing and sometimes IDs are added almost mechanically without checking the code for compatibility. Maintaining these lists in a central place also reduces flexibility. Now, for onboard devices it is actually unnecessary to assign the device operations at runtime. We already know exactly what operations should be assigned. And since we are using chipset devicetrees, we have a perfect place to put that information. This patch adds a simple mechanism to `sconfig`. It allows us to speci- fy operations per device, e.g. device pci 00.0 alias system_agent on ops system_agent_ops end The operations are given as a C identifier. In this example, we simply assume that a global `struct device_operations system_agent_ops` exists. Change-Id: I2833d2f2450fde3206c33393f58b86fd4280b566 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/66483 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
2022-08-06 19:02:59 +02:00
/* A Bison parser, made by GNU Bison 3.8.2. */
/* Bison interface for Yacc-like parsers in C
util/sconfig: Add support for discontiguous FW_CONFIG fields Sooner or later, some board was going to need extra FW_CONFIG bits for a field that was already in production, so this patch adds support for adding extra (unused) bits to a field. The extra are appended via a syntax like: `field FIELD_NAME START0 END0 | START1 END1 | START2 END2 ...` and the suffixed bits are all treated as if they are contiguous when defining option values. BUG=b:185190978 TEST=Modified volteer fw_config to the following: field AUDIO 8 10 | 29 29 | 31 31 option NONE 0 option MAX98357_ALC5682I_I2S 1 option MAX98373_ALC5682I_I2S 2 option MAX98373_ALC5682_SNDW 3 option MAX98373_ALC5682I_I2S_UP4 4 option MAX98360_ALC5682I_I2S 5 option RT1011_ALC5682I_I2S 6 option AUDIO_FOO 7 option AUDIO_BAR 8 option AUDIO_QUUX 9 option AUDIO_BLAH1 10 option AUDIO_BLAH2 15 option AUDIO_BLAH3 16 option AUDIO_BLAH4 31 end which yielded (in static_fw_config.h): FW_CONFIG_FIELD_AUDIO_MASK 0xa0000700 FW_CONFIG_FIELD_AUDIO_OPTION_NONE_VALUE 0x0 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98357_ALC5682I_I2S_VALUE 0x100 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_VALUE 0x200 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682_SNDW_VALUE 0x300 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98373_ALC5682I_I2S_UP4_VALUE 0x400 FW_CONFIG_FIELD_AUDIO_OPTION_MAX98360_ALC5682I_I2S_VALUE 0x500 FW_CONFIG_FIELD_AUDIO_OPTION_RT1011_ALC5682I_I2S_VALUE 0x600 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE 0x700 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE 0x20000000 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_QUUX_VALUE 0x20000100 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH1_VALUE 0x20000200 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH2_VALUE 0x20000700 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH3_VALUE 0x80000000 FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH4_VALUE 0xa0000700 Change-Id: I5ed76706347ee9642198efc77139abdc3af1b8a6 Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/52747 Reviewed-by: Duncan Laurie <duncan@iceblink.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-04-28 22:03:07 +02:00
Copyright (C) 1984, 1989-1990, 2000-2015, 2018-2021 Free Software Foundation,
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, either version 3 of the License, or
(at your option) any later version.
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.
You should have received a copy of the GNU General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>. */
/* As a special exception, you may create a larger work that contains
part or all of the Bison parser skeleton and distribute that work
under terms of your choice, so long as that work isn't itself a
parser generator using the skeleton or a modified version thereof
as a parser skeleton. Alternatively, if you modify or redistribute
the parser skeleton itself, you may (at your option) remove this
special exception, which will cause the skeleton and the resulting
Bison output files to be licensed under the GNU General Public
License without this special exception.
This special exception was added by the Free Software Foundation in
version 2.2 of Bison. */
/* DO NOT RELY ON FEATURES THAT ARE NOT DOCUMENTED in the manual,
especially those whose name start with YY_ or yy_. They are
private implementation details that can be changed or removed. */
#ifndef YY_YY_HOME_ARTHUR_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED
# define YY_YY_HOME_ARTHUR_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED
/* Debug traces. */
#ifndef YYDEBUG
# define YYDEBUG 0
#endif
#if YYDEBUG
extern int yydebug;
#endif
/* Token kinds. */
#ifndef YYTOKENTYPE
# define YYTOKENTYPE
enum yytokentype
{
YYEMPTY = -2,
YYEOF = 0, /* "end of file" */
YYerror = 256, /* error */
YYUNDEF = 257, /* "invalid token" */
CHIP = 258, /* CHIP */
DEVICE = 259, /* DEVICE */
REGISTER = 260, /* REGISTER */
ALIAS = 261, /* ALIAS */
REFERENCE = 262, /* REFERENCE */
ASSOCIATION = 263, /* ASSOCIATION */
BOOL = 264, /* BOOL */
STATUS = 265, /* STATUS */
MANDATORY = 266, /* MANDATORY */
BUS = 267, /* BUS */
RESOURCE = 268, /* RESOURCE */
END = 269, /* END */
EQUALS = 270, /* EQUALS */
HEX = 271, /* HEX */
STRING = 272, /* STRING */
PCI = 273, /* PCI */
PNP = 274, /* PNP */
I2C = 275, /* I2C */
CPU_CLUSTER = 276, /* CPU_CLUSTER */
CPU = 277, /* CPU */
DOMAIN = 278, /* DOMAIN */
IRQ = 279, /* IRQ */
DRQ = 280, /* DRQ */
SLOT_DESC = 281, /* SLOT_DESC */
SMBIOS_DEV_INFO = 282, /* SMBIOS_DEV_INFO */
IO = 283, /* IO */
NUMBER = 284, /* NUMBER */
SUBSYSTEMID = 285, /* SUBSYSTEMID */
INHERIT = 286, /* INHERIT */
PCIINT = 287, /* PCIINT */
GENERIC = 288, /* GENERIC */
SPI = 289, /* SPI */
USB = 290, /* USB */
MMIO = 291, /* MMIO */
GPIO = 292, /* GPIO */
MDIO = 293, /* MDIO */
FW_CONFIG_TABLE = 294, /* FW_CONFIG_TABLE */
FW_CONFIG_FIELD = 295, /* FW_CONFIG_FIELD */
FW_CONFIG_OPTION = 296, /* FW_CONFIG_OPTION */
FW_CONFIG_PROBE = 297, /* FW_CONFIG_PROBE */
PIPE = 298, /* PIPE */
OPS = 299 /* OPS */
};
typedef enum yytokentype yytoken_kind_t;
#endif
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
union YYSTYPE
{
struct device *dev;
struct chip_instance *chip_instance;
char *string;
device + util/sconfig: introduce new device `gpio` Introduce a new device `gpio` that is going to be used for generic abstraction of gpio operations in the devicetree. The general idea behind this is that every chip can have gpios that shall be accessible in a very generic way by any driver through the devicetree. The chip that implements the chip-specific gpio operations has to assign them to the generic device operations struct, which then gets assigned to the gpio device during device probing. See CB:48583 for how this gets done for the SoCs using intelblocks/gpio. The gpio device then can be added to the devicetree with an alias name like in the following example: chip soc/whateverlake device gpio 0 alias soc_gpio on end ... end Any driver that requires access to this gpio device needs to have a device pointer (or multiple) and an option for specifying the gpio to be used in its chip config like this: struct drivers_ipmi_config { ... DEVTREE_CONST struct device *gpio_dev; u16 post_complete_gpio; ... }; The device `soc_gpio` can then be linked to the chip driver's `gpio_dev` above by using the syntax `use ... as ...`, which was introduced in commit 8e1ea52: chip drivers/ipmi use soc_gpio as gpio_dev register "bmc_jumper_gpio" = "GPP_D22" ... end The IPMI driver can then use the generic gpio operations without any knowlege of the chip's specifics: unsigned int gpio_val; const struct gpio_operations *gpio_ops; gpio_ops = dev_get_gpio_ops(conf->gpio_dev); gpio_val = gpio_ops->get(conf->bmc_jumper_gpio); For a full example have a look at CB:48096 and CB:48095. This change adds the new device type to sconfig and adds generic gpio operations to the `device_operations` struct. Also, a helper for getting the gpio operations from a device after checking them for NULL pointers gets added. Successfully tested on Supermicro X11SSM-F with CB:48097, X11SSH-TF with CB:48711 and OCP DeltaLake with CB:48672. Change-Id: Ic4572ad8b37bd1afd2fb213b2c67fb8aec536786 Tested-by: Johnny Lin <Johnny_Lin@wiwynn.com> Tested-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: Patrick Rudolph <siro@das-labor.org> Signed-off-by: Michael Niewöhner <foss@mniewoehner.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/48582 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de>
2020-12-11 21:26:02 +01:00
uint64_t number;
};
typedef union YYSTYPE YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define YYSTYPE_IS_DECLARED 1
#endif
extern YYSTYPE yylval;
int yyparse (void);
#endif /* !YY_YY_HOME_ARTHUR_SRC_COREBOOT_UTIL_SCONFIG_SCONFIG_TAB_H_SHIPPED_INCLUDED */