| Age | Commit message (Collapse) | Author |
|---|
|
To help identify the licenses of the various files contained in the
coreboot source, we've added SPDX headers to the top of all of the
.c and .h files. This extends that practice to Makefiles.
Any file in the coreboot project without a specific license is bound
to the license of the overall coreboot project, GPL Version 2.
This patch adds the GPL V2 license identifier to the top of all
makefiles in the drivers directory that don't already have an SPDX
license line at the top.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I8442bc18ce228eca88a084660be84bcd1c5de928
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68980
Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
|
|
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO.
There's no reason to require explicit disablement however, so drop the
superfluous 'disable' flag, and change the _CRS generation to check if
the GPIOs will be exported via the 'has_power_resource' flag instead.
This mirrors the change made for drivers/i2c/generic.
TEST=untested, as no boards selected this option.
Change-Id: Icb60502a4a7c5e7a1fcf1ee60e23c77e00d6de7b
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71851
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
In order to support wake from D3cold, most devices require extra
circuitry and possibly out-of-band communications to the host.
Therefore, assume that most UARTs that do have wake capabilities support
wake from D3hot rather than D3cold.
BUG=b:187228954
TEST=compile
Change-Id: I24d6d0e81d980fc9c910d8f47f557c88990b6400
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/56834
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Individual drivers check whether the concerned device is enabled before
filling in the SSDT. Move the check before calling acpi_fill_ssdt() and
remove the check in the individual drivers.
BUG=None
TEST=util/abuild/abuild
Change-Id: Ib042bec7e8c68b38fafa60a8e965d781bddcd1f0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
|
|
As per ACPI spec, GpioIo does not have any polarity associated with
it. Linux kernel uses `active_low` argument within GPIO _DSD property
to allow BIOS to indicate if the corresponding GPIO should be treated
as active low. Thus, if GPIO has active high polarity or if it does
not have any polarity associated with it, then the `active_low`
argument is supposed to be set to 0.
Having a `polarity` field in acpi_gpio seems confusing because GPIOs
might not always have polarity associated with them. Example, in case
of DMIC-select GPIO where 0 means select DMIC0 and 1 means select
DMIC1, there is no polarity associated with the GPIO. Thus, it would
be clearer for mainboard to use macros without having to specify a
particular polarity. In order to enable mainboards to provide GPIO
information without polarity for GpioIo usage, this change also adds
`ACPI_GPIO_OUTPUT` and `ACPI_GPIO_INPUT` macros.
BUG=b:157603026
Change-Id: I39d2a6ac8f149a74afeb915812fece86c9b9ad93
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42968
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This driver generates an ACPI device object for a UART attached device
with all of the expected device support handlers like different interrupt
sources and power control GPIOs.
Example use:
chip drivers/uart/acpi
register "name" = ""UDEV""
register "desc" = ""UART Attached Device""
register "hid" = "ACPI_DT_NAMESPACE_HID"
register "compat_string" = ""google,cros-ec-uart""
register "irq_gpio" = "ACPI_GPIO_IRQ_LEVEL_LOW_WAKE(GPP_C20)"
register "uart" = "ACPI_UART_RAW_DEVICE(115200, 64)"
device generic 0 on end
end
Resulting in this ACPI device:
Device (UDEV)
{
Name (_HID, "PRP0001")
Name (_UID, Zero)
Name (_DDN, "UART Attached Device")
Method (_STA, 0, NotSerialized)
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate ()
{
UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
0x00, LittleEndian, ParityTypeNone, FlowControlNone,
0x0040, 0x0040, "\\_SB.PCI0.UAR2",
0x00, ResourceConsumer, , Exclusive)
GpioInt (Level, ActiveLow, ExclusiveAndWake, PullDefault, 0x0000,
"\\_SB.PCI0.GPIO", 0x00, ResourceConsumer)
{
0x0114
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package (0x01)
{
Package (0x02)
{
"compatible",
"google,cros-ec-uart"
}
}
})
}
Change-Id: Idfd2d9d2ab6990a82ddd401734c0d9b1b0b8f82d
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41793
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
