This allows mainboards using an I2C bus to communicate with the cr50
to reuse the functionality related to firmware version and BOARD_CFG.
BUG=b:202246591
TEST=boot on brya0, see cr50 FW version in logs
Change-Id: Ide1a7299936193da3cd3d15fdfd1a80994d70da0
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/62059
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Turns out 200ms still isn't enough in the worst reset conditions.
There's been some reports of failures at 200ms with some older
cr50 versions. Let's not take any chances and bump this way up
since if this fails, it prevents boot.
BUG=b:213828947
BRANCH=None
TEST=Reboot and suspend_stress on Nipperkin
Signed-off-by: Rob Barnes <robbarnes@google.com>
Change-Id: I5be0a80c064546fd277f66135abc9d0572df11cb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61864
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Now that the console system itself will clearly differentiate loglevels,
it is no longer necessary to explicitly add "ERROR: " in front of every
BIOS_ERR message to help it stand out more (and allow automated tooling
to grep for it). Removing all these extra .rodata characters should save
us a nice little amount of binary size.
This patch was created by running
find src/ -type f -exec perl -0777 -pi -e 's/printk\(\s*BIOS_ERR,\s*"ERROR: /printk\(BIOS_ERR, "/gi' '{}' ';'
and doing some cursory review/cleanup on the result. Then doing the same
thing for BIOS_WARN with
's/printk\(\s*BIOS_WARNING,\s*"WARN(ING)?: /printk\(BIOS_WARNING, "/gi'
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I3d0573acb23d2df53db6813cb1a5fc31b5357db8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61309
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Lance Zhao
Reviewed-by: Jason Glenesk <jason.glenesk@gmail.com>
The speed control bits of the Designware I2C controller are bits 1 and 2
in the control register, so the values should be written as number
shifted by the number of the first bit. The resulting constant is
identical.
TEST=Timeless build for amd/chausie results in identical binary
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id0881dfcd7703ab6a70a9b1a355d5a93771aebc6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61591
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Using enum cb_err as return type instead of int improves the readability
of the code. This commit only changes the return value of the static
functions in this file keeping the external interface identical.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I80300e0b24591fc660c3134139b9257e002cdbbb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Turns out 150ms isn't enough in the worst reset conditions. On guybrush
the TPM is reset in S0i3 and the CR50 is allowed to hibernate. The CR50
is woken up and initialized early during S0i3 resume. Occasionally the
CR50 isn't ready before the probe times out.
BUG=b:213828947
BRANCH=None
TEST=suspend_stress_test -c 1000
Change-Id: Ifda438080cf1ad2796c7061223a6a97b8e6e9987
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61104
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Keith Short <keithshort@chromium.org>
Introduce firmware-power-managed DSD ACPI property for TPM devices.
This property can be checked by the kernel TPM driver to override how
the TPM power states are managed. This is a tri-state flag, true,
false, or unset. So an enum used to keep the flag is unset by default.
When firmware-power-managed is true, the kernel driver will not send a
shutdown during s2idle/s0i3 suspend.
BUG=b:200578885
BRANCH=None
TEST=TPM shutdown is triggered on s0ix suspend on guybrush with patched
kernel
Change-Id: Ia48ead856fc0c6e637a2e07a5ecc58423f599c5b
Signed-off-by: Rob Barnes <robbarnes@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/59479
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Since the OS provides its own driver for the I2C controller it can
choose to use a bus speed other than the one used at coreboot runtime.
In this case it would be good to provide a way how the needed bus
timings are communicated to the OS, since these are very board-specific
and there is no way that the OS can know them other than read the
appropriate ACPI reported timings.
This patch adds some code to report additional bus speed timings if
there are some defined in the devicetree.
Change-Id: If921e0613864660dc1bb8d7c1b30fb9db8ac655d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55088
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
In commit b64db833d6 a basic ACPI support was added to the driver.
With this support an SSDT-entry is created for this RTC and it is now
visible to the OS via ACPI. In Linux the PNP-devices, which are
reported over ACPI, are scanned rather early and if the entry is found,
the device is claimed even if there is no driver available yet.
In this case, when the native RTC-driver without ACPI-support is loaded
and tries to register this device, the RTC is already blocked by the
PNP-drivers and cannot be used anymore. This leads to a non-usable RTC
on kernels where the needed ACPI-extension is not yet merged into the
RTC driver.
This patch provides a way to disable the ACPI-support for the RTC if
needed.
Change-Id: Ic65794d409d13a78d17275c86ec14ee6f04cd2a6
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/55003
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
HSBIAS_SENSE_EN configures HSBIAS output current sense through
the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce
the potential pop noise during the headset plug out slowly. But on some
platforms ESD voltage will affect it causing test to fail, especially
with CTIA headset type. For different hardware setups, a designer might
want to tweak default behavior.
Signed-off-by: Vitaly Rodionov <vitaly.rodionov@cirrus.corp-partner.google.com>
Change-Id: I87c6f01af1bdb5b1cb8e399191519598d7fbe9ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52981
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If device is supported as a wake source, _S0W should be set to D3hot.
This ensures that the device is put into D3hot by the OSPM.
Power resource(PRIC) for the device is listed in both _PR0 and _PR3. Thus, it ensures that the OSPM does not turn off power resource when device is put into D0 and D3hot. Hence, it is capable of waking the system from D3hot state. However, if it is put into D3cold, then the power resource is turned off by the OSPM.
The devices we are currently looking at for touchscreen/touchpad
do not really support auxiliary power and so do not support wake from D3cold.
BUG=b:186070097
TEST=build and check device wake state _S0W set to 3 in ssdt table.
Change-Id: I34e4b2350875530d3337be700276bcc4fb1f810a
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52847
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Inspired by discussion in CB:22822.
If I2C bus step response has not been measured, assume the layout to
have been designed with a minimal capacitance and SCL rise and fall
times of 0 ns. The calculations will add the required amount of
reference clocks for the host to drive SCL high or low, such that the
maximum bus frequency specification is met.
Change-Id: Icbafae22c83ffbc16c179fb5412fb4fd6b70813a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52723
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This adds a driver for the TI TAS5825M smart amplifier [1].
The driver expects the mainboard using it to define tas5825m_setup(),
which uses the tas5825m_* functions to set configuration data. Each
mainboard may have very different configuration data, depending on
its audio hardware.
Tested on System76 addw1, bonw14, oryp5, and oryp6.
[1]: https://www.ti.com/product/TAS5825M
Signed-off-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Change-Id: I896e8f272f18e64bfc90f406e7d4163010800aaf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/43614
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current driver is using chip registers map to configure the SAR
sensor, which is opaque, especially when the datasheet is not published
widely.
Use more descriptive names, as defined in Linux kernel documentation at
https://www.kernel.org/doc/Documentation/devicetree/bindings/iio/proximity/semtech%2Csx9310.yaml
BUG=b:173341604
BRANCH=volteer
TEST=Dump all tables, check semtech property:
for i in $(find /sys/firmware/acpi/tables/ -type f) ; do
f=$(basename $i); cat $i > /tmp/$f.dat ; iasl -d /tmp/$f.dat
done
In SSDT.dsl, we have:
Package (0x06)
{
Package (0x02)
{
"semtech,cs0-ground",
Zero
},
Package (0x02)
{
"semtech,startup-sensor",
Zero
},
Package (0x02)
{
"semtech,proxraw-strength",
Zero
},
Package (0x02)
{
"semtech,avg-pos-strength",
0x0200
},
Package (0x02)
{
"semtech,combined-sensors",
Package (0x03)
{
Zero,
One,
0x02
}
},
Package (0x02)
{
"semtech,resolution",
"finest"
}
}
Change-Id: I8d1c81b56eaeef1dbb0f73c1d74c3a20e8b2fd7b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In commit 2609eaaa8f (src/drivers/i2c/rx6110sa: Omit _HID temporarily)
the randomly assigned and therefore wrong ACPI ID for RTC RX6110SA was
removed. In the meantime Seiko-Epson did a great job and registered an
official vendor ID in the ACPI database [1]. Further on, Seiko-Epson
has now assigned the unique Product Identifier for the RX6110SA, which
is '6110'. The assignment of the Product Identifier is controlled by
the vendor and there is no official database where this ID is stored
in. It is up to the vendor to make sure that this ID stays unique.
This patch adds this new vendor and product ID to the driver. Together
with a pending Linux patch this RTC is now useable as ACPI device in
Linux.
[1] https://uefi.org/ACPI_ID_List?search=SECC
Change-Id: I45838162f014a760520692c6dcaae329ad98547d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51176
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Johannes Hahn <johannes-hahn@siemens.com>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DRIVER_I2C_TPM_ACPI is used to enable the "driver" needed for coreboot
to present a TPM node in the devicetree. It would usually only do so,
if coreboot itself is communicating with the TPM via I2C (I2C_TPM).
However, technically, there is no dependency.
In order to not show the ACPI option in menuconfig if the board is not
using I2C, a dependency was declared in Kconfig. However, the same can
be achieved without making it an error to manually declare
DRIVER_I2C_TPM_ACPI without I2C_TPM.
For Volteer, we have just such a need, since it has two "sub-variants"
sharing the same overridetree.cb, one having SPI TPM and another having
I2C TPM. The former will have a disabled ACPI node representing the I2C
TPM, while its Kconfig is such that coreboot itself does not have I2C
TPM support.
In order to export even a disabled ACPI node representing the I2C
connected TPM, coreboot needs DRIVER_I2C_TPM_ACPI. Hence, that will
have to be enabled in a case where coreboot does not have I2C_TPM (for
one of the two sub-variants, namely volteer2).
BUG=b:173461736
TEST=Tested as part of next CL in chain
Change-Id: I9717f6b68afd90fbc294fbbd2a5b8d0c6ee9ae55
Signed-off-by: Jes Bodi Klinke <jbk@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48222
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current HID "RX6110SA" does not comply with the ACPI spec in terms
of the naming convention where the first three caracters should be a
vendor ID and the last 4 characters should be a device ID. For now
there is a vendor ID for Epson (SEC) but there is none for this
particular RTC. In order to avoid the reporting of a non ACPI-compliant
HID it will be dropped completely for now.
Once Epson has assigned a valid HID for this RTC, this valid HID will be
used here instead.
Change-Id: Ib77ffad084c25f60f79ec7d503f14731b1ebe9e2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47706
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When the host sends data in i2c bus, device might not send ACK. It means
that data is not processed on the device side, but for now we don't
check for that condition thus wait for the response which will not come.
Designware i2c detect such situation and set TX_ABORT bit. Checking for
the bit will enable other layers to immediately retry rather than
wait-timeout-retry cycle.
BUG=b:168838505
BRANCH=zork
TEST=test on zork devices, now we see "Tx abort detected" instead of I2C
timeout for tpm initializtion.
Change-Id: Ib0163fbce55ccc99f677dbb096f67a58d2ef2bda
Signed-off-by: Kangheui Won <khwon@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch adds basic ACPI support for the RTC so that the OS is able to
use this RTC via the ACPI interface.
If the Linux kernel is able to find the RTC in ACPI scope, you should
see the following lines in dmesg, where [n] is an enumerated number:
rx6110 i2c-RX6110SA:00: rtc core: registered RX6110SA:00 as rtc[n]
rtc rtc[n]: Update timer was detected
Change-Id: I9b319e3088e6511592075b055f8fa3e2aedaa209
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
