chromiumos/third_party/coreboot.git
17 months agoexynos5: select HAVE_MONOTONIC_TIMER master
David Hendricks [Mon, 6 May 2013 23:12:20 +0000 (16:12 -0700)]
exynos5: select HAVE_MONOTONIC_TIMER

We have the monotonic timer implemented on exynos now, and this
also enables helpful bootstage prints with timing info.

Change-Id: I3baa4c9d70d4b4d059abd5e05eddcabd5258dbfd
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3210
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
17 months agoexynos5250/snow: deprecate time.h
David Hendricks [Thu, 2 May 2013 23:47:54 +0000 (16:47 -0700)]
exynos5250/snow: deprecate time.h

This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/)
which was reverted due to unsatisfied dependencies.

time.h We Hardly Knew Ye.

This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.

timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.

Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3201
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
17 months agotimer.h: add mono_time_diff_microseconds()
David Hendricks [Fri, 3 May 2013 19:28:11 +0000 (12:28 -0700)]
timer.h: add mono_time_diff_microseconds()

The current way to get a simple mono_time difference is:
1. Declare a rela_time struct
2. Assign it the value of mono_time_diff(t1, t2)
3. Get microseconds from it using rela_time_in_microseconds().

This patch adds a simpler method. Now one only needs to call
mono_time_diff_microseconds(t1, t2) to obtain the same value which
is produced from the above three steps.

Change-Id: Ibfc9cd211e48e8e60a0a7703bff09cee3250e88b
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3190
Tested-by: build bot (Jenkins)
17 months agoexynos5/5250: Update timer call sites to use monotonic timer API
David Hendricks [Thu, 2 May 2013 21:23:51 +0000 (14:23 -0700)]
exynos5/5250: Update timer call sites to use monotonic timer API

This goes thru various call sites where we used timer_us() and updates
them to use the new monotonic timer API.

udelay() changed substantially and now gracefully handles wraparound.

Change-Id: Ie2cc86a4125cf0de12837fd7d337a11aed25715c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3176
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
17 months agoRevert "exynos5250/snow: deprecate time.h"
David Hendricks [Fri, 3 May 2013 23:54:45 +0000 (01:54 +0200)]
Revert "exynos5250/snow: deprecate time.h"

This reverts commit 2fde9668b47e74d1bfad2f1688a4481e6b966d04

Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself.

Reverting this until the other two go in.

Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3195
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
17 months agoexynos5250/snow: deprecate time.h
David Hendricks [Thu, 2 May 2013 23:47:54 +0000 (16:47 -0700)]
exynos5250/snow: deprecate time.h

time.h We Hardly Knew Ye.

This deprecates time.h which is currently only used by Exynos5250 and
Snow. The original idea was to try and unify some of the various timer
interfaces and has been supplanted by the monotonic timer API.

timer_us() is now obsolete. timer_start() is now mct_start() and
is exposed in exynos5250/clk.h.

Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5
Reviewed-on: http://review.coreboot.org/3177
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
17 months agoexynos5250: monotonic timer implementation (using MCT)
David Hendricks [Thu, 2 May 2013 20:23:08 +0000 (13:23 -0700)]
exynos5250: monotonic timer implementation (using MCT)

This implements the new monotonic timer API using the global
multi-core timer (MCT).

Change-Id: Id56249ff5d3e0f85808f5754954c83c0bc75f1c1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
17 months agoarmv7: invalidate TLB entries as they are added/modified
David Hendricks [Tue, 30 Apr 2013 23:01:50 +0000 (16:01 -0700)]
armv7: invalidate TLB entries as they are added/modified

The old approach was to invalidate the entire TLB every time we set up
a table entry. This worked because we didn't turn the MMU on until
after we had set everything up. This patch uses the TLBIMVAA wrapper
to invalidate each entry as it's added/modified.

Change-Id: I27654a543a2015574d910e15d48b3d3845fdb6d1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3166
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
17 months agoARMV7: add a function to disable MMU entries
Ronald G. Minnich [Tue, 30 Apr 2013 17:11:30 +0000 (10:11 -0700)]
ARMV7: add a function to disable MMU entries

It is useful to be able to lock out certain address ranges,
NULL being the most important example.

void mmu_disable_range(unsigned long start_mb, unsigned long size_mb)

will allow us to lock out selected virtual addresses on MiB boundaries.
As in other ARM mmu functions, the addresses and quantities are in units
of MiB.

Change-Id: If516ce955ee2d12c5a409f25acbb5a4b424f699b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3160
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
17 months agoGoogle/Snow: Revise bootblock initialization.
Hung-Te Lin [Tue, 30 Apr 2013 08:14:35 +0000 (16:14 +0800)]
Google/Snow: Revise bootblock initialization.

It's fine to always start timer even in suspend/resume mode, so we can
move the timer_start() back to the very beginning of boot procedure.
That provides more precise boot time information.

With that timer change, the wake up state test procedure can be simplified.

Verified by building and booting firmware image on Google/Snow successfully,
and then suspend-resume without problem (suspend_stress_test).

Change-Id: I0d739650dbff4eb3a75acbbf1e4356f2569b487d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3151
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
17 months agoarmv7: add wrapper for tlbimvaa
David Hendricks [Tue, 30 Apr 2013 19:20:53 +0000 (12:20 -0700)]
armv7: add wrapper for tlbimvaa

This adds an inline wrapper for the TLBIMVAA instruction (invalidate
unified TLB by MVA, all address space identifiers).

Change-Id: Ibcd289ecedaba8586ade26e36c177ff1fcaf91d3
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3161
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
17 months agoGoogle/Snow: Remove duplicated SPI1 initialization in bootblock.
Hung-Te Lin [Tue, 30 Apr 2013 08:11:32 +0000 (16:11 +0800)]
Google/Snow: Remove duplicated SPI1 initialization in bootblock.

The firmware media source (SPI1) is already initialized by Exynos iROM.
There is no need to do it again.

Verified by building and booting Google/Snow successfully.

Change-Id: I89390506aa825397c0d7e52ad7503f1cb808f7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3147
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
17 months agolynxpoint: Expose ACPI Device for LP GPIO controller 15/50215/3 release-R28-4100.B stabilize-4100.38.B stabilize-spring-4100.53.B toolchainB
Duncan Laurie [Mon, 6 May 2013 21:02:27 +0000 (14:02 -0700)]
lynxpoint: Expose ACPI Device for LP GPIO controller

In order to probe the gpio-lynxpoint kernel driver the
LP GPIO controller needs to be exposed as a specific
ACPI device.

This also allows the resources to be exposed to the OS via
this device instead of the catch-all LPC device.

BUG=chrome-os-partner:19255
TEST=manual:

Ensure the driver loads at boot:
gpiochip_find_base: found new base at 162
gpiochip_add: registered GPIOs 162 to 255 on device: INT33C7:00

Also ensure the driver is visible in sysfs:
$ cat /sys/devices/platform/INT33C7:00/gpio/gpiochip162/label
INT33C7:00

