Age | Commit message (Collapse) | Author |
|
Change-Id: I12ebed30de4df9814ccb62341c7715fc62c7f5b9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Signed-off-by: Pratik Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-on: https://review.coreboot.org/23431
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Harcuvar is the board name, Denverton is the SoC. So macros in files under
soc/ should be named after the SoC not the board.
Change-Id: I1c7d5b93fba386b8e9bd86cf599508e642e21a75
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23404
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Shine Liu <shine.liu@intel.com>
Reviewed-by: Vanny E <vanessa.f.eusebio@intel.com>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The scratch registers in northbridge used for storing the top of
cacheable memory are volatile. Use the BiosRam storage in the FCH
instead.
TEST=Suspend and resume Kahlee with complete S3 patch stack
BUG=b:69614064
Change-Id: Ieb3cfd173c70bf899a6391d62d1df87b38485f30
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/22726
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The spi_flash_cmd_read_fast() and spi_flash_cmd_read_slow() were just
passing full size buffers to the spi controller ops. However, the
code wasn't honoring what the spi controller can actually perform.
This would cause failures to read on controllers when large requests
were sent in. Fix this by introducing a
spi_flash_cmd_read_array_wrapped() function that calls
spi_flash_cmd_read_array() in a loop once the maximum transfer size is
calculated based on the spi controller's settings.
BUG=b:65485690
Change-Id: I442d6e77a93fda411cb289b606189e490a4e464e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23444
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
Both early platform information reporting in bootblock and common code
CPU driver will add support for cannonlake D0 stepping processor.
BUG=None
TEST=Boot up system with D0 stepping CPU installed, check serial log
that can display as D0 stepping.
Change-Id: I76ee974ee027100d7853a110f95b1601987492e4
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/23350
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
If not, legacy COM ports will be enumerated by kernel and console will
not work.
localhost ~ # cat /proc/tty/driver/serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0
1: uart:16550A mmio:0xC112D000 irq:4 tx:764 rx:0 RTS|DTR
2: uart:16550A mmio:0xC112F000 irq:6 tx:0 rx:0
3: uart:unknown port:000002E8 irq:3
With this fix:
0: uart:16550A mmio:0xC112D000 irq:4 tx:0 rx:0
1: uart:16550A mmio:0xC112F000 irq:6 tx:858 rx:42 RTS|DTR
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
Change-Id: Iac5bf65900e090d4e785e0cd828272ebff209458
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/23219
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change the BiosRam read/write functions to use the fixed MMIO range at
0xfed80500. This is faster than two accesses per byte when using I/O
0xcd4/0xcd5.
Note that BiosRam may only be accessed byte-by-byte. It does not decode
normally.
Change-Id: I9d8baf2bd5d9d48a87bddfb6a0b86e292a8fdf7d
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/23436
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
This uses the functions in include/mrc_cache.h instead of
northbidge/intel/common/mrc_cache.h
Tested working on Lenovo Thinkpad x220, mrc_cache region gets written
and S3 resume still works fine.
Change-Id: I46002c0b19a55d855286eb8b0ca934ef7ca7fe09
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/22982
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change adds _PRW property to CREC device that allows Linux kernel
to identify CREC as a wakeup source.
BUG=b:69118395
TEST=Verified following steps:
1. Under sys devices for CREC: "echo enabled > wakeup"
2. Lid close/Lid open -- Verified that wakeup_count increases
3. Mode change -- Verified that wakeup_count increases
Change-Id: Ib0a687e171c7e5c81325b39f47c9a2462553fe3e
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/23399
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Fix the values that were off by one.
This was discovered when using postcar stage that prints with
debuglevel BIOS_NEVER.
Change-Id: I73a077950ed0dc735d89c9747a8da0a25f30822d
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/23186
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
According to SMBIOS Reference Specification (1)
section 7.18.5 Memory Device — Extended Size
When the size cannot be represented in the size field, it must be set to
0x7fff and the real size stored in the extended_size field.
1: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.1.1.pdf
Change-Id: Idc559454c16ccd685aaaed0d60f1af69b634ea2e
Signed-off-by: Julien Viard de Galbert <jviarddegalbert@online.net>
Reviewed-on: https://review.coreboot.org/23396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This change configures unused pins as not connected.
Change-Id: I6779d9fba73da8fb2faa08ad5d2236b813105720
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/23416
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
This change updates the camera power enable GPIOs as per the latest
schematics. With this update, since one of the enable GPIOs is using a
UART0 pin, set UART0 to PchSerialIoSkipInit in devicetree so that
FSP-S does not re-configure the UART0 GPIOs.
BUG=b:68964831
Change-Id: I5d9126ed8ca2b714f6276f4d3a24c243d7654774
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/23414
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Configure GPP_H12 as an input for PCH_WP_OD.
BUG=b:72202352
BRANCH=none
TEST=none
Change-Id: Ie5b60644a24d745add4d0d38c1421974b8a0017b
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Reviewed-on: https://review.coreboot.org/23389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The following two patches were independent, but they were
merged together. However, the first one changed the API
that the second was originally was written against. Fix build.
b94a2750 (i2c/designware: reduce API complication for bus config)
13101a7b (soc/amd/stoneyridge: Add I2C devicetree support)
BUG=b:72121803
Change-Id: I3678a8f414572dd2227c42ce5585daf6bc933df5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23445
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The TSC rate is empirically swinging during early boot. That
leaves timestamps and udelay()s to not be correct. To rectify this
stop using TSC for all of these time sources. Instead use the
performance TSC which is at a fixed 100MHz clock. That provides
stable time sources and legit timestamps.
BUG=b:72378235,b:72170796
Change-Id: Ia2693c415c557aac687bcb48ee69358ea1c53d67
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23424
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Some x86 platforms don't have a TSC that is invariant w.r.t.
rate to get accurate timestamps. As such a different timestamp
is required. Therefore, allow one to specify non-TSC timestamp
source and not compile in the default x86 TSC code.
BUG=b:72378235,b:72170796
Change-Id: I737fcbba60665b3bc2b5864269536fda78b44d90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
If GENERIC_UDELAY is selected don't try to use UDELAY_IO as there
will be a udelay() conflict at link time.
BUG=b:72378235,b:72170796
Change-Id: I9e01c9daddd0629ecc38a809889b39a505c0e203
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
In order to fully utilize GENERIC_UDELAY in smm and postcar
the udelay() implementation needs to be included. Do that.
BUG=b:72378235,b:72170796
Change-Id: Ia20c1ed41ee439bb079e00fb7bd9c1855e31e349
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Right now dw_i2c_get_soc_cfg() is expecting the SoC to implement
that callback for obtaining the bus config. However, we're currently
forcing another parameter of struct device so one can do the lookup.
This works for Intel-based systems since the struct device was needed
to program the BAR, etc. However, from an API standpoint, it just
complicates matters by needing to obtain the struct device. The SoC
already has knowlege of its own devices so it can get the config
itself by bus number. Therefore, remove that contraint from the API.
BUG=b:70232394
Change-Id: Id8558f5deedda0963a46a532a7bf984e168fb270
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23420
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This commit adds support for an Elan touchscreen device connected over
I2C via devicetree.
BUG=b:72121803
TEST=Confirm the device is probed for.
Change-Id: Ia9e427dbeab9088f77e3cd751b561f7b9a8cb400
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23408
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
I2C bus configuration is generally set up in devicetree.cb. This change
establishes listings for the buses so that they can be used (though
followup changes should update the buses to have correct timings).
BUG=b:72121803
Change-Id: I2b12c82d2bab42ab470aa207880be8876e7cb75f
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23407
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This is required to add support for I2C devices on Kahlee to ACPI tables
via devicetree.cb. Without this, operations are not emitted for I2C
devices and the proper ACPI table entries are not generated.
BUG=b:72121803
Change-Id: I1cfe12f3cc23e90ec74b739678f5a5a73257c2c2
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This commit establishes the stoneyridge implementation for i2c entries
in the devicetree.cb file.
BUG=b:72121803
Change-Id: I0d923609bd8fce94c9aee401a5ae2811281b60e5
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23405
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This commit adds device name to ACPI name bindings for various entries
in the devicetree.
BUG=b:72121803
Change-Id: I5564e4a7e56fdd1bc9f34497bdb78383093a2ba3
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23417
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Chrome OS reports that "GRUNT TEST XXXX" is an invalid hwid. The 8296
comes from the lower four numbers from running:
$ printf "%d\n" 0x$(crc32 <(echo -n 'GRUNT TEST'))
BUG=b:72436450
Change-Id: Ib0044442396cad65c25c107feb35a30a2f70b769
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23411
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add support for a mmio resource in the devicetree to allow
memory-mapped IO addresses to be assigned to given values.
AMD platforms perform a significant amount of configuration through
these MMIO addresses, including I2C bus configuration.
BUG=b:72121803
Change-Id: I5608721c22c1b229f527815b5f17fff3a080c3c8
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23319
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
3rdparty/blobs was updated to move northbridge/amd/00670F00 contents into
soc/amd/stoneyridge. Now soc/amd/stoneyridge/Kconfig needs to be updated
to use VBIOS.bin new location.
BUG=b:70785272
TEST=Update 3rdparty/blobs master branch, try to build kahlee. It should
fail. Update soc/amd/stoneyridge/Kconfig, try to build kahlee again, it
should work (need to rebuild .config first).
CQ-DEPEND=CL:881709
Change-Id: I8cb9874eedc4a5d41d42b3f727c6d3cb9b920b5a
Signed-off-by: Richard Spiegel <richard.spiegel@silverbackltd.com>
Reviewed-on: https://review.coreboot.org/23398
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Rename the device ID macros as per the skylake PCH H external design
specification.
Change-Id: I4e80d41380dc1973d02bc69ac32aad5c4741a976
Signed-off-by: V Sowmya <v.sowmya@intel.com>
Reviewed-on: https://review.coreboot.org/23381
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This change disables SATA controller in order to make SATA IP enter
low power status.
BUG=b:72332817
TEST=cat /sys/kernel/debug/pmc_core/pch_ip_power_gating_status
and verify SATA IP enters low power state
Change-Id: I72a98bc3d0b47aebc0d7be534f4a7503084b257f
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://review.coreboot.org/23354
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Add config option SOC_ESPI in glkrvp Kconfig. This is to disable LPC
and enable eSPI instead.
TEST=Boot to OS
Change-Id: I3116b656d41d1d7719c254888d1e3640628a97ca
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/22626
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
This moves the call to pch_enable_lpc() from romstage to bootblock.
In other words, it happens earlier in the boot process. Turns out, we
need this to talk to the EC to determine if we're in recovery mode or
not.
BUG=b:69011806
TEST=boots to linux
Change-Id: I899bf343d705fe19a2978917bc88990495ebb5a3
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://review.coreboot.org/23401
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This adds coreboot device tree entries on zoombini & meowth for the
cr50. Also, fixes the GPIO pin IRQ settings to be falling edge. This
is based on what we do for fizz.
BUG=b:71722449
TEST=booted to linux on meowth: tpm_version command now sees the cr50.
localhost ~ # tpm_version
TPM 2.0 Version Info:
Chip Version: 2.0.0.0
Spec Family: 322e3000
Spec Family String: 2.0
Spec Level: 0
Spec Revision: 116
Manufacturer Info: 43524f53
Manufacturer String: CROS
Vendor ID: xCG fTPM
TPM Model: 00000001
Firmware Version: 0ad551830bcf7a82
localhost ~ # uname -a
Linux localhost 4.14.13 #3 SMP PREEMPT Sat Jan 13 02:55:45 PST 2018 x86_64 Genuine Intel(R) CPU 0000 @ 1.00GHz GenuineIntel GNU/Linux
localhost ~ #
and we see interrupts when talking to the cr50:
localhost ~ # grep cr50 /proc/interrupts ; tpm_version ; grep cr50 /proc/interru
pts
84: 4687 IO-APIC 84-edge cr50_spi
TPM 2.0 Version Info:
Chip Version: 2.0.0.0
Spec Family: 322e3000
Spec Family String: 2.0
Spec Level: 0
Spec Revision: 116
Manufacturer Info: 43524f53
Manufacturer String: CROS
Vendor ID: xCG fTPM
TPM Model: 00000001
Firmware Version: 0ad551830bcf7a82
84: 4799 IO-APIC 84-edge cr50_spi
localhost ~ #
Change-Id: I9d503334502503ef49515e4a8736d967bc454a98
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://review.coreboot.org/23310
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
|
|
BUG=b:71839089
TEST=
1. emerge-nami coreboot chromeos-bootimage
2. powerd_dbus_suspend
3. touch touchpad to wakeup system
4. localhost ~ # cat /var/log/eventlog.txt
| 2018-01-21 17:01:59 | S0ix Enter
| 2018-01-21 17:02:04 | S0ix Exit
| 2018-01-21 17:02:04 | Wake Source | GPIO | 80
Change-Id: Ie550cfa3f7b5fd105f89c16076d428743392d0e4
Signed-off-by: Van Chen <van_chen@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/23363
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The FSP 2.0 Memory_Info_HOB for KBL is not sending
"MemoryType" value as what is required for SMBIOS Table
according to SMBIOS Spec. Thus, converting the value
retrieved from FSP HOB to the correct value.
This change will not be required for upcoming SOCs since
FSP have fixed this issue in its next platforms and thus it
will take care and send the correct value in "MemoryType"
field based on SMBIOS spec. Thus this conversion from coreboot
will not be required in the next platfoms. "MemoryType" value
can be directly passed to dimm_info_fill() function.
BUG=none
BRANCH=none
TEST=Tested in Soraka, and getting the value as 0x1D for
LPDDR3 memory. dmidecode (latest version 3.1) Command Type 17
will also show correct information. Currently, it was showing
"Unknown".
Change-Id: I75d6cca464680a88bf836e25bf5440a9cdbc738e
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/23384
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
The CAR APIs already exist to deal with proper type useage.
Don't open code things that already exist.
BUG=b:65485690
Change-Id: I09593401513f6060a30cf5c02c94d14afbe8f4fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
Clean up the extra DRIVERS_I2C_GENERIC
BUG=None
TEST=None
Change-Id: Ida32b6f99c40c022aa8548f7353abf1d60ba4ddf
Signed-off-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/23380
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The TSC has been observed to be ticking at a non-constant rate
in early boot. The root cause is still not known, but this
misbehavior necessitates an alternative monotonic timer source.
Use the perf TSC which ticks at 100 MHz. This also means the
timestamp table is not accurate as well. Root cause of TSC rate
instability needs to be resolved in order to fix that.
BUG=b:72170796
Change-Id: Ie052169868a9d9f25f8cc0ce8dd8251b560e671f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23397
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
|
|
For the internal eMMC to be used by non-chrome for installation,
the CARD device and _RMV methods are required. Without these,
other OSes does not show the eMMC as a valid installation target.
TEST= boot CNL-RVP with Tiano payload and install Windows 10
to the internal eMMC drive.
Change-Id: Icfdccd88bc113d97c2fabf4c63d8d772737a6057
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/23314
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Solution: To do an additional config read to the SD controller
after the controller has been power gated (put to D3)
Change-Id: Ia2438c767332b0e2d413c71b06b052bf9ab4a96c
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/23313
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Solution: To do an additional config read to the eMMC controller
after the controller has been power gated (put to D3)
Change-Id: Ieac939c9108e84ba6c7c26b1a49aaf829d8456b7
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/23312
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In ramstage the device_operations are needed for the i2c designware
host controller. Move the intel/common/block/i2c implementation
into the generic driver so other platforms can take advantage of it.
BUG=b:72121803
Change-Id: Id249933fadcc016bfba00e7a6d65f56dfc220724
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
|
|
Rename the following functions to ensure it's clear that the designware
i2c host controller driver is the one that these functions are
associated with:
i2c_get_soc_cfg() -> dw_i2c_get_soc_cfg()
i2c_get_soc_early_base() -> dw_i2c_get_soc_early_base()
i2c_soc_devfn_to_bus() -> dw_i2c_soc_devfn_to_bus()
i2c_soc_bus_to_devfn() -> dw_i2c_soc_bus_to_devfn()
BUG=b:72121803
Change-Id: Idb7633b45a0bb7cb7433ef5f6b154e28474a7b6d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23371
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
If one wants to implement both i2c_bus.h and i2c_simple.h APIs
the compilation unit needs to be guarded or coordinated carefully
with different compilation units. Instead, name the i2c_bus
functions with _dev such that it indicates that they operate on
struct device. One other change to allow i2c_bus.h to be built in
non-ramstage environments is to ensure DEVTREE_CONST is used for
the dev field in struct bus.
BUG=b:72121803
Change-Id: I267e27e62c95013e8ff8b0728dbe9e7b523de453
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Change-Id: If5a72786d1119908073488c1d6d8787ac0f4f95c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/23276
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Id4e05941122c8756f15d5d24482e4cdc04215c55
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/23275
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: Ie472092f8926231f4e1bd1fb12839b532b4ad158
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/23279
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch adds AC and DC loadline settings since vr_config_enable is
set. Without correct AD/DC loadline settings, VRs reported incorrect
VID values which caused CPU freqency clipping. The clipping reason
could be retrieved from MSR 0x64F. From VRTT report, the AC/DC
loadline resistances are within spec, we can use default value defined
in Table 6-1, doc #543977.
BUG=b:70646304
BRANCH=None
TEST=emerge-fizz coreboot chromeos-bootimage & Read AC/DC loadline
settings from DCI to ensure the values were programmed correctly.
Change-Id: Id0ce29fa5726ca3711aa4c822fb123e2de7bc48f
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.com>
Reviewed-on: https://review.coreboot.org/23349
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
|
|
Audio DMIC_DATA needs to be ON in S0ix to support Wake on Voice.
By doing this, SoC can see the DMIC DATA and use for WoV processing.
Thus configuring GPIO_173 as IGNORE IOSSTATE.
TEST=put DUT in S0ix, verify DUT wakes up
Change-Id: I8bf403564e927deb8fed7f415e334bb230107cb0
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Reviewed-on: https://review.coreboot.org/23246
Reviewed-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Tune I2C params for I2C bus 5 to ensure that the frequency does not
exceed 400KHz.
BUG=b:65058277
BRANCH=None
TEST=Measured bus frequency for audio <= 400MHz
Change-Id: I18bca023a6a0fe21e6f46f8688264d3c04d77f25
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://review.coreboot.org/23359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|