Currently bootblock does not initialize eSPI if it is already done in
PSP verstage. But some other component is clobbering the eSPI
configuration causing timeouts in EC communication after the boot flow
hits x86. To workaround this issue, re-initialize eSPI in bootblock.
BUG=b:217414563
TEST=Build and boot to OS in Skyrim with PSP verstage.
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Change-Id: I41c0b2816a106a6a547f3cb372693e1bb7f23734
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66443
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This adds a default early GPIO table in the case of us not being
able to identify a valid board ID.
Primarily, this is useful in the case of EC issues to ensure
that debug interfaces (e.g. UART) are always up and available.
BUG=b:238165977
TEST=Boots and no errors on simics
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I135dc6c29bc23195afe5c78eb79992691652d9e4
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66394
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Some PCI capabilities should only be enabled if it is available not
only on a device, but also all bridge upstream of it. Checking only
the device and the bridge just above it may not be enough.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I1237d3b4b86dd0ae5eb586e3c3c407362e6ca291
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66383
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
'parent_cap' should be found from 'parent' instead of 'dev'.
Signed-off-by: Bill XIE <persmule@hardenedlinux.org>
Change-Id: I99dab83d90287ca924d30dc4aeac0ff96e877e5c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
1. Add active policy
2. Set critical policy trigger point to 105C
3. Correct TSR location
BUG=b:240634844
TEST=emerge-draco coreboot
values provided and verified by thermal team
Change-Id: I0d91bad03cbdeea5c84b533580ac98072ce0110b
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66351
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
PERST# is supposed to be de-asserted in GC6 exit, but the original
patch used the CTXS Method, which drives a GPIO low, instead of
STXS, because PERST# is active-low. This patch fixes that.
BUG=b:214581763
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: Ib0adb8efe5e2cc733ae2228614c58c124ba3f11b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66402
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
The lid sensor is on a daughterboard which can cause unintended
shutdowns when not connected. Disable lid sensor based shutdown behavior
in depthcharge until we have a better solution.
BUG=b:240005819
BRANCH=firmware-brya-14505.B
TEST=booted ghost, no longer shuts down due to missing lid sensor
Change-Id: I69f70255dee1b69e05b112c0174f5f52d1368837
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66295
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Support for feature "In-Band ECC" not available for Tiger Lake
Similar to Elkhart Lake, Tiger Lake also provides this feature.
Ported from Elkhart Lake (CB:55668)
Bug = N/A
TEST = Build and boot Siemens AS-TGL1
Change-Id: Ie54d5f6a9747fad0105d0f8bf725be611bb8cf60
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
The POWERCONTROL and PLATPOLICY NVJT subfunctions were incorrectly set
to 2 and 3, respectively. While looking at the ACPI code, Nvidia noticed
these are supposed to be 3 and 4, also respectively, so this patch fixes
that.
BUG=b:214581763
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Change-Id: I0f808aba7072b943ee2fad20e06ff39a9b54903d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
BUG=b:240624460
TEST=None
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I8542c9bb624a366bc1bb01f6eae66ba97520d19c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66381
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Configure the rcomp, dqs and dq tables based on the schematic
dated July 17/2022 and Intel Kit #573387.
TEST=Built successfully
Signed-off-by: Tarun Tuli <taruntuli@google.com>
Change-Id: I092f42db252052382d377a4ae48dc25f73080a3b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66202
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds `_DEPRECATED_` tag to ChromeOS boot mode related event
logging types as below:
* ELOG_TYPE_CROS_RECOVERY_MODE <---- to record recovery boot reason
while booting into recovery mode
* ELOG_TYPE_CROS_DEVELOPER_MODE <--- if the platform is booted into
developer mode.
* ELOG_TYPE_CROS_DIAGNOSTICS <---- if the platform is booted into
diagnostic mode.
Drop static structure `cros_deprecated_recovery_reasons` as it has been
replaced by vb2_get_recovery_reason_string() function.
ELOG_TYPE_FW_BOOT_INFO event type is now used to record all those
related fw boot info along with ChromeOS boot mode/reason etc.
BUG=b:215615970
TEST=Build and boot google/kano to ChromeOS.
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: I932952ce32337e2d54473667ce17582a90882da8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/65802
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
When GPP_B2 output high, there is a leakage path. This patch fix it by
setting the pin NC.
BUG=b:233959105
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot
Change-Id: I3c833d5d62c715960dcb27494a0b9b93c91e8f2f
Signed-off-by: Robert Chen <robert.chen@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66382
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Building firmware for Brya is currently broken due to the RO_FWID region
for adlrvp_m_ext_ec bloating past 64 characters.
The CONFIG_MAINBOARD_PART_NUMBER is catenated onto the
CONFIG_MAINBOARD_VENDOR string, which for Intel, makes for a very long
trunk string that the kernel version will then be added to form the
RO_FWID string. For Intel, that trunk string is already pretty long at :
"Intel Corporation_Alder Lake Client Platform".
Shortening the CONFIG_MAINBOARD_PART_NUMBER should address this issue
for now.
BUG=b:241273391
TEST="emerge-brya coreboot chromeos-bootimage" and verify it builds
successfully
Change-Id: Ie862c87dd9a24743f249f1b10862ca6f3295db23
Signed-off-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Bora Guvendik <bora.guvendik@intel.com>
This function is only called from the same compilation unit, so turn it
into a static function.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I5c2deaa46f69c763df9612e39415b37c60d631be
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Check return value of cbfs_truncate_space() in cbfs_truncate().
Remove return from cbfs_image_from_buffer() to inform about invalid
image region when incorrect offset header was provided.
Also change header offset provided to mentioned function in
cbfs_expand_to_region() and cbfs_truncate_space() from zero
to HEADER_OFFSET_UNKNOWN, as they do not support images with cbfs master
header.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Ib009212692fb3594a826436df765860f54837154
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66334
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use 0x016llx to print device resource info so that both 64bit and
32bit resources could be displayed correctly.
Signed-off-by: Gang Chen <gang.c.chen@intel.com>
Change-Id: I0ec4c47cca4a09ceb7dc929efaa5630b1f9df81c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66324
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
The check was recently removed to allow callers to pass `count == 0`.
Dereferencing the `msg` array is invalid in that case, though. Linux,
where we borrowed the i2c interface from, also treats this with -EINVAL.
Change-Id: I1eec02dd3a3fcf2d477a62cc65292fca40e469d3
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
We actually want the bus driver to process the 1 zero-length write
we are passing. So set the count to 1.
Change-Id: I5a41abb68c27a83715b6baec91ece9fa90b66a8c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Tested-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66337
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Some definitions are the same in dramc_soc.h for MT8192, MT8195 and
MT8186, so we move them to dramc_soc_common.h
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I3095333e62abf98de1f2d27033baeeba7a4cad79
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66276
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
- Retrieve the SKU ID for Geralt via CBI interface. If that failed
(or no data found), fall back to ADC channels for SKU ID.
- The RAM code is implemented by the resistor straps that we can read
and decode from ADC.
TEST=build pass
BUG=b:236331724
Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com>
Change-Id: I31626e44bd873a3866c9bd1d511b476737f15a20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66275
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new config FSP_TYPE_IOT to add the IoT FSP option so that
respective mainboard Kconfig can use IoT FSP if needed.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I01d891348c039269138e64290ae3d6ec75d3c687
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66367
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
The latest master adds the missing MemInfoHob.h to IOT ADL-P &
ADL-S folders.
Signed-off-by: Lean Sheng Tan <sheng.tan@9elements.com>
Change-Id: I8ef998b2e414d3d63494e6177b4fde2dc26e9d55
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66366
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Set tcc_offset value to 3 in devicetree for Thermal Control Circuit
(TCC) activation feature. This value is suggested by Thermal team.
BUG=b:240600260
TEST=emerge-draco coreboot
verified by thermal team
Change-Id: I3044643d52f1d6e883beb3ec87a77f32d086f46c
Signed-off-by: Tony Huang <tony-huang@quanta.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66252
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
UFS storage devices require the bRefClkFreq attribute to be set to
operate correctly in high speed mode. The correct value is determined by
what the SoC / board supports. For the ADL UFS controller, it is
19.2 MHz.
a) Introduce a new ACPI property "ref-clk-freq".
b) Add support to configure this property using an SoC Kconfig.
Kernel patch:
https://web.archive.org/web/20220801060732/https://lore.kernel.org/all/
20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeid/
BUG=b:238262674
TEST=Build,boot Nirwen and dump SSDT entries and check that the kernel
correctly parses ref-clk-freq as 19.2 MHz.
Scope (\_SB.PCI0)
{
Device (UFS)
{
Name (_ADR, 0x0000000000120007) // _ADR: Address
Name (_DDN, "UFS Controller") // _DDN: DOS Device Name
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
/* Device Properties for _DSD */,
Package (0x01)
{
Package (0x02)
{
"ref-clk-freq",
0x0124F800
}
}
})
}
}
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Change-Id: I80c338a8a61f161b0feb6c5a3ca00cf5e0cfb36c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66051
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Switching off the pads of the internal crystal oscillator that connect
to the crystal on the board in S0i3 saves a little power, so enable it.
No measurements to quantify the power savings have been made. PPR #57243
revision 1.59 was used as a reference.
BUG=b:237647468
TEST=None
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I52f14ae5c614ad8ff0479b619de7164afa1e7648
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66336
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
- Add support for edp aux read and write.
- Update edp panel properties based on edid read.
- Configure edp controller and edp phy.
Panel details:
Manufacturer: SHP Model 1523 Serial Number 0
Made week 53 of 2020
EDID version: 1.4
Digital display
8 bits per primary color channel
DisplayPort interface
Maximum image size: 31 cm x 17 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
Default (sRGB) color space is primary color space
First detailed timing is preferred timing
Supports GTF timings within operating range
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 5a8780a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 346500 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Did detailed timing
Hex of detail: 653880a070384d403020350035ae10000018
Detailed mode (IN HEX): Clock 144370 KHz, 135 mm x ae mm
0780 07b0 07d0 0820 hborder 0
0438 043b 0440 0485 vborder 0
-hsync -vsync
Hex of detail: 000000fd003090a7a7230100000000000000
Monitor ranges (bare limits): 48-144Hz V, 167-167kHz H, max dotclock
350MHz
Hex of detail: 000000fc004c513134304d314a5734390a20
Monitor name: LQ140M1JW49
Changes in V2:
- Remove Misc delays in edp code.
- Move mdss soc code to disp.c
- Update EDID read using I2C write & read.
Changes in V3:
- Remove unrelated delays.
- Misc changes.
BUG=b:182963902,b:216687885
TEST=Validated on qualcomm sc7280 development board.
Monitor name: LQ140M1JW49
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Change-Id: If89abb76028766b19450e756889a5d7776106f95
Reviewed-on: https://review.coreboot.org/c/coreboot/+/61342
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Shelley Chen <shchen@google.com>
This patch adds a function to calculate best rational approximation
for a given fraction and unit tests for it.
Change-Id: I2272d9bb31cde54e65721f95662b80754eee50c2
Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66010
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
gcc 12 fails the build with the warning below:
CC romstage/lib/cbfs.o
src/lib/cbfs.c: In function 'switch_to_postram_cache':
src/lib/cbfs.c:31:32: error: comparison between two arrays [-Werror=array-compare]
31 | if (_preram_cbfs_cache != _postram_cbfs_cache)
| ^~
src/lib/cbfs.c:31:32: note: use '&_preram_cbfs_cache[0] != &_postram_cbfs_cache[0]' to compare the addresses
Instead of following gcc’s suggestion, disable the warning for gcc as
requested by Julius [1]:
> Can we just set -Wno-array-compare instead? There's nothing illegal
> about that expression and as we can see in this case, there are
> perfectly reasonable cases where you might want to do something like
> that. On the other hand, I don't really see a realistic scenario where
> this warning could prevent a real problem (anyone who doesn't know
> that array1 == array2 doesn't compare the array elements in C
> shouldn't have any business submitting code to coreboot).
[1]: https://review.coreboot.org/c/coreboot/+/62827/1
Found-by: gcc-12 (Debian 12-20220313-1) 12.0.1 20220314 (experimental) [master r12-7638-g823b3b79cd2]
Found-by: gcc (Debian 12.1.0-7) 12.1.0
Change-Id: I322f7cc57dcca713141bddaaaed9ec034898754d
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66105
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
A DDR5 DIMM internally has two channels each of width 32 bit.
But the total physical channel width is 64 bit.
BUG=b:180458099
TEST=Boot DDR5 to kernel
Signed-off-by: Meera Ravindranath <meera.ravindranath@intel.com>
Change-Id: Ic5e9c58f255bdf86a68ce90a4f853bf4e7c7ccfe
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52730
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Follow latest schematic, GPP_A17 is used to enable AMP power.
BUG=b:240006200
BRANCH=firmware-brya-14505.B
TEST=Check I2C scan can see the AMP return ACK.
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: Ia6c52302a12ddec68303714ac07e96a65a8f8fb8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66325
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jack Rosenthal <jrosenth@chromium.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Use the new "detect" method instead of "probed". Fixes an uncommon issue
where i2c-hid fails to initialize the device on Linux.
Tested on: gaze15, gaze16-3060, lemp10, oryp8
Tested:
- Linux: Touchpad works across 50 reboots
- Windows: Touchpad is still detected as an I2C HID device
- Windows: Extra I2C HID devices are not shown in Device Manager
Change-Id: I6a899c64a6d77b65a2ae57ab8df81cd84b568184
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66129
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
the missing `; \` at the end of the line meant subsequent lines
were no longer run from $project_dir, so Logo.bmp was silently
failing to restore. This led to the working dir being dirty,
and on subsequent runs, any change to a different branch in the
same repo would fail.
Change-Id: I17a323bc2dda19b69d809e398b273f24e14b43af
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66321
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Copy the constraint from ADL-S to ADL-P.
Fixes the following warning in Linux on System76 oryp9, which has an
NVIDIA GPU on the bridge.
pcieport 0000:00:01.0: can't derive routing for PCI INT A
This, in turn, resolves an IRQ conflict with the PCH HDA device that
would cause a stack track on every boot.
irq 10: nobody cared (try booting with the "irqpoll" option)
<snip>
[<00000000bf549647>] azx_interrupt [snd_hda_codec]
Disabling IRQ #10
Change-Id: I550c80105ff861d051170ed748149aeb25a545db
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/66285
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Karthikeyan Ramasubramanian