Change-Id: I9f79c008f88da9b67ed1cdfdb9d3a581ce8f05ff
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50215

17 months agoslippy: Update SPD 82/50082/2
Duncan Laurie [Fri, 3 May 2013 22:59:59 +0000 (15:59 -0700)]
slippy: Update SPD

BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-slippy chromeos-coreboot-slippy

Change-Id: Iae0258ceb0424df0937d2cec7dd885060f5b4e48
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50082

17 months agoMake ssize_t an actual ssize_t 47/49947/3
Stefan Reinauer [Thu, 2 May 2013 21:02:28 +0000 (14:02 -0700)]
Make ssize_t an actual ssize_t

In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.

Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
TEST=emerge-daisy libpayload depthcharge builds with ToT coreboot

Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
17 months agosnow: Set vbe mode info to valid later in the boot process 13/50013/3
David Hendricks [Fri, 3 May 2013 01:29:30 +0000 (18:29 -0700)]
snow: Set vbe mode info to valid later in the boot process

This sets the vbe mode to valid later in the boot process, after
cbmem resources have been allocated during displayport init.

BRANCH=none
BUG=none
TEST=booted on Snow using depthcharge in dev mode
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5ea675de817a2cf5695ef0473550023c72dd04c7
Reviewed-on: https://gerrit.chromium.org/gerrit/50013
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
17 months agocall fill_lb_framebuffer() earlier 12/50012/2
David Hendricks [Fri, 3 May 2013 01:23:24 +0000 (18:23 -0700)]
call fill_lb_framebuffer() earlier

fill_lb_framebuffer() now sets the framebuffer pointer according to
the EDID information, so it must be called before setting the tag
and size.

