The call made at mp_ops.post_mp_init() generally
uses four different names. Unify these with followups.
smm_southbridge_enable(SMI_EVENTS)
smm_southbridge_enable_smi()
hudson_enable_smi_generation()
enable_smi_generation()
Furthermore, some platforms do not enable power button
SMI early. It may be preferred to delay the enablement,
but fow now provide global_smi_enable_no_pwrbtn() too.
Change-Id: I6a28883ff9c563289b0e8199cd2ceb9acd6bacda
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Attempts to write to APM_CNT IO port should always be guarded
with a test to verify SMI handler has been installed.
Immediate followup removes redundant HAVE_SMI_HANDLER tests.
Change-Id: If3fb0f1a8b32076f1d9f3fea9f817dd4b093ad98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41971
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
cbmem is not online when vboot runs before the bootblock. Update the
macro to reflect that.
BUG=b:158124527
TEST=Build & boot psp_verstage on trembyle
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I6fb4ad04f276f2358ab9d4d210fdc7a34a93a5bb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42066
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
When adding XIP stages on x86, the -P parameter was used to
pass a page size that covers the entire file to add. The same
can now be achieved with --pow2page and we no longer need to
define a static Konfig for the purpose.
TEST: Build asus/p2b and lenovo/x60 with "--pow2page -v -v" and
inspect the generated make.log files. The effective pagesize is
reduced from 64kB to 16kB for asus/p2b giving more freedom
for the stage placement inside CBFS. Pagesize remained at 64kB
for lenovo/x60.
Change-Id: I5891fa2c2bb2d44077f745619162b143d083a6d1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41820
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Keith Hui <buurin@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
• Based on FSP EAS v2.1 – Backward compatibility is retained.
• Add multi-phase silicon initialization to increase the modularity of the
FspSiliconInit() API.
• Add FspMultiPhaseSiInit() API
• FSP_INFO_HEADER changes
o Added FspMultiPhaseSiInitEntryOffset
• Add FSPS_ARCH_UPD
o Added EnableMultiPhaseSiliconInit, bootloaders designed for
FSP 2.0/2.1 can disable the FspMultiPhaseSiInit() API and
continue to use FspSiliconInit() without change.
FSP 2.2 Specification:
https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html
Change-Id: If7177a267f3a9b4cbb60a639f1c737b9a3341913
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41728
Reviewed-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to the comments of
https://review.coreboot.org/c/coreboot/+/41719
, which is about Microcode patch for amd/picasso.
Change the code with the same way.
The changes include:
1. combine the microcode_xxx.c and update_microcode.c
into one source.
2. Redefine the microcode updating function to eliminate
the parameter. Get the revision ID in the black box.
Reduce the depth of function calls.
3. Get the revision ID by bitwise calculation instead of
lookup table.
4. Reduce the confusing type casts.
5. Squash some lines.
We do not change the way it used to be. The code assume
only one microcode is integrated in CBFS. If needed in future,
41719 is the example of integrating multiple binaries.
And, 41719 depends on the definition in this patch.
Change-Id: I8b0da99db0d3189058f75e199f05492c4e6c5881
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42094
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This MSR is used for detecting if the micro code is applied
successfully.
Change-Id: I060eb1a31f3358341ac0d5b9105e710c351f2ce8
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42212
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
For the sake of completeness, we should provide these operations.
Change-Id: Ia28af94ec86319c7380d8377f7e24e5cdf55dd9c
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42145
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Only Winbond parts seem to support making status register writes
volatile. So this flag should not be exposed in the generic interface.
Change-Id: Idadb65ffaff0dd7809b18c53086a466122b37c12
Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41746
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
A function pci_dev_disable_bus_master() is created. This function
can be used to disable Thunderbolt PCIe root ports, bridges and
devices for Vt-d based security platform at end of boot service.
BUG=None
TEST=Verified PCIe device bus master enable bit is cleared.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: Ie92a15bf2c66fdc311098acb81019d4fb7f68313
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Advertising SMI triggers in FADT is only valid if we exit with
SMI installed. There has been some experiments to delay SMM
installation to OS, yet there are new platforms that allow some
configuration access only to be done inside SMM.
Splitting static HAVE_SMI_HANDLER variable helps to manage cases
where SMM might be both installed and cleared prior to entering
payload.
Change-Id: Iad92c4a180524e15199633693446a087787ad3a2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There have been changes to the way device properties are supported
in Linux[1] and Windows[2] which add flexibilty:
- non-standard UUIDs can be used instead of only ACPI_DP_UUID
- support for multiple different packages within the _DSD that
associate different properties with unique UUIDs.
To handle this I extracted the part that does the write of UUID and
properties to a separate function and defined a new PACKAGE type
which has the custom UUID as a name and can be used the same way that
child properties are today.
For example a PCIe root port for a USB4 port has a standard property
indicating the USB4 reference, and then two custom properties which
are defined for different attributes.
Example code:
/* Create property table */
acpi_dp *dsd = acpi_dp_new_table("_DSD");
acpi_dp_add_reference(dsd, "usb4-port", usb4_path);
/* Add package for hotplug */
acpi_dp *pkg = acpi_dp_new_table("6211e2c0-58a3-4af3-90e1-927a4e0c55a4");
acpi_dp_add_integer(pkg, "HotPlugSupportInD3", 1);
acpi_dp_add_package(dsd, pkg);
/* Add package for external port info */
pkg = acpi_dp_new_table("efcc06cc-73ac-4bc3-bff0-76143807c389");
acpi_dp_add_integer(pkg, "ExternalFacingPort", 1);
acpi_dp_add_package(dsd, pkg);
/* Write all properties */
acpi_dp_write(dsd);
Resulting ACPI:
Scope (\_SB.PCI0.TRP0)
{
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package ()
{
Package () { "usb4-port", \_SB.PCI0.TDM0.RHUB.PRTA }
},
ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
Package ()
{
Package () { "HotPlugSupportInD3", One }
},
ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package ()
{
Package () { "ExternalFacingPort", One },
}
})
}
[1] https://patchwork.kernel.org/patch/10599675/
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports
Change-Id: I75f47825bf4ffc5e9e92af2c45790d1b5945576e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/42047
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
These build on existing functions but use different object types
in order to provide functions for upcoming changes:
acpigen_write_return_op(): Return an operator.
acpigen_write_if_lequal_op_op(): Check if 2 operands are equal.
acpigen_get_package_op_element(): Read an element from a package
into an operator.
This one just provides the missing helper, the other 3 already exist:
acpigen_get_tx_gpio: Read TX gpio state.
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I1141fd132d6f09cf482f74e95308947cba2c5846
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41985
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The definition of processor_rev_id in struct microcode
is 16 bits. So we need to change the a series of parameters
passing to 16 bits.
Change-Id: Iacabee7e571bd37f3aca106d515d755969daf8f3
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41869
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change introduces a new top-level interface for interacting with a
bitmask providing firmware configuration information.
This is motivated by Chromebook mainboards that need to support multiple
different configurations at runtime with the same BIOS. In these
devices the Embedded Controller provides a bitmask that can be broken
down into different fields and each field can then be broken down into
different options.
The firmware configuration value could also be stored in CBFS and this
interface will look in CBFS first to allow the Embedded Controller value
to be overridden.
The firmware configuration interface is intended to easily integrate
into devicetree.cb and lead to less code duplication for new mainboards
that make use of this feature.
BUG=b:147462631
TEST=this provides a new interface that is tested in subsequent commits
Change-Id: I1e889c235a81545e2ec0e3a34dfa750ac828a330
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There's not a function that is the equivalent to
x86_setup_mtrrs_with_detect() but not solving for above 4GiB.
Provide x86_setup_mtrrs_with_detect_no_above_4gb() which is the
equivalent to x86_setup_mtrrs_with_detect() but instructs the MTRR
solver to not take into account memory above 4GiB.
BUG=b:155426691
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia1b5d67d6f139aaa929e03ddbc394d57dfb949e0
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41897
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Introduce concept of var_mtrr_context object for tracking and
assigning MTRR values. The algorithm is lifted from postcar_loader
code, but it's generalized for different type of users: setting
MSRs explicitly or deferring to a particular caller's desired
actions.
BUG=b:155426691,b:155322763
Change-Id: Ic03b4b617196f04071093bbba4cf28d23fa482d8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41849
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
<types.h> is supposed to provide <commonlib/bsd/cb_err.h>,
<stdbool.h>,<stdint.h> and <stddef.h>. So remove those includes
each time when <types.h> is included.
Change-Id: I886f02255099f3005852a2e6095b21ca86a940ed
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41817
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We want to use the CACHE_ROM_* macros in linker scripts. Avoid
`commonlib/helpers.h` as it contains an ALIGN() macro definition
that conflicts with the ALIGN keyword in linker scripts.
Change-Id: I3bf20733418ca4135f364a3f6489e74d45e4f466
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41785
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The ACPI device sleep states are different from system sleep states
and many places hardcode to specific values that are difficult to
decode without referring to the spec.
Change-Id: If5e732725b775742fd2a9fd0df697e312aa7bf20
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41791
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The USB Type-C Connector Class in the Linux kernel is not specific to
the ChromeOS EC, so this functionality is now split out into a separate
file, acpigen_usb.c. Documentation about the kernel side is available at
https://www.kernel.org/doc/html/latest/driver-api/usb/typec.html.
Change-Id: Ife5b8b517b261e7c0068c862ea65039c20382c5a
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41539
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change adds back CB:39487 which was reverted as part of
CB:41412. Now that the resource allocator is split into old(v3) and
new(v4), this change adds support for allocating resources above 4G
boundary with the new allocator v4.
Original commit message:
This change adds support for allocating resources above the 4G
boundary by making use of memranges for resource windows enabled in
the previous CL.
It adds a new resource flag IORESOURCE_ABOVE_4G which is used in the
following ways:
a) Downstream device resources can set this flag to indicate that they
would like to have their resource allocation above the 4G
boundary. These semantics will have to be enabled in the drivers
managing the devices. It can also be extended to be enabled via
devicetree. This flag is automatically propagated by the resource
allocator from downstream devices to the upstream bridges in pass
1. It is done to ensure that the resource allocator has a global view
of downstream requirements during pass 2 at domain level.
b) Bridges have a single resource window for each of mem and prefmem
resource types. Thus, if any downstream resource of the bridge
requests allocation above 4G boundary, all the other downstream
resources of the same type under the bridge will be allocated above 4G
boundary.
c) During pass 2, resource allocator at domain level splits
IORESOURCE_MEM into two different memory ranges -- one for the window
below 4G and other above 4G. Resource allocation happens separately
for each of these windows.
d) At the bridge level, there is no extra logic required since the
resource will live entirely above or below the 4G boundary. Hence, all
downstream devices of any bridge will fall within the window allocated
to the bridge resource. To handle this case separately from that of
domain, initializing of memranges for a bridge is done differently
than the domain.
Limitation:
Resources of a given type at the bridge or downstream devices
cannot live both above and below 4G boundary. Thus, if a bridge has
some downstream resources requesting allocation for a given type above
4G boundary and other resources of the same type requesting allocation
below 4G boundary, then all these resources of the same type get
allocated above 4G boundary.
Change-Id: I92a5cf7cd1457f2f713e1ffd8ea31796ce3d0cce
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41466
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change moves the resource allocator functions out of device.c
and into two separate files:
1. resource_allocator_v3.c: This is the old implementation of
resource allocator that uses a single window for resource
allocation. It is required to support some AMD chipsets that do not
provide an accurate map of allocated resources by the time the
allocator runs. They work fine with the old allocator since it
restricts itself to allocations in a single window at the top of the
4G space.
2. resource_allocator_common.c: This file contains the functions that can
be shared by the old and new resource allocator.
Entry point into the resource allocation is allocate_resources() which
can be implemented by both old and new allocators. This change also
adds a Kconfig option RESOURCE_ALLOCATOR_V3 which enables the old
resource allocator. This config option is enabled by default
currently, but in the following CLs this will be enabled only for the
broken boards.
Reason for this split: Both the old and new resource allocators need
to be retained in the tree until the broken chipsets are fixed.
Change-Id: I2f5440cf83c6e9e15a5f22e79cc3c66aa2cec4c0
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41442
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
After removal of CAR_MIGRATION there are no more reasons
to carry around ENV_STAGE_HAS_BSS_SECTION=n case.
Replace 'MAYBE_STATIC_BSS' with 'static' and remove explicit
zero-initializers.
Change-Id: I14dd9f52da5b06f0116bd97496cf794e5e71bc37
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40535
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The ALC5682 headset codec can be connected over SoundWire and be
configured for mainboards to use:
- Data Port 0 and Bulk Register Access is supported
- Data Ports 1-4 are supported as both source and sink
The data port and audio mode properties are filled out as best as
possible with the datasheet as a reference.
The ACPI address for the codec is calculated with the information in
the codec driver combined with the devicetree.cb hierarchy where the
link and unique IDs are extracted from the device path.
For example this device is connected to master link ID 0 and has strap
settings configuring it for unique ID 1:
chip drivers/soundwire/alc5682
register "desc" = ""Headset Codec""
device generic 0.1 on end
end
This driver was tested with the volteer reference design by booting
and disassembling the runtime SSDT to ensure that the devices have the
expected address and properties.
Device (SW01)
{
Name (_ADR, 0x000021025D568200)
Name (_DDN, "Headset Codec")
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-bra-mode-0", "BRA0" },
Package () { "mipi-sdw-dp-0-subproperties", "DP0" },
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" },
Package () { "mipi-sdw-dp-1-source-subproperties", "SRC1" },
Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" },
[...]
}
}
Name (BRA0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-bra-mode-bus-frequency-configs",
Package () { 0x000F4240, [...] }
},
[...]
}
}
Name (DP0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-bra-flow-controlled", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-bra-mode-0", "BRA0" }
}
}
Name (MOD0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-audio-mode-bus-frequency-configs",
Package () { 0x000F4240, [...] }
},
[...]
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
}
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I488dcd81d2e66a6f2c269ab7fa9f7ceaf2cbf003
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40891
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The MAX98373 smart speaker amp can be connected over SoundWire and be
configured for mainboards to use:
- Data Port 0 and Bulk Register Access is not supported
- Data Port 1 is the 32bit data input for the speaker path
- Data Port 3 is the 16bit data output for I/V sense ADC path
The data port and audio mode properties are filled out as best as
possible with the datasheet as a reference.
The ACPI address for the codec is calculated with the information in
the codec driver combined with the devicetree.cb hierarchy where the
link and unique IDs are extracted from the device path.
For example this device is connected to master link ID 1 and has strap
settings configuring it for unique ID 3.
chip drivers/soundwire/max98373
register "desc" = ""Left Speaker Amp""
device generic 1.3 on end
end
This driver was tested with the volteer reference design by booting
and disassembling the runtime SSDT to ensure that the devices have the
expected address and properties.
Device (SW13)
{
Name (_ADR, 0x000123019F837300)
Name (_DDN, "Left Speaker Amp")
Method (_STA)
{
Return (0x0F)
}
Name (_DSD, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-sw-interface-revision", 0x00010000 },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" },
Package () { "mipi-sdw-dp-1-sink-subproperties", "SNK1" },
Package () { "mipi-sdw-dp-3-source-subproperties", "SRC3" },
}
}
Name (MOD0, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {
"mipi-sdw-audio-mode-bus-frequency-configs",
Package () { 0x00753000, [...] }
},
[...]
}
}
Name (SNK1, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
Name (SRC3, Package ()
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () { "mipi-sdw-data-port-type", Zero },
[...]
},
ToUUID ("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () {
Package () { "mipi-sdw-port-audio-mode-0", "MOD0" }
}
}
}
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I3f8cb2779ddde98c5df739bd8a1e83a12a305c00
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40890
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change adds a help function to write a SoundWire ACPI address
object that conforms to the SoundWire DisCo Specification Version 1.0
The SoundWire address structure is defined in include/device/soundwire.h
and provides the properties that are used to form the _ADR object.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: I6efbf52ce20b53f96d69efe2bf004b98dbe06552
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40885
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change uses the previously added SoundWire definitions to provide
functions that generate ACPI Device Properties for SoundWire
controllers and codecs.
A SoundWire controller driver should populate
`struct soundwire_controller` and pass it to
soundwire_gen_controller(). This will add all of the defined master
links provided by the controller.
A SoundWire codec driver should populate the necessary members in
struct soundwire_codec and pass it to soundwire_gen_codec().
Several properties are optional and depend on whether the codec itself
supports certain features and behaviors.
The goal of this interface is to handle all of the properties defined
in the SoundWire Discovery and Configuration Specification Version
1.0 so that controller and codec drivers do not need to all have code
for writing standard properties.
Both of these functions also provide a callback method for adding
custom properties that are not defined by the SoundWire DisCo
Specification. These properties may be required by OS drivers but are
outside of the scope of the SoundWire specification itself.
This code is tested with controller, codec, and mainboard
implementations in subsequent commits.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ib185eaacf3c4914087497ed65479a772c155502b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This header implements structures to describe the properties defined in
the SoundWire Discovery and Configuration Specification Version 1.0.
By itself this just provides the property definitions, it is then used
by the code that generates ACPI device properties and by the controller
and codec drivers.
A new header for MIPI vendor/device IDs is also added, with the MIPI
Alliance board members added by default. This will be used in the same
way as pci_ids.h to track devices added to coreboot.
BUG=b:146482091
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Change-Id: Ie9901d26d1efe68edad7c049c98a976c4e4f06f4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This reverts commit 44ae0eacb8.
Reason for revert: Resource allocator patches need to be reverted
until the AMD chipsets can be fixed to handle the resource allocation
flow correctly.
BUG=b:149186922
Change-Id: I90f3eac2d23b5f59ab356ae48ed94d14c7405774
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41412
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Mike Banon <mikebdp2@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds some spd_cache functions. They are for implementing the
spd_cache. It's for reducing the SPD fetch time when device uses SODIMMs.
The MRC cache also includes SPD data, but there is no public header file
available to decode the struct of MRC. So SPD cache is another solution.
BUG=b:146457985
BRANCH=None
TEST=Build puff successfully and verified below two items.
one DIMM save the boot time : 158ms
two DIMM save the boot time : 265ms
Change-Id: Ia48aa022fabf8949960a50597185c9d821399522
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40797
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Edward O'Callaghan <quasisec@chromium.org>
This patch adds the get_spd_sn function. It's for reading SODIMM serial
number. In spd_cache implementation it can use to get serial number
before reading whole SPD by smbus.
BUG=b:146457985
BRANCH=None
TEST=Wrote sample code to get the serial number and ran on puff.
It can get the serial number correctly.
Change-Id: I406bba7cc56debbd9851d430f069e4fb96ec937c
Signed-off-by: Jamie Chen <jamie.chen@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40414
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
CB:41194 got rid of "this file is part of" lines. However, there are
some changes that landed right around the same time including those
lines. This change uses the following command to drop the lines from
new files:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ic3c1d717416f6b7e946f84748e2b260552c06a1b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41342
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Picasso has an LPC and eSPI bridge on the same PCI DEVFN. They can both
be active at the same time. This adds a way to specify which devices
belong on which bus.
i.e.,
device pci 14.3 on # - D14F3 bridge
device espi 0 on
chip ec/google/chromeec
device pnp 0c09.0 on end
end
end
device lpc 0 on
end
end
BUG=b:154445472
TEST=Built trembyle and saw static.c contained the espi bus.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: I0c2f40813c05680f72e5f30cbb13617e8f994841
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41099
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add functionality to use process call cycle. It can be used to
write/read data to/from e.g. EEPROM attached to SMBus Controller
via I2C.
Tested on:
* C246
Change-Id: Ifdac6cf70a4ce744601f5d152a83d2125ea88360
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39875
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
pci_domain_set_resources is duplicated in all the SOCs. This change
promotes the duplicated function.
Picasso was adding it again in the northbridge patch. I decided to
promote the function instead of duplicating it.
BUG=b:147042464
TEST=Build and boot trembyle.
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Iba9661ac2c3a1803783d5aa32404143c9144aea5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41041
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
