These two functions try to access arrays of lengths 32 and 64 at indices
of at most 259 and 71 (respectively). Something here is seriously wrong.
This code was introduced in 2007, and aside from cosmetic changes, has
had no modifications since then. I don't know what this code is supposed
to do, and asking around on IRC, no one else did either. Until someone
has the interest and time to work on it, let's at least add a die() to
prevent the out of bounds access and alert the user that something is
wrong.
Change-Id: I5fc15a50a9f0e97add31e3a40da82a15f7427358
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Found-by: Coverity CID 12296{79-82}
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
This patch is not actually disabling HECI1 as it requires a dedicated FSP UPD
for WHL/CML SoC code to set this HECI1 chip config.
Change-Id: Ia88f3315a9dc3365d0acc13ed887e7c596c97c91
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33194
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch provides an additional option to skip HECI function
disabling using SMM mode for WHL and CML platform, where FSP has
dedicated UPD to make HECI function disable.
User to select HECI_DISABLE_USING_SMM if FSP doesn't provided dedicated
UPD.
Right now CNL and ICL platform will use HECI_DISABLE_USING_SMM kconfig
to make HECI disable and WHL/CML has to rely on FSP to make HECI
disable.
Change-Id: If3b064f3c32877235916f966a01beb525156d188
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33193
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
As per Icelake EDS PCI device B:D:F (0:0x1f:0) referred as ESPI,
hence modify SoC code to reflect the same.
This patch replaces all SoC specific PCI LPC references with ESPI
except anything that touches intel common code block.
Change-Id: I4990ea6d9b7b4c0eac2b3eea559f5469f086e827
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33190
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Lean Sheng Tan <lean.sheng.tan@intel.com>
No C_ENVIRONMENT_BOOTBLOCK support for Braswell is available.
Enable support and add required files for the Braswell Bootblock in C.
The next changes are made support C_ENVIRONMENT_BOOTBLOCK:
- Add car_stage_entry() function bootblock-c_entry() functions.
- Specify config DCACHE_BSP_STACK_SIZE and C_ENV_BOOTBLOCK_SIZE.
- Add bootblock_c_entry().
- Move init from car_soc_XXX_console_init() to bootblock_soc_XXX_Init()
Removed the unused cache_as_ram_main() and weak car_XXX_XXX_console_init()
BUG=NA
TEST=Booting Embedded Linux on Facebook FBG-1701
Building Google Banos
Change-Id: Iab48ad72f1514c93f20d70db5ef4fd8fa2383e8c
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/29662
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Recovery path should finalize work context, and trim
vboot_working_data buffer_size. Otherwise, depthcharge ingests
the full 12 KB workbuf in recovery path.
BUG=chromium:972528, b:134893812
TEST=Build with vboot_reference CL:1584488. Check that USB disks
are properly verified in recovery path.
BRANCH=none
Change-Id: Icf2600d2eb5d846a26aec35a153946dd2f7f128c
Signed-off-by: Joel Kitching <kitching@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33358
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Disable dynamic clock gating for the community cr50's IRQ lives on.
That IRQ is pulsed very quickly, and with clock gating enabled pulses
tend to be missed. This is expecially true on the default 0.0.22
firmware that cr50 comes with out of the factory.
BUG=b:130764684 b:130338605
BRANCH=None
TEST=Boot hatch with cr50 "intap" firmware that can vary the pulse width,
observe that even with sub-microsecond pulses no IRQs are missed.
Change-Id: I34d14fb7cc97e33eecfda2c99cc53a541c87662d
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Evan Green <evgreen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33326
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
It was determined through testing that 16MB of reserved VRAM is
sufficient. Additional RAM for the graphics driver is allocated out
of system memory.
BUG=b:123579702
TEST=Boot Grunt, watch VRAM usage with graphics driver logging.
Change-Id: I44b640f015b45c0dc3d701929549f3a1082a9268
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33368
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The prototype of vprintk() is currently declared unconditionally, which
prevents it from being used in situations where the console is disabled.
The code will compile correctly, but not link, since the definition in
console.c isn't being provided. This adds a shim around the declaration
so that, like printk(), a call to vprintk() in this situation will expand
to a no-op function instead.
Change-Id: Ib4a9aa96a5b9dbb9b937ff45854bf6a407938b37
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33181
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
die() currently only accepts a fixed message string, which is rather
inconvenient when there is extra information that would be helpful to
print in the error message. This currently requires an extra call to
printk(), which is somewhat awkward:
printk(BIOS_EMERG, "Bad table, opcode %d at %d", id, i);
die(""); // what do I say here?
die() already has a printk() inside it to print the error message, so
let's just make it variadic to combine the two.
die("Bad table, opcode %d at %d", id, i); // much better
Forwarding variadic arguments from one function to another is rather
tricky, so die_with_post_code() is redefined as a variadic macro
instead.
Change-Id: I28b9eac32899a1aa89e086e0d3889b75459581aa
Signed-off-by: Jacob Garber <jgarber1@ualberta.ca>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33153
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Keith Short <keithshort@chromium.org>
This patch removes all possible dependencies in order to build platform
with CONFIG_RAMPAYLOAD enable(without ramstage).
A. Create coreboot separate stage kconfigs
This patch creates seperate stage configs as below
1. HAVE_BOOTBLOCK
2. HAVE_VERSTAGE
3. HAVE_ROMSTAGE
4. HAVE_POSTCAR
5. HAVE_RAMSTAGE
B. Also ensures below kconfigs are aligned with correct stage configs
1. COMPRESS_RAMSTAGE and RELOCATABLE_RAMSTAGE are now enable if
CONFIG_HAVE_RAMSTAGE is selected.
2. COMPRESS_BOOTBLOCK will enable if CONFIG_HAVE_BOOTBLOCK is set
3. COMPRESS_PRERAM_STAGES will enable if CONFIG_HAVE_VERSTAGE
|| CONFIG_HAVE_ROMSTAGE is selected.
C. Also fix compilation issue with !CONFIG_HAVE_RAMSTAGE
On x86 platform:
Case 1: ramstage do exist: CONFIG_HAVE_RAMSTAGE=1
>> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_x86_32
Case 2: ramstage doesn't exist: CONFIG_HAVE_RAMSTAGE=0
>> rmodules_$(ARCH-ramstage-y) will evaluate as rmodules_
This patch fixes Case 2 usecase where platform doesn't select
CONFIG_HAVE_RAMSTAGE.
Also add option to create sipi_vector.manual based on $(TARGET_STAGE)
variable.
$(TARGET_STAGE)=ramstage if user selects CONFIG_HAVE_RAMSTAGE
$(TARGET_STAGE)=postcar if user selects CONFIG_RAMPAYLOAD
Change-Id: I0f7e4174619016c5a54c28bedd52699df417a5b7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33142
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a method for the soc/amd/<product> to indicate what AcpiMmio
ranges are supported. Induce a build error if soc or mainboard
code is added which attempts to use an unsupported block.
This patch attempts to dissuade accessing unsupported blocks without
requiring the complexity of structures or reinitializing at the
beginning of a new stage.
TEST=boot grunt, force build errors by removing blocks in iomap.h
BUG=b:131682806
Change-Id: I2121df108fd3caf07e5588bc3201bcdd8dcaaa00
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32934
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
This patch adds support for the Dual SPI feature (SDR 2-bit in Qualcomm
terminology) to the QSPI controller.
Change-Id: I7aed2ccd9627f5de5dd760b418f74d56d2c031d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33284
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch adds support to read SPI flash in Dual SPI mode, where both
MISO and MOSI lines are used for output mode (specifically Fast Read
Dual Output (0x3b) where the command is still sent normally, not Fast
Read Dual I/O (0xbb) whose additional benefit should be extremely
marginal for our use cases but which would be more complicated to
implement). This feature needs to be supported by both the flash chip
and the controller, so we add a new dual_spi flag (and a new flags field
to hold it) to the spi_flash structure and a new optional xfer_dual()
function pointer to the spi_ctrlr structure. When both are provided,
Dual SPI mode is used automatically, otherwise things work as before.
This patch only adds the dual_spi flag exemplary to all Winbond and
Gigadevice chips, other vendors need to be added as needed.
Change-Id: Ic6808224c99af32b6c5c43054135c8f4c03c1feb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33283
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
All SPI flash chip drivers currently in coreboot use the generic read
functions (spi_flash_cmd_read_fast()/_slow()) as their read callback.
The only use case for specialized read callbacks we have left is with
specialized flash controllers like Intel fast_spi (which sort of
impersonate the flash chip driver by implementing their own probe
function).
This patch unifies the behavior for all normal flash drivers by making
the read callback optional and letting them all fall back to a default
read implementation that handles normal fast/slow reading. Most of the
drivers used to install the respective callback after checking
CONFIG_SPI_FLASH_NO_FAST_READ, but some hardcoded either slow or fast
writes. I have found no indications for why this is and spot-checked
datasheets for affected vendors to make sure they all support both
commands, so I assume this is just some old inaccuracy rather than
important differences that need preserving. (Please yell if you
disagree.)
Also take the opportunity to refactor some of the common spi_flash.c
code a bit because I felt there are too many nested functions that don't
really do enough on their own, and centralizing stuff a bit should make
it easier to follow the code flow. (Some of this is in preparation for
the next patch.)
Change-Id: I2096a3ce619767b41b1b0c0c2b8e95b2bd90a419
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch changes the Gigadevice SPI flash driver to adopt the same
structure packing improvements for the hardcoded parameters of
individual chips that was implemented for Winbond last year. This cuts
the size of the hardcoded info nearly in half and should save us a few
hundred bytes in every stage.
Change-Id: I9910dcb9b649f51b317f3f8fcba49e5e893f67d2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33285
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The SPI transfer speed logging in cbfs_spi is super useful, doesn't get
in the way (just adding one line per stage, essentially) and should have
no notable overhead. Let's enable it by default for the BIOS_DEBUG log
level rather than having to recompile to get it.
Also fix an issue with building this code on MIPS due to lack of 64-bit
division primitives. (This means MIPS and arm32 board may display
incorrect results when reading more than 4MB in a single transfer, which
sounds very unlikely.)
Change-Id: I03c77938afe01fdcecf917e8c4c25cc29cdc764e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33281
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Add support for generating IndexField, which is similar to Field.
Change-Id: If66a627e64953696b0b68488256bd5c141e4c205
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33032
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
One variant is asking for support for 16G 2666 LPDDR3, so adding
generic SPD for that.
BUG=b:133455595
BRANCH=None
TEST=None as this is not being used yet
Change-Id: If16a101119aabc30d6ea83e95e9ded2e089a982d
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33274
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
One variant is asking for support for 8G 3200 DDR4, so adding generic
SPD for that.
BUG=b:132920013
BRANCH=None
TEST=None as this is not being used yet
Change-Id: I89cd3287aaf0baf384c4fe82d0881b0c48e09753
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33258
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Skip GT specific programming in coreboot to support early
parts without GT enable.
Change-Id: I231e13367cbfbafbfb0cb4235487dbcbcae76820
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33189
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Ronak Kanabar <ronak.kanabar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The RAMPAYLOAD symbol added by 7e893a02c0 (Kconfig: Create RAMPAYLOAD
kconfig) is shown unconditionally for all x86 systems. It generally
creates a lot of confusion to prompt for something that isn't imple-
mented or not working. So guard it with another Kconfig that can be
selected by platforms that actually support it.
Change-Id: I6d158382d1000b8b40ca1368e2efff0c39884f15
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33263
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
* Select ONBOARD_VGA_IS_PRIMARY in driver/lenovo/hybrid_graphics to fix
disabling iGPU in 'Dual Graphics' on Lenovo T430.
* Remove ONBOARD_VGA_IS_PRIMARY in mainboards that already select
DRIVERS_LENOVO_HYBRID_GRAPHICS.
Change-Id: I6594fbb957c9a8135fe670d38b5755adf29d2dff
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33254
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
* Move the contents of iommu.c to early_init.c.
* Name the functions like done in intel/soc/common.
* Move PAMx register setup to own function
Preparations for integration in soc/intel/common/*
Tested on Lenovo T520 (Intel Sandy Bridge).
Still boots to OS, no errors visible in dmesg.
Change-Id: I3ec395bf6722bceb84316e92733dcfcd7a093639
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32068
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Remove the Return statement within the PS0, PS3 methods. PS0/3 are not
allowed to return anything. Even an empty return will be resolved to
Return(Null). In order to be conform with the specification, the code
has been refactored to remove the return statements.
Change-Id: I7b4820e8dd40a9169a7facce67282b8af5af67af
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33293
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add Skylake C236 to the PCH Table. The one which was already in there is
actually the CM236 and not the C236. This can be checked in datasheet:
100-series-chipset-datasheet-vol-1 p. 25.
Change-Id: I435927f15e9d3219886375426b09c68632dfe3d9
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33248
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
This change adds support for the UCSI specification in order to
provide information about the Type-C port and an interface to
perform power and data role swap.
This change is split across the DSDT and SSDT, with the shared
memory and operation region declared in the SSDT after being
allocated in CBMEM.
The OS will fill in the registers in the system memory region and
then call the _DSM method wtih a read or write argument. The DSM
method will copy the required registers to/from the system memory
and the EC and perform the write or read action.
Responses from the EC will generate a new SCI with event code 0x79
which will notify this UCSI ACPI device and the OS driver will take
action to read status from the EC.
BUG=b:131083691
Change-Id: I438a2bdfaf6720acd8354e0339dcef2844b63a4e
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The USB Type-C Connector System Software Interface (UCSI) defines a
required memory oregion for the OS UCSI driver to use to communicate
with the BIOS and EC.
This provides a CBMEM ID that can be used by drivers to allocate this
shared memory region for the UCSI driver to use.
BUG=b:131083691
Change-Id: Id5b7fa19436443bc11a6ebe3ce89cd552cee4d85
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32356
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The SD controller seems to take some time after restarting
the clock at 1.8V before it actually switches from 3.3V to
1.8V. Add a _DSM method that simply sleeps when switching
between 3.3V and 1.8V. Otherwise, the kernel times out too
quickly waiting for the card to acknowledge the 1.8V switch.
The card itself is waiting until it sees the clk signal being
driven at 1.8V.
BUG=b:125441242
TEST=Boot Hatch with SD card and CR2 removed, observe voltage
switch succeeds.
Change-Id: I15090ed9f9bc90b35dfcba47c913e3d37b799d0b
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Signef-off-by: Evan Green <evgreen@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33233
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
These are documented in the Intel Datasheet entitled
"6th Generation Intel® Processor Datasheet for S-Platforms"
"6th Generation Intel® Processor Datasheet for H-Platforms" (Volume 2)
Without them, coreboot fails to properly inform the payload of the
amount of available memory.
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Change-Id: I5b810c6415c4aa0404e5fa318d2c8db292566b8a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33286
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: ron minnich <rminnich@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The values are generated from the respective VBTs.
Change-Id: Ic74e9dac898c17ce64a94b06682997a39daeff69
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30247
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Thomas Heijligen <src@posteo.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Logs from Linux' i915 suggest that not even the FSP/GOP takes proper
care of this. The sequence is mostly the same as on older platforms,
with a slightly different configuration of the backlight PWM.
We light the panel up with 50% PWM duty cycle. This often results in
an already rather high perceived brightness, but shouldn't be too
blinding.
Change-Id: I762a77c8df023a4c14af502af5edfeeb961da1ae
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/30246
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Modify the 16 and 32 bit BIOS RAM access functions that had been
originally moved from stoneyridge. This was suggested in the
review of
69486cac7: Create AcpiMmio functionality from stoneyridge
Change-Id: I5b491da6f263cbab2b549301e16a7e19896f2428
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32932
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Document the AcpiMmio individual blocks better. This is in response
to a request in gerrit for
69486cac7: Create AcpiMmio functionality from stoneyridge
Correct comments that were inadvertently left in place from older
patches.
Change-Id: I4c16a866de5622e8cfbd3a08816b9d3182950d0e
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/32931
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Jacob Garber