(credit to rminnich for this, I'm just uploading it)

BRANCH=none
BUG=none
TEST=booted on Snow using depthcharge in dev mode
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I5ac783fa3a776eee504d39889284041d1dc2c92a
Reviewed-on: https://gerrit.chromium.org/gerrit/50012
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
17 months agoslippy: Add SPD data for on-board memory 11/49911/2
Duncan Laurie [Thu, 2 May 2013 17:40:49 +0000 (10:40 -0700)]
slippy: Add SPD data for on-board memory

BUG=chrome-os-partner:19041
BRANCH=none
TEST=emerge-slippy chromeos-coreboot-slippy

Change-Id: I7a617fe06d23b906f718ed30f1378f7d220b2799
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49911
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agodevice tree: track init times 67/49767/2
Aaron Durbin [Tue, 30 Apr 2013 20:41:13 +0000 (15:41 -0500)]
device tree: track init times

With the introduction of a monotonic timer it is possible to
track the individual times of each device's init() call. Add this
ability behind a HAVE_MONOTONIC_TIMER option.

Example log messages:
Root Device init 5 usecs
CPU_CLUSTER: 0 init 66004 usecs
PCI: 00:00.0 init 1020 usecs
PCI: 00:02.0 init 456941 usecs
PCI: 00:13.0 init 3 usecs
PCI: 00:14.0 init 3 usecs
PCI: 00:15.0 init 92 usecs
PCI: 00:15.1 init 37 usecs
PCI: 00:15.2 init 36 usecs
PCI: 00:15.3 init 35 usecs
PCI: 00:15.4 init 35 usecs
PCI: 00:15.5 init 36 usecs
PCI: 00:15.6 init 35 usecs
PCI: 00:16.0 init 3666 usecs
PCI: 00:17.0 init 63 usecs
PCI: 00:1b.0 init 3 usecs
PCI: 00:1c.0 init 89 usecs
PCI: 00:1c.1 init 15 usecs
PCI: 00:1c.2 init 15 usecs
PCI: 00:1c.3 init 15 usecs
PCI: 00:1c.4 init 15 usecs
PCI: 00:1c.5 init 16 usecs
PCI: 00:1d.0 init 4 usecs
PCI: 00:1f.0 init 495 usecs
PCI: 00:1f.2 init 29 usecs
PCI: 00:1f.3 init 4 usecs
PCI: 00:1f.6 init 4 usecs

Change-Id: Ibe499848432c7ab20166ab10d6dfb07db03eab01
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49767
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
18 months agochromeos: Add PRESUBMIT.cfg 72/49772/2
Stefan Reinauer [Wed, 1 May 2013 19:53:55 +0000 (12:53 -0700)]
chromeos: Add PRESUBMIT.cfg

This adds back the presubmit hook configuration file
for the ChromeOS build system / repo utility.

BUG=chrome-os-partner:18638
TEST=upload a change to gerrit without --no-verify
     and see that repo does not complain about the license
     headers anymore.

Change-Id: I82a31afaf2b01a77a2d09da49f5c7a6531dc7681
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49772
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agolynxpoint: Move ME lock down to ramstage 57/49757/3
Duncan Laurie [Wed, 1 May 2013 18:30:24 +0000 (11:30 -0700)]
lynxpoint: Move ME lock down to ramstage

Now that we have RW ramstage we don't need to have the
management engine lock down step done in a final SMM.

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2 and look for messages
during the ME device init step:

ME: mkhi_end_of_post
ME: END OF POST message successful (0)
PCI: 00:16.0: Disabling device

Change-Id: I9db4e72e38be58cc875c1622a966d8fcacc83280
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49757

18 months agolynxpoint: Add missing ME MBP entries 56/49756/3
Duncan Laurie [Wed, 1 May 2013 18:27:58 +0000 (11:27 -0700)]
lynxpoint: Add missing ME MBP entries

There were two undefined MBP types that are now defined.
These include NFC status and some interesting timing data.

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2, check for missing
MBP messages and for timing output.

ME: Wake Event to ME Reset:      6 ms
ME: ME Reset to Platform Reset:  7 ms
ME: Platform Reset to CPU Reset: 51 ms

Change-Id: I67bf1f303f3c32497041e64c40eb9ccb6a63d88a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49756

18 months agoslippy: Prepare LPC IO decode ranges for EC 55/49755/3
Duncan Laurie [Wed, 1 May 2013 18:12:53 +0000 (11:12 -0700)]
slippy: Prepare LPC IO decode ranges for EC

- 0x200-0x208 for host command window
- 0x800-0x8ff for host command arguments and parameters
- 0x900-0x9ff for exported EC memory map

BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-slippy chromeos-coreboot-slippy

Change-Id: I064b969843ef0d3c602793d1cb3d82715775c05e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49755

18 months agoslippy: Add iSSD power sequencing 48/49648/3
Duncan Laurie [Wed, 1 May 2013 18:11:10 +0000 (11:11 -0700)]
slippy: Add iSSD power sequencing

Without an LM10506-A the power sequencing for this
part needs to be done manually using GPIOs.

BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-slippy chromeos-coreboot-slippy

Change-Id: I842152e5f7c30c8dbe37df0c344935a659eb2887
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49648
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agolibpayload: make searching for a file less verbose 66/49766/2
Aaron Durbin [Wed, 1 May 2013 13:40:13 +0000 (08:40 -0500)]
libpayload: make searching for a file less verbose

The cbfs core code would print out all unmatched file
names when searching for a file. This contributes to a lot
of unnecessary messages in the boot log. Change this
message to a DEBUG one so that it will only be printed when
CONFIG_DEBUG_CBFS is enabled.

Change-Id: I34c747e0d3406351318abf70994dbc0bb3fa6c01
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49766
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agocbfs: make searching for a file less verbose 65/49765/2
Aaron Durbin [Thu, 25 Apr 2013 13:42:23 +0000 (08:42 -0500)]
cbfs: make searching for a file less verbose

The cbfs core code would print out all unmatched file
names when searching for a file. This contributes to a lot
of unnecessary messages in the boot log. Change this
message to a DEBUG one so that it will only be printed when
CONFIG_DEBUG_CBFS is enabled.

Change-Id: I1e46a4b21d80e5d2f9b511a163def7f5d4e0fb99
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49765
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agolynxpoint: export mem console pointer in ACPI 64/49764/2
Aaron Durbin [Wed, 1 May 2013 18:41:44 +0000 (13:41 -0500)]
lynxpoint: export mem console pointer in ACPI

Instead of having an OS re-parse cbmem book-keeping records
for the cbmem allocator just to get the console buffer export
the pointer to the memory console directly in a field named 'CBMC'.
This field lives in the GNVS table.

BUG=None
BRANCH=None
TEST=Built and booted kernel with support for this field.
/sys/firmware/log correctly shows up.

Change-Id: Ief0c4da7b18df66feb9c816c9f4abdf5a72bd3a4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49764
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agohaswell: enable monotonic timer 63/49763/2
Aaron Durbin [Wed, 1 May 2013 18:29:45 +0000 (13:29 -0500)]
haswell: enable monotonic timer

For all the current haswell boards enable the monotonic timer.
The ULT boards use the 24MHz MSR while the non-ULT boards use the
local apic.

Change-Id: I8b19f526a5a49e8467f296c566a2c4263bc5a863
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49763
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: boot state: run timers on state entry 54/49754/2
Aaron Durbin [Tue, 30 Apr 2013 04:22:01 +0000 (23:22 -0500)]
BACKPORT: boot state: run timers on state entry

When TIMER_QUEUE is configured on call the timer callbacks on
entry into a state but before its entry callbacks. In addition
provide a barrier to the following states so that timers are drained
before proceeding. This allows for blocking state traversal for key
components of boot.
BS_OS_RESUME
BS_WRITE_TABLES
BS_PAYLOAD_LOAD
BS_PAYLOAD_BOOT

Future functionality consists of evaluating the timer callbacks within
the device tree. One example is dev_initialize() as that seems state
seems to take 90% of the boot time. The timer callbacks could then be
ran in a more granular manner.

Change-Id: I9be5dbd8ad3d56a17f5de827a870fa63608ab8f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49754
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: coreboot: add timer queue implementation 53/49753/2
Aaron Durbin [Tue, 30 Apr 2013 14:58:12 +0000 (09:58 -0500)]
BACKPORT: coreboot: add timer queue implementation

A timer queue provides the mechanism for calling functions
in the future by way of a callback. It utilizes the MONOTONIC_TIMER
to track time through the boot. The implementation is a min-heap
for keeping track of the next-to-expire callback.

Change-Id: Ia493a284efb3b34e8577e6d3db957169c6d86a1b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49753
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: boot state: track times for each state 52/49752/2
Aaron Durbin [Sat, 27 Apr 2013 01:54:16 +0000 (20:54 -0500)]
BACKPORT: boot state: track times for each state

When the MONOTONIC_TIMER is available track the entry, run, and exit
times for each state. It should be noted that the times for states that
vector to OS or a payload do not have their times reported.

Change-Id: I1ab55ca52e37db02f4fa3c0707170ab162bb78e6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49752
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: tsc: provide monotonic timer 51/49751/2
Aaron Durbin [Tue, 30 Apr 2013 03:22:55 +0000 (22:22 -0500)]
BACKPORT: tsc: provide monotonic timer

Implement the timer_monotonic_get() using the TSC.

Change-Id: I2c09ba2a2e96861255c7bf38291d9f4df004dcc4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49751
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: lapic: monotonic time implementation 50/49750/2
Aaron Durbin [Mon, 29 Apr 2013 22:18:49 +0000 (17:18 -0500)]
BACKPORT: lapic: monotonic time implementation

Implement the timer_monotonic_get() functionality based off of
the local apic timer.

Change-Id: Ifbead8ead0142a2e246d50306f052adce979da9a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49750
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: haswell: 24MHz monotonic time implementation 49/49749/2
Aaron Durbin [Mon, 29 Apr 2013 21:57:10 +0000 (16:57 -0500)]
BACKPORT: haswell: 24MHz monotonic time implementation

Haswell ULT devices have a 24MHz package-level counter. Use
this counter to provide a timer_monotonic_get() implementation.

Change-Id: I72dce5976acd44376bc8ac1587dcb3c3d5b9f1e7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49749
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: coreboot: introduce monotonic timer API 48/49748/2
Aaron Durbin [Tue, 30 Apr 2013 03:31:51 +0000 (22:31 -0500)]
BACKPORT: coreboot: introduce monotonic timer API

The notion of a monotonic timer is introduced. Along with it
are helper functions and other types for comparing times. This
is just the framework where it is the responsibility of the
chipset/board to provide the implementation of timer_monotonic_get().

The reason structs are used instead of native types is to allow
for future changes to the data structure without chaning all the
call sites.

Change-Id: If608f65efc9d2e8190dcc97f0e87c8f6a7b50745
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49748
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: boot state: rebalance payload load vs actual boot 47/49747/2
Aaron Durbin [Thu, 25 Apr 2013 03:59:45 +0000 (22:59 -0500)]
BACKPORT: boot state: rebalance payload load vs actual boot

The notion of loading a payload in the current boot state
machine isn't actually loading the payload. The reason is
that cbfs is just walked to find the payload. The actual
loading and booting were occuring in selfboot(). Change this
balance so that loading occurs in one function and actual
booting happens in another. This allows for ample opportunity
to delay work until just before booting.

Change-Id: I8c2af24a12a77d22e61c0bd8c392714bd1dfdedd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49747
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: x86: use boot state callbacks to disable rom cache 46/49746/2
Aaron Durbin [Thu, 25 Apr 2013 01:59:43 +0000 (20:59 -0500)]
BACKPORT: x86: use boot state callbacks to disable rom cache

On x86 systems there is a concept of cachings the ROM. However,
the typical policy is that the boot cpu is the only one with
it enabled. In order to ensure the MTRRs are the same across cores
the rom cache needs to be disabled prior to OS resume or boot handoff.
Therefore, utilize the boot state callbacks to schedule the disabling
of the ROM cache at the ramstage exit points.

Change-Id: If67b9b50081d21d505685a96d201c242e71b64f7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49746
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: boot: remove cbmem_post_handling() 45/49745/2
Aaron Durbin [Wed, 24 Apr 2013 22:31:49 +0000 (17:31 -0500)]
BACKPORT: boot: remove cbmem_post_handling()

The cbmem_post_handling() function was implemented by 2
chipsets in order to save memory configuration in flash. Convert
both of these chipsets to use the boot state machine callbacks
to perform the saving of the memory configuration.

Change-Id: Ic086cae17491a20d2e81aa1c7922bd821aacb00b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49745
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: cbmem: use boot state machine 44/49744/2
Aaron Durbin [Wed, 24 Apr 2013 21:39:08 +0000 (16:39 -0500)]
BACKPORT: cbmem: use boot state machine

There were previously 2 functions, init_cbmem_pre_device() and
init_cbmem_post_device(), where the 2 cbmem implementations
implemented one or the other. These 2 functions are no longer
needed to be called in the boot flow once the boot state callbacks
are utilized.

Change-Id: I2648ebc26a753896ad4b82ab8136e9742b4d6af5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49744
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: coverage: use boot state callbacks 43/49743/2
Aaron Durbin [Wed, 24 Apr 2013 21:28:52 +0000 (16:28 -0500)]
BACKPORT: coverage: use boot state callbacks

Utilize the static boot state callback scheduling to initialize
and tear down the coverage infrastructure at the appropriate points.
The coverage initialization is performed at BS_PRE_DEVICE which is the
earliest point a callback can be called. The tear down occurs at the
2 exit points of ramstage: OS resume and payload boot.

Change-Id: I623e55f19f9fb52492f288c620cc966cafd0ab71
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49743
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: acpi: split resume check and actual resume code 42/49742/2
Aaron Durbin [Thu, 25 Apr 2013 03:33:08 +0000 (22:33 -0500)]
BACKPORT: acpi: split resume check and actual resume code

It's helpful to provide a distinct state that affirmatively
describes that OS resume will occur. The previous code included
the check and the actual resuming in one function. Because of this
grouping one had to annotate the innards of the ACPI resume
path to perform specific actions before OS resume. By providing
a distinct state in the boot state machine the necessary actions
can be scheduled accordingly without modifying the ACPI code.

Change-Id: I298f0f1c1aa6ee62fee0067a53dc021fe07044dc
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49742
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: boot state: schedule static callbacks 41/49741/2
Aaron Durbin [Wed, 24 Apr 2013 21:12:52 +0000 (16:12 -0500)]
BACKPORT: boot state: schedule static callbacks

Many of the boot state callbacks can be scheduled at compile time.
Therefore, provide a way for a compilation unit to inform the
boot state machine when its callbacks should be called. Each C
module can export the callbacks and their scheduling requirements
without changing the shared boot flow code.

Change-Id: I6a4102cb9fac3f7980c28169430251651fddeb30
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49741
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: ramstage: introduce boot state machine 40/49740/2
Aaron Durbin [Wed, 24 Apr 2013 20:14:01 +0000 (15:14 -0500)]
BACKPORT: ramstage: introduce boot state machine

The boot flow currently has a fixed ordering. The ordering
is dictated by the device tree and on x86 the PCI device ordering
for when actions are performed. Many of the new machines and
configurations have dependencies that do not follow the device
ordering.

In order to be more flexible the concept of a boot state machine
is introduced. At the boundaries (entry and exit) of each state there
is opportunity to run callbacks. This ability allows one to schedule
actions to be performed without adding board-specific code to
the shared boot flow.

Change-Id: I9555845ca3045c6d4386b79438e5f426916fe457
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49740
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: rmodule: put all code/data bits in one section 39/49739/2
Aaron Durbin [Mon, 29 Apr 2013 18:53:41 +0000 (13:53 -0500)]
BACKPORT: rmodule: put all code/data bits in one section

While debugging a crash it was discovered that ld was inserting
address space for sections that were empty depending on section
address boundaries. This led to the assumption breaking down that
on-disk payload (code/data bits) was contiguous with the address
space. When that assumption breaks down relocation updates change
the wrong memory. Fix this by making the rmodule.ld linker script
put all code/data bits into a payload section.

Change-Id: Iae9406efa97690c2ce11737688906dc071de5c7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49739
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoBACKPORT: string: Add STRINGIFY macro 38/49738/2
Aaron Durbin [Fri, 26 Apr 2013 16:58:35 +0000 (11:58 -0500)]
BACKPORT: string: Add STRINGIFY macro

STRINGIFY makes a string from a token. It is generally useful.
Even though STRINGIFY is not defined to be in the C library it's
placed in string.h because it does make a string.

Change-Id: If8e16cb321bb53eed4013dc5ea2436a4f40eeb6b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49738
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
18 months agoFix Google ChromeEC driver 34/49734/2
Stefan Reinauer [Wed, 1 May 2013 17:48:37 +0000 (10:48 -0700)]
Fix Google ChromeEC driver

Compilation was broken by a bad merge of

C 3d7c2eb ec/google: Isolate EC bus protocol implementation.

CONFIG_EC_GOOGLE_API_ROOT was removed a while ago because
the required include files were added to the coreboot tree
instead of taking them from the installed system.

Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
TEST=emerge-link chromeos-coreboot-link with new repository compiles

Change-Id: I7684d7f87aaf426cd5cdfa4ddd32b7e7d7c3aee7
Reviewed-on: https://gerrit.chromium.org/gerrit/49734
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
18 months agoFix mainboard GPI handler prototype 29/49729/2
Stefan Reinauer [Wed, 1 May 2013 17:15:24 +0000 (10:15 -0700)]
Fix mainboard GPI handler prototype

Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
TEST=emerge-link chromeos-coreboot-link with new repository compiles
     past smihandler.c

Change-Id: I24c55a668f341c6f70d3d96a4b72fa98b81559fc
Reviewed-on: https://gerrit.chromium.org/gerrit/49729
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
18 months agoGoogle/Snow: Remove unnecessary serial console init code.
Hung-Te Lin [Tue, 30 Apr 2013 07:31:48 +0000 (15:31 +0800)]
Google/Snow: Remove unnecessary serial console init code.

The "console_init" does initialize UART driver (which will setup peripheral and
pinmux) and print starting message. Duplicated initialization can be removed.

Also, console_init (from console.c) is always linked to bootblock (and will do
nothing if CONFIG_EARLY_CONSOLE is not defined) so it's safe to remove #ifdef.

Verified by building and booting on Google/Snow, with and without
CONFIG_EARLY_CONSOLE.

Change-Id: I0c6b4d4eb1a4e81af0f65bcb032978dfb945c63d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3150
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoGoogle/Snow: Temporary fix for resume failure.
Hung-Te Lin [Mon, 29 Apr 2013 14:11:22 +0000 (22:11 +0800)]
Google/Snow: Temporary fix for resume failure.

The DDR3 memory initialization (with "mem_reset" set on normal boot) will cause
resume to be unstable, especially when X is running. System may show X screen
for few seconds, then crash randomly and unable to recover - although text
console may still work for a while.  Probably caused by corrupted memory pages.

'mem_reset' (which refers to RESET# in DDR3 spec) should be enabled according
to DDR3 spec. But it seems that on Exynos 5, memory can be initialized without
setting mem_reset for both normal boot and resume - at least no known failure
cases are found yet.  So this can be a temporary workaround.

Verified by booting a Google/Snow device with X Window and ChromeOS, entering
browser session with fancy web pages, closing LID to suspend for 5 seconds, then
re-opening to resume.  Suspend/resume worked as expected.

Also tried the "suspend_stress_test" with X running and finished 100 iterations
of suspend/resume test without failure.

Change-Id: I7185b362ce8b545fe77b35a552245736c89d465e
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3148
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoGoogle/Snow: Enable suspend/resume.
Hung-Te Lin [Thu, 25 Apr 2013 11:49:40 +0000 (19:49 +0800)]
Google/Snow: Enable suspend/resume.

Add the suspend/resume feature into bootblock and romstage.

Note, resuming with X and touchpad driver may be still unstable.

Verified by building and booting successfully on Google/Snow, and then executing
the "suspend_stress_test" in text mode ("stop ui; suspend_stress_test") in
Chromium OS, passed at least 20 iterations.

Change-Id: I65681c42eeef2736e55bb906595f42a5b1dfdf11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3102
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
18 months agogoogle/snow: Revise romstage initialization code.
Hung-Te Lin [Thu, 25 Apr 2013 11:30:19 +0000 (19:30 +0800)]
google/snow: Revise romstage initialization code.

Move board setup procedure to snow_setup_* functions, and Snow board-specific
(wakeup) code to snow_* for better function names and comments.

Verified by successfully building and booting on Google/Snow.

Change-Id: I2942d75064135093eeb1c1da188a005fd255111d
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3130
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months agogoogle/snow: Add "wakeup" module for suspend/resume.
Hung-Te Lin [Thu, 25 Apr 2013 09:38:55 +0000 (17:38 +0800)]
google/snow: Add "wakeup" module for suspend/resume.

The "wakeup" procedure will be shared by bootblock and romstage for different
types of resume processes.

Note, this commit does not include changes in romstage/bootblock to enable
suspend/resume feature. Simply adding functions to handle suspend/resume.

Verified by successfully building and booting Google/Snow firmware image.

Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3129
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoarm/exynos: Allow DRAM controller to be initialized without clearing RAM content.
Hung-Te Lin [Thu, 25 Apr 2013 08:14:19 +0000 (16:14 +0800)]
arm/exynos: Allow DRAM controller to be initialized without clearing RAM content.

To support suspend/resume, PHY control must be reset only on normal boot
path.  So add a new param "mem_reset" to specify that.

Verified to boot successfully on Google/Snow.

Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoGOOGLE/SNOW: get graphics working
Ronald G. Minnich [Fri, 19 Apr 2013 01:09:24 +0000 (18:09 -0700)]
GOOGLE/SNOW: get graphics working

This adds support for display bring-up on Snow. It
includes framebuffer initialization and LCD enable functions.

Note: We fixed a merge conflict in this CL by making a fake edid
struct for Snow and passing it into vbe_mode_info_valid().

Change-Id: I16e711c97e9d02c916824f621e2313297448732b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3116
Tested-by: build bot (Jenkins)
18 months agoexynos5250: ungate the product ID register
David Hendricks [Mon, 22 Apr 2013 23:03:11 +0000 (16:03 -0700)]
exynos5250: ungate the product ID register

This makes sure that the product ID (PRO_ID) register can be read
when the OS kernel is figuring out what kind of CPU it's running on.

For historical reference, the original U-Boot code seems to have
worked basically by accident here. The hardware has a quirk where by
reading the value before gating the IP block keeps the value
persistent. U-Boot reads the chip ID early on to distinguish between
chip family, but we do not mix code the same way so we do not read
the chip ID. Since the value has been read before the clock gating
happens, the value remains available for the kernel to use during the
decompression stage. We don't want to rely on that behavior when using
coreboot. Instead the kernel should gate unused IPs.

(credit to Gabe for finding symptom in the kernel)

Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3121
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
18 months agoGOOGLE/SNOW: fix stupid paren error
Ronald G. Minnich [Mon, 22 Apr 2013 17:46:53 +0000 (10:46 -0700)]
GOOGLE/SNOW: fix stupid paren error

This simple error led to corrupted graphics.
How annoying.

Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3120
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agogoogle/snow: disable unused USB3.0 PLL to save power
David Hendricks [Thu, 18 Apr 2013 20:46:00 +0000 (13:46 -0700)]
google/snow: disable unused USB3.0 PLL to save power

This PLL is unused and can be disabled to save about 250mW.

Change-Id: I1be37304d6ea5ff78696e05ad1023ce3c57f636c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3109
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoexynos5: eliminate lcd_base variable
David Hendricks [Fri, 19 Apr 2013 00:27:07 +0000 (17:27 -0700)]
exynos5: eliminate lcd_base variable

The original imported code used "lcdbase" and "lcd_base" which quite
predictably caused confusion and bugs. Let's put an end to this little
bit of insanity.

Change-Id: I4f995482cfbff5f23bb296a1e6d35beccf5f8a91
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3114
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months agogoogle/snow: Minor clean-ups for display setup code in ramstage
David Hendricks [Thu, 18 Apr 2013 23:45:47 +0000 (16:45 -0700)]
google/snow: Minor clean-ups for display setup code in ramstage

This just cleans up a few areas:
- Removed an unnecessary delay from exynos_dp_bridge_setup()
- The delay at the end of exynos_dp_bridge_init() is necessary, so
  removed the comment suggesting that it might not be.
- Simplified exynos_dp_hotplug

Change-Id: I44150f5ef3958e333985440c1022b4f1544a93aa
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3113
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agogoogle/snow: enable clock gating to save power
David Hendricks [Thu, 18 Apr 2013 20:49:57 +0000 (13:49 -0700)]
google/snow: enable clock gating to save power

This enables clock gating to save power on unused IPs.

Change-Id: I9ab2a2535ebb91bb4110390a6f055a67146bdbf9
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3110
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoexynos5250: get xres and yres out of the device tree and into the panel descriptor
Ronald G. Minnich [Thu, 18 Apr 2013 23:10:29 +0000 (16:10 -0700)]
exynos5250: get xres and yres out of the device tree and into the panel descriptor

We neglected to copy xres and yres out; now we do.

Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3111
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months ago[3/3] google/snow: enable TMU
David Hendricks [Thu, 18 Apr 2013 22:19:40 +0000 (15:19 -0700)]
[3/3] google/snow: enable TMU

This enables the thermal management unit (TMU) on Snow.

Change-Id: Idd76af40bf0a5408baf61ef2665fd52ae4e260ba
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3108
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months ago[2/3] exynos5: modify thermal management unit code for coreboot
David Hendricks [Thu, 18 Apr 2013 21:21:15 +0000 (14:21 -0700)]
[2/3] exynos5: modify thermal management unit code for coreboot

This updates the Exynos TMU code for coreboot:
- Remove dependency on device tree
- Add Makefile entries

Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3107
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months ago[1/3] exynos5: import thermal management unit code
David Hendricks [Thu, 18 Apr 2013 21:01:45 +0000 (14:01 -0700)]
[1/3] exynos5: import thermal management unit code

This simply imports the Exynos TMU driver from u-boot. It is not
built and thus should not break anything.

Change-Id: I7861132fbf97f864e4250ffbda1ef3843f296ddc
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3106
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months agoexynos5: move power_enable_hw_thermal_trip() prototype
David Hendricks [Thu, 18 Apr 2013 22:04:43 +0000 (15:04 -0700)]
exynos5: move power_enable_hw_thermal_trip() prototype

This moves the prototype for power_enable_hw_thermal_trip() to
a generic location so it can be used by generalized thermal
management code. The implementation will still be CPU-specific.

Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3105
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months agoarmv7/exynos5250: Deprecate sdelay in favor of udelay
David Hendricks [Fri, 12 Apr 2013 22:11:05 +0000 (15:11 -0700)]
armv7/exynos5250: Deprecate sdelay in favor of udelay

This gets rid of the clock-tick based sdelay in favor of udelay().
udelay() is more consistent and easier to work with, and this allows
us to carry one less variation of timers (and headers and sources...).

Every 1 unit in the sdelay() argument was assumed to cause a delay of
2 clock ticks (@1.7GHz). So the conversion factor is roughly:
sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6)
          = udelay((N * 2) / (1.7 * 10^3))

The sdelay() periods used were:
sdelay(100) --> udelay(1)
sdelay(0x10000) --> udelay(78) (rounded up to udelay(100))

There was one instance of sdelay(10000), which looked like sort of a
typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should
approximate to about 12us, so we'll stick with that for now and leave
a note.

Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3079
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agogoogle/snow: enable 32KHz sleep clock
David Hendricks [Thu, 11 Apr 2013 19:58:25 +0000 (12:58 -0700)]
google/snow: enable 32KHz sleep clock

Change-Id: I9db91826e4534b8a6eea2b13bcf7c6abd848b4e4
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3075
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoSamsung/exynos5250: convert unsigned {int,char} to u32/u8
Ronald G. Minnich [Tue, 16 Apr 2013 23:00:23 +0000 (16:00 -0700)]
Samsung/exynos5250: convert unsigned {int,char} to u32/u8

The types are (esp. int) are confusing at times as to size.
Make them definite as to size.

Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3103
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
18 months agosnow: Return 0 from get_recovery_mode_from_vbnv.
Gabe Black [Tue, 16 Apr 2013 03:36:01 +0000 (20:36 -0700)]
snow: Return 0 from get_recovery_mode_from_vbnv.

This function isn't yet used for much, or perhaps anything, but where it
appears in the code it's ored with other values. Since we're not actually
retrieving anything, it might be best to return 0 so that the other values
that are being ored in can be expressed and this function can stay dormant
until it actually has something to do.

Change-Id: I6edc222a5c2d00ece2ecfad5191a615331eeaf16
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3098
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
18 months agosnow: Report the state of the power button GPIO in the coreboot tables.
Gabe Black [Tue, 16 Apr 2013 02:59:10 +0000 (19:59 -0700)]
snow: Report the state of the power button GPIO in the coreboot tables.

Change-Id: Ia7ce2b7342e186c565b92211e3ac15d80ce24b38
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3097
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agosnow: Configure the power button as an input GPIO.
Gabe Black [Tue, 16 Apr 2013 02:47:40 +0000 (19:47 -0700)]
snow: Configure the power button as an input GPIO.

We need to read it to report its value to the payload. The kernel will
reconfigure it as an external interrupt, but we'll make it a regular input
for now.

Change-Id: I019bd2c2731144d3b7bb53fad0c2c903874f616c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3096
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
18 months agosnow: Fix the name of some constants in romstage.c.
Gabe Black [Tue, 16 Apr 2013 02:45:10 +0000 (19:45 -0700)]
snow: Fix the name of some constants in romstage.c.

These names were inherited from chromeos.c where they've already been
fixed.

Change-Id: I7ad57b979b7b8f42f6bd68d1ecf887caba3fa3f1
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3095
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agosnow: Get rid of the oprom loaded GPIO.
Gabe Black [Tue, 16 Apr 2013 02:07:10 +0000 (19:07 -0700)]
snow: Get rid of the oprom loaded GPIO.

ARM doesn't use option ROMs, so this value doesn't make sense.

Change-Id: I1a0f0854e1dd4b9594ca0c147e590337520436da
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3094
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agosnow: Tidy up chromeos.c.
Gabe Black [Tue, 16 Apr 2013 01:22:11 +0000 (18:22 -0700)]
snow: Tidy up chromeos.c.

Got rid of a lot of #defines, some of which were converted to enums and
the rest which were eliminated entirely. Got rid of cruft in
get_developer_mode_switch and started using it for the dev mode GPIO.
Instead of a macro defining how many GPIOs are expected, now the code
actually counts the GPIOs as they're added.

Change-Id: I97b6b9f52a72d1276eb3cf36d7f9dd7b335b4d19
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3093
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agosnow: Add support for EC based recovery.
Gabe Black [Tue, 16 Apr 2013 01:09:15 +0000 (18:09 -0700)]
snow: Add support for EC based recovery.

Implement the get_recovery_mode_switch function using the newly added I2C
based Chrome EC support.

Change-Id: I9d0200629887f202edf017cba3222a7d7f5b053e
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3092
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agosnow: Fix some comments in chromeos.c.
Gabe Black [Mon, 15 Apr 2013 23:25:02 +0000 (16:25 -0700)]
snow: Fix some comments in chromeos.c.

The comment about the lid switch was left over from when this file was copied
from another board and was incorrect. Also fixed a capitalization
inconsistency.

Change-Id: Icefd19047971e13c08f615578e4a181e82a2997f
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3091
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
18 months agoec/google: Move plug-n-play initialization to LPC protocol.
Hung-Te Lin [Mon, 15 Apr 2013 10:06:32 +0000 (18:06 +0800)]
ec/google: Move plug-n-play initialization to LPC protocol.

"Plug-n-play" is not supported on all platforms using Google's Chrome EC.
For example, EC on I2C bus will need explicit configuration and initialization.
So move the plug-n-play initialization to the LPC implementation.

Verified by building Google/Link (with EC/LPC) successfully.

Change-Id: I49e5943503fd5301aa2b2f8c1265f3813719d7e3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3089
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
18 months agoec/google: Support Google's Chrome EC on I2C interface.
Hung-Te Lin [Mon, 15 Apr 2013 10:27:24 +0000 (18:27 +0800)]
ec/google: Support Google's Chrome EC on I2C interface.

Google's Chrome EC can be installed on LPC or I2C bus, using different command
protocol.  This commit adds I2C support for devices like Google/Snow.

Note: I2C interface cannot be automatically probed so the bus and chip number
must be explicitly set.

Verified by booting Google/Snow, with following console output:
  Google Chrome EC: Hello got back 11223344 status (0)
  Google Chrome EC: version:
     ro: snow_v1.3.108-30f8374
     rw: snow_v1.3.128-e35f60e
    running image: 1

Conflicts:
src/ec/google/chromeec/Kconfig

Change-Id: I8023eb96cf477755d277fd7991bdb7d9392f10f7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3074
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoec/google: Isolate EC bus protocol implementation.
Hung-Te Lin [Thu, 11 Apr 2013 07:58:12 +0000 (15:58 +0800)]
ec/google: Isolate EC bus protocol implementation.

The Chrome EC can be connected by different types of bus like LPC / I2C / SPI,
and the current implementation is only for LPC.

To support other types, we must first isolate the LPC protocol stuff and add
configuration variable (EC_GOOGLE_CHROMEEC_LPC) to specify bus type.

Verified by building google/link (with chromeec) configuration successfully.

Conflicts:
src/ec/google/chromeec/Kconfig
src/ec/google/chromeec/Makefile.inc

Change-Id: Ib2920d8d935bcc77a5394e818f69e9265e26e8a0
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3068
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
18 months agoexynos5/snow: remove wait_ms arg from dp_controller_init()
David Hendricks [Fri, 12 Apr 2013 23:02:44 +0000 (16:02 -0700)]
exynos5/snow: remove wait_ms arg from dp_controller_init()

This removes the wait_ms argument from the dp_controller_init(). The
only delay involved is a constant 60ms delay that happens if
everything else goes well. This delay is derived from the LCD spec
so there's no reason it should be baked into the controller code.

(This patch also has the side-effect of fixing a bug where we were
delaying on an undefined value for wait_ms).

Change-Id: I03aa19f2ac2f720524fcb7c795e10cc57f0a226e
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoExynos5250: add a microsecond timer
Ronald G. Minnich [Thu, 11 Apr 2013 22:03:28 +0000 (15:03 -0700)]
Exynos5250: add a microsecond timer

Add a microsecond timer, its declaration, the function to start it,
and its usage.  To start it, one calls timer_start().  From that point
on, one can call timer_us() to find microseconds since the timer was
started.

We show its use in the bootblock. You want it started very early.

Finally, the delay.h change having been (ironically) delayed, we
create time.h and have it hold one declaration, for the timer_us() and
timer_start() prototype.

We feel that these two functions should become the hardware specific
functions, allowing us to finally move udelay() into src/lib where it
belongs.

Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3073
Tested-by: build bot (Jenkins)
18 months agoSnow: Set up the ChromeOS GPIOs as inputs during the ROM stage.
Gabe Black [Wed, 10 Apr 2013 21:34:57 +0000 (14:34 -0700)]
Snow: Set up the ChromeOS GPIOs as inputs during the ROM stage.

We need these to be inputs so they can be read when populating the coreboot
tables. It seems like a good idea to do this early to ensure that the input
gate capacitance has had a chance to charge, and if we decide to use
actually use that information during the ROM stage to do earlier RW
firmware selection.

It is not guarded by a ChromeOS config variable because those lines are
always intended to be input GPIOs, regardless of whether we're running
ChromeOS or not.

Change-Id: Id76008931b5081253737c6676980a1bdb476ac09
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3067
Tested-by: build bot (Jenkins)
18 months agoSnow: Fix the recovery GPIO polarity, and lid GPIO polarity and number.
Gabe Black [Wed, 10 Apr 2013 21:39:09 +0000 (14:39 -0700)]
Snow: Fix the recovery GPIO polarity, and lid GPIO polarity and number.

Change-Id: I34097f878291367b28962048190e11ccaacfc514
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3066
Tested-by: build bot (Jenkins)
18 months agoARM: Unmask aborts very early in the bootblock.
Gabe Black [Wed, 10 Apr 2013 21:32:56 +0000 (14:32 -0700)]
ARM: Unmask aborts very early in the bootblock.

It's better to recognize aborts when they occur than to mask them to
discover them later without knowing where they actually came from.

Change-Id: Ic8f5321415f411afac94b5ef9dd440790df6d82c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3065
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
18 months agoExynos5250: Use new chip settings for the cpu
Ronald G. Minnich [Tue, 9 Apr 2013 21:35:35 +0000 (14:35 -0700)]
Exynos5250: Use new chip settings for the cpu

Properly use the chip settings when configuring the CPU,
at this point being purely graphics.

Change-Id: I9bc2d32c1037653837937b314e4041abc0024835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3054
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
18 months agoGOOGLE/SNOW: add edp support to ramstage
Ronald G. Minnich [Tue, 9 Apr 2013 21:39:34 +0000 (14:39 -0700)]
GOOGLE/SNOW: add edp support to ramstage

Add basic edp support to the ramstage. Not working.

Change-Id: I15086e03417edca7426c214e67b51719d8ed9341
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3055
Tested-by: build bot (Jenkins)
18 months ago[2/2] tps65090: re-factor for coreboot
David Hendricks [Wed, 10 Apr 2013 00:20:07 +0000 (17:20 -0700)]
[2/2] tps65090: re-factor for coreboot

This does basic re-factoring to fit the driver into coreboot.

Change-Id: Id5f8c12a73ec37ddd545d50b3e8e9b3012657db1
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3061
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months ago[1/2] initial import of TI TPS65090
David Hendricks [Tue, 9 Apr 2013 23:58:02 +0000 (16:58 -0700)]
[1/2] initial import of TI TPS65090

This imports TPS65090 PMIC from u-boot and adds/updates Makefiles
and Kconfig files. The follow-up patch will re-factor the code.

Change-Id: Ic9e43b9665ddf7f55feae8fa17fbf3d2d5f4756d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3060
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoGOOGLE/SNOW: clean up the device tree
Ronald G. Minnich [Tue, 9 Apr 2013 21:32:32 +0000 (14:32 -0700)]
GOOGLE/SNOW: clean up the device tree

This is a simpler device tree that is also more correct,
and has graphics settings as well.

Change-Id: I342d8be7dddb76e6992876c73f5c625c926977d3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3053
Tested-by: build bot (Jenkins)
18 months agoexynos5: Re-factor I2C code
David Hendricks [Fri, 5 Apr 2013 23:11:12 +0000 (16:11 -0700)]
exynos5: Re-factor I2C code

This re-factors the Exynos5 I2C code to be simpler and use the
new API, and updates users accordingly.

- i2c_read() and i2c_write() functions updated to take bus number
  as an argument.

- Get rid of the EEPROM_ADDR_OVERFLOW stuff in i2c_read() and
  i2c_write(). If a chip needs special handling we should take care
  of it elsewhere, not in every low-level i2c driver.

- All the confusing bus config functions eliminated. No more
  i2c_set_early_config() or i2c_set_bus() or i2c_get_bus(). All this
  is handled automatically when the caller does a transaction and
  specifies the desired bus number.

- i2c_probe() eliminated. We're not a command-line utility.

- Let the compiler place static variables automatically. We don't need
  any of this fancy manual data placement.

- Remove dead code while we're at it. This stuff was ported early on
  and much of it was left commented out in case we needed it. Some
  also includes nested macros which caused gcc to complain.

- Clean up #includes (no more common.h, woohoo!), replace debug() with
  printk().

Change-Id: I8e1f974ea4c6c7db9f33b77bbc4fb16008ed0d2a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3044
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoreplace device/i2c.h with simpler version
David Hendricks [Fri, 5 Apr 2013 20:42:39 +0000 (13:42 -0700)]
replace device/i2c.h with simpler version

The existing header was imported along with the Exynos code and left
mostly unchanged. This is the first patch in a series intended to
replace the imported u-boot I2C API with a much simpler and cleaner
interface:

- We only need to expose i2c_read() and i2c_write() in our public API.
  Everything else is board/chip-dependent and should remain hidden
  away.

- i2c_read and i2c_write functions will take bus number as an arg
  and we'll eliminate i2c_get_bus and i2c_set_bus. Those are prone to
  error and end up cluttering the code since the user needs to save
  the old bus number, set the new one, do the read/write, and restore
  the old value (3 added steps to do a simple transaction).

- Stop setting default values for board-specific things like SPD
  and RTC bus numbers (as if we always have an SPD or RTC on I2C).

- Death to all the trivial inline wrappers. And in case there was any
  doubt, we really don't care about the MPC8xx. Though if we did then
  we would not pollute the public API with its idiosyncrasies.

Change-Id: I4410a3c82ed5a6b2e80e3d8c0163464a9ca7c3b0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3043
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoexynos5-common: Enable fimd_bypass and minor cleanup
Ronald G. Minnich [Tue, 9 Apr 2013 21:29:42 +0000 (14:29 -0700)]
exynos5-common: Enable fimd_bypass and minor cleanup

Basic cleanup, this code still does not work.

Change-Id: I84ed9f08fd04cd8eb74cd860e0775d8c602f42d6
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3049
Tested-by: build bot (Jenkins)
18 months agoarmv7: replace read/write macros with inlines
David Hendricks [Tue, 9 Apr 2013 03:01:18 +0000 (20:01 -0700)]
armv7: replace read/write macros with inlines

This enables type checking for safety as to help prevent errors like
http://review.coreboot.org/#/c/3038/ . Now compilation fails if the
wrong type is passed into readb/readw/readl/writeb/writew/writel
or other macros in io.h.

This also deprecates readw/writew. The previous definition was 16-bits
which is incorrect since wordsize on ARMv7 is 32-bits and there was
only 1 instance of writew (#if 0'd anyway). Going forward we should
always use read{8,16,32} and write{8,16,32} where N specifies the
exact length rather than relying on ambiguous definition of wordsize.

Since many macros relied on __raw_*, which were basically the same
(minus data memory barrier instructions), this patch also gets rid
of __raw_*. There were parts of the code which ended up using these
macros consecutively, for example:
setbits_le32(&regs->ch_cfg, SPI_CH_RST);
clrbits_le32(&regs->ch_cfg, SPI_CH_RST);

In such cases the safe versions of readl() and writel() should be
used anyway.

Note: This also fixes two dubious casts as to avoid breaking
compilation.

Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/3045
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
18 months agoslippy: Initial mainboard commit 31/49531/3
Duncan Laurie [Mon, 29 Apr 2013 22:10:31 +0000 (15:10 -0700)]
slippy: Initial mainboard commit

BUG=chrome-os-partner:19035
BRANCH=none
TEST=manual: build slippy mainboard

Change-Id: I33876b90902d4a08d760eb482b08ba41be6e3695
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49531
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agohaswell: Update ULT microcode to rev 'a' 47/49647/2
Duncan Laurie [Tue, 30 Apr 2013 18:09:57 +0000 (11:09 -0700)]
haswell: Update ULT microcode to rev 'a'

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: Build and boot on wtm2

Change-Id: I714208da23bf7cbd1232874c05ad3100551f5f7c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49647
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agosmi: Update mainboard_smi_gpi() to have 32bit argument 30/49530/2
Duncan Laurie [Mon, 29 Apr 2013 22:04:30 +0000 (15:04 -0700)]
smi: Update mainboard_smi_gpi() to have 32bit argument

With the LynxPoint chipset there are more than 16
possible GPIOs that can trigger an SMI so we need
a mainboard handler that can support this.

There are only a handful of users of this function
so just change them all to use the new prototype.

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: build and boot on wtm2

Change-Id: I3d96da0397d6584f713fcf6003054b25c1c92939
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49530
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agoelog: Make sure the elog data structures are initialized in elog_clear. 03/49303/3
Gabe Black [Fri, 26 Apr 2013 00:21:58 +0000 (17:21 -0700)]
elog: Make sure the elog data structures are initialized in elog_clear.

If elog_clear is called before other elog functions, for instance if it's
called through an SMI immediately after the system boots, then the elog data
structures won't have been set up and the system will go off the deep end.
This change adds a call to elog_init to elog_clear to make sure things things
are always initialized before we start using them.

BUG=chrome-os-partner:18734
TEST=Built and booted on Link. Before this change, this command would cause
the system to lock up if run immediately after boot:

echo 1 > /sys/firmware/gsmi/clear_eventlog

After this change, that results in the log being cleared correctly.
BRANCH=None

Change-Id: I45027f0dbfa40ca8c581954a93b14b4fedce91ed
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49303
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
18 months agohaswell: Configure PCH power sharing for ULT 29/49329/2
Duncan Laurie [Fri, 26 Apr 2013 17:35:19 +0000 (10:35 -0700)]
haswell: Configure PCH power sharing for ULT

This reads PCH power levels via PCODE mailbox and writes the
values into the PMSYNC registers as indicated in the BWG.

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: boot on WTM2 and read PMSYNC registers and
compare to the values read from PCU

Change-Id: Iddcdef9b7deb6365f874f629599d1f7376c9a190
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agolynxpoint: Updates to power management and clock gating 30/49330/2
Duncan Laurie [Fri, 26 Apr 2013 17:41:33 +0000 (10:41 -0700)]
lynxpoint: Updates to power management and clock gating

Slight tweaks found when looking at latest ref code when
investigating package C-state issues.

A few bits in the clock gating register don't match the
documentation and are also cleaned up.

BUG=chrome-os-partner:16862
BRANCH=none
TEST=manual: Build and boot on wtm2 board

Change-Id: I36ced7280c160b114c70b2eeafc8b24813ff2f6a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49330
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
18 months agox86: use proper types for interrupt callbacks 70/48970/2
Aaron Durbin [Tue, 23 Apr 2013 15:25:34 +0000 (10:25 -0500)]
x86: use proper types for interrupt callbacks

The mainboard_interrupt_handlers() argument for the function
pointer was using void * as the type. This does not allow the compiler
to catch type differences for the arguments. Thus, some code has been
committed which violates the new interrupt callbacks not taking any
arguments. Make sure the compiler provides a type checking benefit.

Change-Id: I268ec8e16929080955751ef518d65b91895e4308
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48970