The exynos manual suggests hooking the mmc ip blocks to the mpll. They had
been set to use a different pll. This changes them over and modifies the
divider so that the frequency stays the same.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I9b473b683c5806a49c9eba91807baa0b58c9c9dd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59732
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit. Saw that depthcharge could talk
to the TPM over i2c.
BRANCH=None
Change-Id: I08c483bf57b17ed923dee0715e1a244ff607bd64
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59731
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This allows us to set different speeds for each HSI2C bus.
BUG=none
BRANCH=none
TEST=using logic analyzer on pit, saw I2C4 run at 1MHz
and I2C9 run at 400KHz
Change-Id: I27bf54084644c4cbcdbed423197a1113d6f6c17b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59693
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This change adjusts some clock settings so that they match U-Boot. There are
three different changes.
1. Change the source for psgen from the oscillator clock to the pclk.
2. Change the pll feeding the SPI busses from epll to mpll, as suggested in
the manual.
3. Change the SPI prescaller.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: I2896c099a91bdb78bfac03fbb804ef65c3233cd0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59730
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The clock divider was being read from registers incorrectly which meant that
the periph rate was wrong.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on pit.
BRANCH=None
Change-Id: Idb38374195a737fac2f096771929c8f1645d7247
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59729
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Wait for UART FIFO to be ready.
(Credit to dhendrix for finding the bits to test with.)
BUG=none
TEST=manually boot device and see no garbage on serial output.
BRANCH=none
Change-Id: Ic921cc39a27b137f1a7fd137e032ffb61489bdd1
Reviewed-on: https://gerrit.chromium.org/gerrit/57660
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
BUG=chrome-os-partner:16957
TEST=None
BRANCH=None
CQ-DEPEND=CL:59674
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Chrome EC protocol V3 has several new command structure and constants defined.
Simply cherry-picking changes from upstream.
BUG=none
TEST=emerge-daisy chromeos-coreboot-snow # build pass
Change-Id: Iaabd90058620e9e4497b701341a4b4ca5027c302
Reviewed-on: https://gerrit.chromium.org/gerrit/59410
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
There's a need to determine if a specific gpio pin is
is set up to be a native function or not. Implement this.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built. Determined LP version worked correctly based off of another
patch.
Change-Id: I91d57a549e0f4fddc0b1849e5f74320fc839642c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59589
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The BIOS spec for LynxPoint calls out additional
programming steps for the PCIe Root Ports. Implement those
steps from the BIOS spec. These steps are completed before
deeper PCIe probing. The "late" programming was removed as
that was applicable to Cougar/Panther point where this
code was originally copied, though there was some overlap.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted. Spot checked some registers. Device
shows up in lspci.
Change-Id: I64f25e4451e035d98ca6b66b0335bd280b70b074
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59558
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
PCIe Root Ports should be disabled based on pin ownership
and the strapping configuration. Implement this logic
for LynxPoint. The chip_ops->enable_dev() path is no
longer used. Instead the PCIe driver handles the enabling
and disabling of devices. This allows for having an empty
or incomplete device tree since those "allocated" devices
do not travel through the chip_ops->enable_dev() path.
The coalescing was tested to be working properly, however
not all configurations were tested.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Booted with different devictree configurations. Coalescing
works.
Change-Id: I1e8bfe5e447b72ff8a4b04b650982d8c1ae0823c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59424
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
... this is needed for libpayload to talk to USB devices.
(forward ported from https://gerrit.chromium.org/gerrit/#/c/55554)
BUG=chrome-os-partner:18635
TEST=Boot on Snow, see EHCI stack find devices
BRANCH=none
Change-Id: I2db8eb30ccc7983e2305b6222f02babf14ddb53f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55811
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
... this is needed for libpayload to talk to USB devices.
BUG=chrome-os-partner:18635
TEST=Boot on Snow, see EHCI stack find devices
BRANCH=none
Change-Id: I663cb560d79e98cd2b767238fd4aec2cd04854e9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/55554
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Don't force dev mode. Allow users to enter / exit dev mode as normal.
TEST=Manual. Build + boot image, test verified boot.
BUG=chrome-os-partner:19636.
Change-Id: I168eb04a8ac102a8c4a1ca8936f78f62b001e0eb
Reviewed-on: https://gerrit.chromium.org/gerrit/59492
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
So far this is used by the USB driver, and instead of
having ifdefs all throughout that code, implement the same
API on x86 and ARM.
BUG=chrome-os-partner:18635
TEST=Boot from USB on Snow
BRANCH=none
Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56105
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
On some systems there may be 2GB SKU that is the same as the
4GB SKU but just one channel of memory. In that case we need
to ensure that both copies of the same SPD source end up
populated by ensuring that repeated entries are included by
using $+ instead of $^.
Alternatively we could do the check inside romstage, but it
is already set to behave this way if the SPD gets populated
correctly.
BUG=chrome-os-partner:20268
BRANCH=none
TEST=manual:
I changed spd_index to 3 in falco romstage to force it to
pretend it was a 2GB config of the same memory, then booted
to ensure it was indeed limited to 2GB.
memcfg channel[0] config (00780008):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 2048 MB width x16 single rank, selected
DIMMB 0 MB width x16 single rank
memcfg channel[1] config (00600000):
ECC inactive
enhanced interleave mode on
rank interleave on
DIMMA 0 MB width x8 single rank, selected
DIMMB 0 MB width x8 single rank
Change-Id: Ibfe5051ccda2fe69e8caff3f3c264116e3411c65
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59483
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Jay Kim <yongjaek@chromium.org>
The SystemAgent contains a mini-hd audio controller at PCI 0:3.0
which uses the same verb table init sequence as the southbridge.
In order to avoid two copies of the verb table loading code I
separated out the HDA verb table functions into a file that can
be re-used and then added a minihd driver to the haswell northbridge.
The minihd verb table is the same across devices so it can live
within the minihd driver rather than needing to be specified in
each separate mainboard.
I also fixed up the driver for lynxpoint HDA by following the
reference code.
BUG=chrome-os-partner:19993
BRANCH=none
TEST=manual: boot into linux and check for mini-hd
Without HDMI cable plugged in driver does not find any codec,
and it does not seem to re-probe when HDMI is connected. We may
be missing kernel patches for this.
hda-intel 0000:00:03.0: no codecs found!
With a basic kernel patch to add 0x0a0c device ID to HDA driver
and with HDMI cable connected it is much happier:
snd_hda_intel 0000:00:03.0: irq 60 for MSI/MSI-X
input: HDA Intel MID HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input9
snd_hda_intel 0000:00:1b.0: irq 61 for MSI/MSI-X
input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input11
Change-Id: Ifa587984be4fc2801704a0368b9cdf8379c2450e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59336
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Add -ffreestanding and -fomit-frame-pointer for all
platforms.
- Add ARMv7 specific flags to the armv7 Makefile
BUG=none
TEST=build, boot depthcharge on ARM and x86
BRANCH=none
Change-Id: I71ab1b096e505940cc20c266bccd43917bcfad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56104
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
On ARMv7 we need to carefully add memory barriers to
all memory read and write operations. This change
brings libpayload in sync with what coreboot is doing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=no functional change
Change-Id: Ie9c30b0f0d30531c5f9d99c2729246a86b8cec26
Reviewed-on: https://gerrit.chromium.org/gerrit/59294
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Otherwise we have to worry about hand off between bootblock and
romstage. Too much complexity
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=none
BRANCH=none
Change-Id: I3979be4b1d67de27275bc7ba4f45131b09a276f0
Reviewed-on: https://gerrit.chromium.org/gerrit/59323
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=Run sudo cbmem -l on Snow w/ coreboot, observe that it finds
CBMEM
BRANCH=none
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
It's done in bootblock_simple.c just after returning from
the mainboard specific bootblock function.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=Boot on Snow
BRANCH=none
Change-Id: I96cab5e406132a9f7dc30d48ff99f524773a1a14
Reviewed-on: https://gerrit.chromium.org/gerrit/58473
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This is already called in ARMv7 bootblock_simple.c so we don't
want to do it twice
BUG=none
TEST=boot on Snow
BRANCH=none
Change-Id: I4e9e7c3a0a5e6c9a78cb71dc55c1b48ed8764867
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58472
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This was used by Ron 13ys ago and was never used again
ever since.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Currently, the exception handling code on ARM in libpayload turns on alignment
checks as an easy way to generate an exception for testing purposes. It was
leaving it on which disabled unaligned accesses for other, unlreated code
running later. This change adjusts the code so the original value of the
alignment bit is restored after the test exception.
BUG=chrome-os-partner:18635
TEST=Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the depthcharge's main. Before this
change, the access caused an exception. After this change, the access
completed successfully.
BRANCH=None
Change-Id: If92cab3cc8eabca7c5b0560ce88a8796a27fe3b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Currently, the exception handling code on ARM turns on alignment checks as an
easy way to generate an exception for testing purposes. It was leaving it on
which disabled unaligned accesses for other, unlreated code running later.
This change adjusts the code so the original value of the alignment bit is
restored after the test exception.
BUG=chrome-os-partner:18635
TEST=Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the RAM stage. Before this change, the
access caused an exception. After this change, the access completed
successfully.
BRANCH=None
Change-Id: Ic2584650bb8e01dfe2285af6e2896e8c87477f50
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59371
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
BUG=chrome-os-partner:19420
TEST=Built and booted into depthcharge on snow and pit and saw serial output
which implies that the coreboot tables were found and parsed.
BRANCH=None
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The GPIOs used by vboot and setting up the display and backlight were still
the ones for snow. This change updates them so they're correct for pit.
BUG=chrome-os-partner:19420
TEST=Built and booted to when the payload is loaded on pit
BRANCH=None
Change-Id: I3ae4c2baefbab26bbc7b3716242c37885a5b44c0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59241
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The MAX_CPUS option is only used on x86 currently, so there's no reason to
have it in the pit config.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit
BRANCH=None
Change-Id: I78d035afe533ae46b7825b877b1bcc73b4e68f24
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59240
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
That part isn't used on pit.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit.
BRANCH=None
Change-Id: I889343b4dd6398281cebd2ebd66f13e888b113e8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59239
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
On pit, the tps65090 is connected to the EC and has to be accessed by proxy.
Until we have that implemented, this change removes calls to tps69050 which
will never succeed, and stops compiling in the driver.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit and saw that error spew from trying to access the
tps69050 we away.
BRANCH=None
Change-Id: I409339b283b1516a52efefdcbd1f20cc8f4c2154
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59238
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The members data structures in dmc.h are intended to have a particular size.
Rather than assume that particular types are the right size, we should use
types that are guaranteed to be the right size. Also, since the registers are
at particular offsets as well, the structures should be packed.
BUG=chrome-os-partner:19420
TEST=Built for pit.
BRANCH=None
Change-Id: Ie52a5eba459bc2a070656b264e00ef783838026e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59237
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The previous driver was a bit awkward and not entirely correct. This change
primarily replaces the read/write functions with simpler and more robust
(hopefully) version.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit into the RAM stage without any errors reading or
writing registers on the PMIC. There isn't really any direct feedback from the
PMIC, so I'm assuming since it didn't complain it worked. I looked at some of
the transaction on an oscilloscope and they looked correct.
BRANCH=None
Change-Id: I01b1f9ea43eafb4aae1dbebddc051cd5ec5aea74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59201
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
LynxPoint-LP has a lot of GPEs and the "default" set has been
moved to register 4 starting at bit offset 96. This means
that PME_B0 bit in GPE0_EN/GPE0_STS is now bit 109 in LPT-LP
but still bit 13 in LPT-H.
BUG=chrome-os-partner:20174
BRANCH=none
TEST=manual: suspend on falco and wake from usb
4 | 2013-06-19 10:49:17 | ACPI Enter | S3
5 | 2013-06-19 10:49:22 | ACPI Wake | S3
6 | 2013-06-19 10:49:22 | Wake Source | Internal PME | 0
Change-Id: I443cd4d17796888debed70c0bda27ae09accd09b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59265
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
For all other CPUs, we unconditionally include the CPU Kconfig
files in the CPU directory, not in the vendor directory. Do the
same thing for the Exynos CPUs. This allows us to make CPU dependent
changes in the directory of that CPU alone.
Also, drop some unused Kconfig variables from the Exynos Kconfig
files.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=no functional change
BRANCH=none
Change-Id: I57667dc5c5af5f61a54186a8fd47ceeae143d688
Reviewed-on: https://gerrit.chromium.org/gerrit/59291
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Some of the pcie logic was located in pch.c as well
as pcie.c. Move all pcie logic to the same pcie.c
file. This is a straight cut-and-paste (no logic changes)
except for a rename from pch_pcie_enable() ->
pch_pcie_enable_dev().
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted.
Change-Id: I338c53039b95f255ab9ced313c51193a9d34b404
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59277
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The function to disable devices was formerly named
pch_hide_devfn(). This routine was doing more than hiding
devices. It was disabling them, i.e. turning them off.
Therefore, rename it to pch_disable_devfn(). Also, allow
external callers to this function.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted.
Change-Id: Id5bb319d4e67892c02a39dff49e45b2811a2f016
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59276
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The iobp functions are useful to may of the southbridge
devices as certain values need to be updated to properly
initialize the devices. Therefore expose read, write, and
updated iobp functions.
BUG=chrome-os-partner:20262
BRANCH=None
TEST=Built and booted. Analyzed the console messages.
Change-Id: Id7fdd8d0d9f022f92d6285ecd8f85a52024ec2bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59275
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The dmb should be executed before reading operations, and before/after writing
operations.
BUG=none
TEST=manual: emerge-daisy chromeos-firmware-snow; booted Snow.
BRANCH=none
Change-Id: I3405cd8bef35b5454c423790d1886c87509c0f28
Reviewed-on: https://gerrit.chromium.org/gerrit/58441
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Hung-Te Lin <hungte@chromium.org>
This updates the low-level I2C code to handle the new high-speed
HSI2C/USI inteface. It also outputs a bit more error information
when things go wrong. Also adds some more error prints. Timeouts
really need to be noted.
In hsi2c_wait_for_irq, order the delay so that we do an initial
sleep first to avoid an early-test that was kicking us out of the
test too soon. We got to the test before the hardware was ready
for us. Finally, test clearing the interrupt status register every time
we wait for it on the write. Works.
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I785a4b9038d25c1a564784da0b7d54eaa9ef651d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58761
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This updates the setup_power() function to actually set up the PMIC
which is on this board (the MAX77802).
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I686740cc34e40256c6607132ec7a94d5156b5d55
Reviewed-on: https://gerrit.chromium.org/gerrit/58763
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This adds register offsets and important values for the Maxim
MAX77802 PMIC.
This adds a header
BUG=chrome-os-partner:19420
BRANCH=none
TEST=TODO...
Change-Id: I615c56215d5dbb8913eae707e1adfb2945c65068
Reviewed-on: https://gerrit.chromium.org/gerrit/58762
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
We saw a problem on x86 last year in which setting direction, then value,
glitched the output and caused problems. Change this code to set the output,
then the direction.
BUG=chrome-os-partner:19420
TEST=Build and boot on pit.
BRANCH=None
Change-Id: Ie40786139b0b496e22a80dc3dd712b6adff03d1e
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59087
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
A quirk of the Kconfig used in coreboot is that config options
cannot be overriden by local config changes unless they have
a description string.
BUG=chrome-os-partner:20208
BRANCH=none
TEST=manual:
1) Add CONFIG_MAINBOARD_VENDOR="Custom" to local config
2) Build and flash coreboot
3) cat /sys/class/dmi/id/sys_vendor and look for "Custom"
Change-Id: I1b5f2124cd4a22c056c025143ae5bcaafa6b03f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59088
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
