The EC doesn't return any data when one performs a write to
VBNV context. Therefore there is a mismatch of expectations.
Correct this by properly setting the expected response length.
BUG=chrome-os-partner:31148
BRANCH=None
TEST=No longer hanging while writing to VBNV on ryu.
Change-Id: I7077a507c3280358dac1f88ece62cacee9b71bea
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c1735c3377163aeb9e90155cb9f081a1eea919c9
Original-Change-Id: I455724f20f5442bd62a792f09273227417475f07
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/211137
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8826
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
SERIRQ_CONTINUOUS_MODE is specific feature of LPC busses.
This fixes a KCONFIG unmet dependency warning on ARM mainboards with
chromeec.
Change-Id: Iae61986219585dcb1124cf3b24fa32a8596d56c8
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8665
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The existing code generated invalid ACPI processor objects
if the core number was greater than 9. The first invalid
object instance was autocorrected by Linux, but subsequent
instances conflicted with each other, leading to a failure
to boot if more than 10 CPU cores were installed.
The modified code will function with up to 99 cores.
Change-Id: I62dc0eb61ae2e2b7f7dcf30e9c7de09cd901a81c
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8422
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The EC can export ALS information if the sensor is attached
to it directly rather than to the host. This adds a basic
ACPI ALS device and implements the required information.
The kernel does not use the _ALR tuple set but it is required
by the ACPI spec so this just adds the sample two point
response curve defined in ACPI 5.0 section 9.2.5.
The EC does not currently send events for lux value changes so
a polling interval of 1 second is defined.
BUG=chrome-os-partner:24208
BRANCH=None
TEST=build and boot on samus, add acpi-als driver to the kernel
and read /sys/bus/iio/devices/iio:device0/in_illuminance_raw
Original-Change-Id: Id29b72a68aa21c1a7c71d5f87223ac010cef0377
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203743
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 81f44b33b87a6ee3079b8ef6efffacd0eeb0283f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5a0ccd30e8b453675beaf7d0363dbfa162bd5b3f
Reviewed-on: http://review.coreboot.org/8132
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the empty weak function clear_recovery_mode_switch().
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set, turning the
device off and on again with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Original-Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Original-Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197780
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Sheng-liang Song <ssl@google.com>
Original-Tested-by: Sheng-liang Song <ssl@google.com>
(cherry picked from commit 18908bb64cef34ca41812814817ef887961bed34)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I71ca9f3ea8d816c865375ec66a0603ca211f23ae
Reviewed-on: http://review.coreboot.org/7895
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c06c69d580ee3ec0a3892ebf164a5fe)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SPI drivers for tegra and exynos5420 have code in them which waits for a
frame header and leaves filler data out. The SPI driver shouldn't have support
for frame headers directly. If a device uses them, it should support them
itself. That makes the SPI drivers simpler and easier to write.
When moving the frame handling logic into the EC support code, EC communication
continued to work on tegra but no longer worked on exynos5420. That suggested
the SPI driver on the 5420 wasn't working correctly, so I replaced that with
the implementation in depthcharge. Unfortunately that implementation doesn't
support waiting for a frame header for the EC, so these changes are combined
into one.
BUG=None
TEST=Built and booted on pit. Built and booted on nyan. In both cases,
verified that there were no error messages from the SPI drivers or the EC
code.
BRANCH=None
Original-Change-Id: I62a68820c632f154acece94f54276ddcd1442c09
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/191192
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4fcfed280ad70f14a013d5353aa0bee0af540630)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id8824523abc7afcbc214845901628833e135d142
Reviewed-on: http://review.coreboot.org/7706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Provide ASL to support the AUX port (a.k.a Mouse) found at
0x60,0x64 irq 12 on this EC.
Change-Id: I6969ae4d492570136a8e14e42509638857e1ed85
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7650
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
There were instances of unneeded arch/hlt.h includes,
various hlt() calls that weren't supposed to exit (but
might have) and various forms of endless loops around
hlt() calls.
All these are sorted out now: unnecessary includes are
dropped, hlt() is uniformly replaced with halt() (except
in assembly, obviously).
Change-Id: I3d38fed6e8d67a28fdeb17be803d8c4b62d383c5
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7608
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The in source comment:
/* This function avoids an error on serial console. */
refers to the resource allocator needing to find a non-NULL
function pointer else complaints of "... missing read_resources"
will be spewed.
Unfortunately/fortunately (depending on the time of day) compiler
optimisers have gotten a bit better at optimising away no-op functions
leading to the very message these stubs attempted to avoid. By using
the DEVICE_NOOP formalism that is static inlined 'suggests' (not enforces)
to the compiler to keep these symbols around.
Change-Id: I182019627b6954a4020f9f70e9c829ce3135f63c
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7598
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The DPTF charger particpant device needs to be notified when the
AC state changes so it can re-evaluate the PPCC object and apply
the proper charge rate limit if necessary.
Change-Id: I6723754e2fe12862f50709875140fcadcddb18eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189029
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Brad Geltz <brad.geltz@intel.com>
(cherry picked from commit ed1ee577014421b021e8814edc91a1b696bf9eed)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Update the ec_commands header (direct from EC source) and
add support for the new charger current limit interface
which will be used by DPTF.
Change-Id: Ia9a2a84b612a2982dbe996f07a856be6cd53ebdb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185758
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 1fcca2d75856ecefd3aeb1c551182aa76d649466)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6925
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
OEM strings should not be handled by mobo code but by common code with strings
collected from all devices.
Change-Id: Ibde61a1ca79845670bc0df87dc6c67fa868d48a9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6788
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
It's the third minipcie slot in x200.
Change-Id: Ibfa8d787698cd23b4abcffe5cff2d62039cf0f86
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6641
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8df6cdbcacb082af88c069ef8b542b44ff21d97a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6616
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Currently the workaround for indicating a "full" battery kicks
in at 3%, but this turns out to be too high for some devices.
So move the workaround start point to 6% from full, or 94%.
Change-Id: Ib4305df3a68e89f3a10a096d0e89d8105ea9037b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 982dc496a0553c90dee56fda6411b7c21a5d7da9)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6521
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC recently added events for Thermal and Battery shutdown
to provide some sort of notification to the OS that it is
about to pull power.
Original-Change-Id: Ibbdb5f11b8fa9fc80612a3cc10667c612420b1bb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167301
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Duncan Laurie <dlaurie@google.com>
(cherry picked from commit 03a53ed5e58caa018d49df193510d95bdf5bed7b)
Change-Id: I0cdf89a60b541840029db58d49921340e7ab60eb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167314
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 16d00848f48da83f6d6c813137a35af45bb05c4b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6458
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This makes S3 work.
Change-Id: Ife14372f5f9bb151d7e6e98c6069eb99d5369baf
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6392
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Fixed spelling and added empty lines to separate the help
from the text automatically added during make menuconfig.
Change-Id: I6eee2c86e30573deb8cf0d42fda8b8329e1156c7
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
Reviewed-on: http://review.coreboot.org/6313
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Whenever spi_xfer is called and whenver it's implemented, the natural unit for
the amount of data being transfered is bytes. The API expected things to be
expressed in bits, however, which led to a lot of multiplying and dividing by
eight, and checkes to make sure things were multiples of eight. All of that
can now be removed.
BUG=None
TEST=Built and booted on link, falco, peach_pit and nyan and looked for SPI
errors in the firmware log. Built for rambi.
BRANCH=None
Change-Id: I02365bdb6960a35def7be7a0cd1aa0a2cc09392f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192049
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6175
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The spi_flash_probe and and spi_setup_slave functions each took a max_hz
parameter and a spi_mode parameter which were never used.
BUG=None
TEST=Built for link, falco, rambi, nyan.
BRANCH=None
Change-Id: I3a2e0a9ab530bcc0f722f81f00e8c7bd1f6d2a22
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/192046
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
[km: cherry-pick from chromium]
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/6174
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Comment #endif /* FOO */ pairings.
Alphabetise headers and remove any #if CONFIG_ guards around them.
Background rational:
Remove guarding the inclusion of headers based on CONFIG_ options. This
*potentially* could hide issues such as functions being swapped from
under our feet, since different runtime behaviour could be declared with
the same function same name and type-signature. Hence, depending on the
header we happen to get may change runtime behaviour.
Change-Id: Ic61bdfb64d99f0e2998c6451ae6686915b7bb3d4
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6059
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
It's helpful to have a generic function that will tell
the EC to reboot if the EC isn't running a specified
image. Add that and implement google_chromeec_early_init()
to utilize the new function still maintaing its semantics
of if recvoery mode is enabled the EC should be running its
RO image. There is a slight change in that no communication
is done with the EC if not in recovery mode.
BUG=chrome-os-partner:24133
BRANCH=rambi,squawks
TEST=Built and boot with recovery request. Noted EC reboot.
Change-Id: I22240f6a11231e39c33fd79796a52ec76b119397
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182060
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/5039
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The PATx methods will be passed a temperature in deci-kelvin,
so it needs to be converted back to kelvin before being sent
to the EC.
The PAT disable method is changed to take the temperature ID
as an argument so individual sensors can be disabled.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi, load esif_lf kernel drivers and
esif_uf userspace application. Start and stop DPTF and see
that temperature thresholds are set to sane values.
Change-Id: Ieeff5a5d2d833042923c059caf3e5abaf392da95
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182023
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5036
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The EC now supports two auxiliary programmable trip points for
thermal monitoring. These are expected to be used by DPTF and
need to be exported.
In order to support these the header was updated from the latest
chrome ec source.
BUG=chrome-os-partner:17279
BRANCH=rambi
TEST=build and boot on rambi
Change-Id: I257d910daac4e36280c0cecf4129381a32ffcb9a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181661
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5027
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is a empty struct that has propagated through the superio's & ec's
but really does nothing. Time to get rid of it before it adds yet more
cruft. However, since this touches many superio's at once we do this in
stages by first changing the function type to be a pure procedure.
Change-Id: Ibc732e676a9d4f0269114acabc92b15771d27ef2
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5617
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Rudolf Marek <r.marek@assembler.cz>
This is not complete yet but it compiles and doesn't cause
any issues by itself. It is tied into the EC pretty closely
so that is part of the same commit.
Once we have more of the EC support done it will need some
more work to make use of those new interfaces properly.
BUG=chrome-os-partner:17279
BRANCH=none
TEST=build and boot on rambi, dump DSDT and look over \_SB.DPTF
Change-Id: I4b27e38baae18627a275488d77944208950b98bd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179459
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5002
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch implements a simple interface between the EC and mainboard
ASL code. This interface does not rely on the preprocessor, and
prevents name conflicts by scoping the interface methods. As this
interface is documented on the coreboot wiki, an in-tree documentation
is not provided.
Change-Id: If0b09be4f5e17cc444539a30f0186590fa0b72b5
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5515
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@gmail.com>
The GP15 ACPI object was used to get the state of the lid. However
GP15 is specific to certain Intel chipsets, and will not always be in
the ACPI namespace. Instead of hardcoding this object, let the
mainboard define it.
Also, document the ACPI interface for the EC.
Change-Id: I02a2eb3116af61ea5701f84507327aa40218597a
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/5444
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Some boards need to override which IRQ the i8042 keyboard
controller has its interrupt on instead of the default
IRQ#1. The SIO_EC_PS2K_IRQ macro provides the mainboard
an ability to override the interrupt location.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. New IRQ is correctly
picked up by kernel allowing keyboard support.
Change-Id: Ic2b222018dfc3aa30e24a31009e832ae0fb7e9cf
Reviewed-on: https://chromium-review.googlesource.com/177222
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4978
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
FixedIO seems like a nice short version of IO but in reality
it is limited to 10-bit ISA addresses and so should not really
be used in most situations.
Change all the references to use IO() directly instead.
BUG=chromium:311294
BRANCH=none
TEST=emerge-samus chromeos-coreboot-samus and check for iasl
warnings using updated iasl compiler revision 20130117.
Boot the imge and ensure that EC regions are still exported
in /proc/ioports.
Change-Id: I54de65892bed9e43dbba916990cf2b70c370843c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174810
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4910
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Without these delays on fast systems like X230 the port is read before it's
updated.
Change-Id: I3e01fc348cc5170cec108a05095ba301055ed6b0
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4617
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
To be consistent with touchpad counterpart.
Change-Id: I72d09b41b964f80a81fbf409ef69dd368834a3e2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4654
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
To stay in line with wwan and bluetooth.
Change-Id: Iafe2dc97fc2aec5c2ad1834659b796a6b079c1bc
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4652
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Useful for accessibility.
Sticky modifier (sticky Fn) is a behaviour of modifier key when
you don't have to hold it pressed to achieve the result. E.g.
with normal Fn brightness up is:
<Press Fn> <Press Home> <Despress Home> <Depress Fn>
With sticky Fn you can do:
<Press Fn> <Depress Fn> <Press Home> <Despress Home>
Change-Id: I4da5adcea02428d936023891de08684cae77c44e
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4661
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested on my X201 and X230.
Change-Id: I3c7ec65681157d15c6e87eea64779a08e03ae5a8
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
wwan_enable was never used.
wlan_enable isn't something for device tree but for CMOS config if at all.
Change-Id: I765d9d6f0b73b7dc5a57c0c630a53b4b7a0b48cb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4651
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
THis reduces risks of bufer overflows.
Change-Id: I77f80e76efec16ac0a0af83d76430a8126a7602d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4279
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Two new events possible from the EC for starting and stopping throttle.
These are handled in a per-board method that is defined under the
thermal zone. This is not quite where I wanted it but the scoping
rules in ACPI don't let me have a defined external object in the
same scope.
Change-Id: I766f07b4365b29df3daa8e45e88f7c38c645c287
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63988
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4415
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Just like bluetooth and wlan it need to be enabled in EC.
Set the appropriate bit in EC if CMOS config says so.
Change-Id: Ia48ca3201f013d3b4c4153f32ff536e06b6a2f6d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4516
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Currently H8 skips important init if unable to access CMOS config.
Change default to enable all features to have a sane system without
using CMOS config.
Change-Id: I4448ccd21beae8ad23eb22391770c6fe3b83e3b4
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4515
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
We will soon need to call google_chromeec_get_board_version to determine
correct DDR SPD. We must do so before DDR is initialized, so allow this
function to be called from romstage.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I882d84e38d11bf66067193a6f408f941f2cf8a81
Reviewed-on: https://gerrit.chromium.org/gerrit/61191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4351
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Instead of depending on exact mobo configure general characteristic whether
dock is configured in romstage or ramstage.
X60 and T60 have superio in dock so it needs to be inited to get serial, so
it should be inited in romstage.
On X201 there is nothing useful that early in boot but it's needed to init more
to get dock working, in particular EC init needs to be done first.
Change-Id: If5072e3dec883a94cd2d5643a92f7f6c3c9feee9
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4294
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead define brightness up/down function and gfx device and use
preprocessor magic to glue it together.
Change-Id: I03074ae07b33c1546d229efc3e80606ddbee6300
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4282
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Do not directly check the return value of get_option, but instead compare
the returned value against a CB_CMOS_ error code, or against CB_SUCCESS.
Change-Id: I2fa7761d13ebb5e9b4606076991a43f18ae370ad
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4266
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The function reads the Build ID and the supported function specification
version from the running EC firmware, and stores a text representation
in the provided output buffer.
Change-Id: I3b647d7f315c9b4922fa9a9c5167a80f6d82e753
Signed-off-by: Peter Stuge <peter@stuge.se>
Reviewed-on: http://review.coreboot.org/3617
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Needed to make dock work on X201.
Change-Id: Id0b32266cacf04bb48530bedf50818c268f947ec
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4081
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Unlike on X60/T60 dock has to be inited at the same time as EC.
Change-Id: If6eb3140c871859ce99027a50908f72bcc560243
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4082
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The EC expects the temperature in 64ths degree C. Alter
it8516e_set_fan_temperature() to just export this interface and
make the calculation more obvious.
Change-Id: Ibe241b7909f4c02b30b1e1200a1850d47695a765
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3785
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add an option to set minimal and maximal PWM percentages when the fan is
in temperature controlled mode. Also fix a non-ascii flaw.
Change-Id: I85ae244bee2145bf17d6c29e93dd4871540985c8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3774
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC firmware expects a 255th while we provide a percentage.
Change-Id: Ib06a061b431ac728329043179800729e39e6166b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3773
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The IT8516E firmware of Kontron supports some selected external sensors
attached to the EC via SMBUS or GPIO16.
Change-Id: I4c451c360a393e916430e3bea04a95847455cef7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3772
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
For devices with ChromeOS EC on SPI bus, use the standard SPI driver interface
(see spi-generic.h) to exchange data.
Note: Only EC protocol v3 is supported for SPI bus.
Change-Id: Ia8dcdecd125a2bd7424d0c7560e046b6d6988a03
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3751
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the new Chrome EC protocol version 3 to Coreboot.
Note, protocol version 3 is not applied on any bus implementations yet.
LPC (x86) and I2C (arm/snow) are still using v2 protocol. The first one to use
v3 protocol will be SPI bus (arm/pit). LPC / I2C will be updated to v3 only
when they are ready to change.
Change-Id: I3006435295fb509c6351afbb97de0fcedcb1d8c4
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3750
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since EC protocol v3, the packet format will be the same for all buses (inclding
I2C, SPI, and LPC). That will simplify the implementation in each individual bus
driver source file.
To prepare for that, we will move the protocol part into crosec_proto.c:
crosec_command_proto, with bus driver in callback "crosec_io".
Change-Id: I9ccd19a57a182899dd1ef1cd90598679c1546295
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Chrome EC protocol V3 has several new command structure and constants defined.
Simply cherry-picking changes from upstream.
Change-Id: I7cb61d3b632ff32743e4fa312e0cc691c1c4c663
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/3748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The LPC-based ChromeOS EC uses several ioport regions to communicate with
the AP. In order for the new unified userspace access method to work, we
need them to be reserved by the BIOS.
Before /proc/ioports shows:
0800-0803
0804-08ff
We'd like just a single 256-byte region at 0x800, but ASL can't handle that.
So this will work:
0800-087f
0880-08ff
Change-Id: I3f8060bff32d3a49f1488b26830ae26b83dab79d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: http://review.coreboot.org/3746
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome EC still does not tolerate SERIRQ in quiet mode
and so the keyboard does not work properly.
Change-Id: I9ab052187c9926ce0e2c86b86dfe987dd6564c1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we are executing VbInit() in coreboot we can end up
in a situation where the recovery reason is consumed during
VbInit (end of romstage) and then the EC is rebooted to RO
during ramstage EC init, thereby losing the recovery reason.
Two possiblities are to remove the EC check+reboot from ramstage
and let it happen in depthcharge. This however means that the
system has to boot all the way into depthcharge and then reboot
the EC and the system again.
Instead if we do a check in romstage before VbInit() is called
then we can reboot the EC into RO early and avoid booting all
the way to depthcharge first.
This change adds a ramstage version the EC init function and
calls it from the shared romstage code immediately after the
PCH decode windows are setup.
Change-Id: I30d2a0c7131b8e4ec30c63eea36944ec111a8fba
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3744
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With LynxPoint-LP the SCI GPE is no longer a GPIO
that is offset by 16. Remove the Add and fix up
the link definition so it is still accurate.
Change-Id: I091141183a09345b5ffe28365583e48019f9f5e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/3742
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The default for this variable should be n, it should only depend on
EC_GOOGLE_CHROMEEC, and it should be (and is) explicitly enabled when
needed. This prevents it from being turned on when the EC bus is SPI.
Change-Id: Idc6651a764be4f055341a36b9b4a58990f050b0c
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3737
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Most PnP drivers align the initialization of their `device_operations`
with spaces. Unify this, so next autogenerated patches always match the
alignment.
Change-Id: I3f6baef6c8bb294c136354754125ea88c07a61a1
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/3479
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Until ME boots (which takes seconds on X201) the reported temperature
is 128 °C which triggers Linux overheat alarm which shuts down.
Pretend temperature is 40°C until ME boots.
Change-Id: Ia49fa03c6eb27f539a23711f2c8ebfde72b1dc18
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3404
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On X201 to enable EHCI debug you need to go through EC if USB power is
disabled so we need to inclue ec.c.
Change-Id: I8f8b7de639ecaebceaa53cd338136befaeec8214
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3405
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Enable UMTS on Lenovo X60 and X201.
Enable radios if no options are available.
Enable dock on Lenovo X201.
Based on my X201 branch.
Change-Id: I6e8d3bbd6a6b1a8e59473dd5cc8125a1583d75df
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/3377
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Port most of the functions found in ec/acpi/ec.c to ACPI Source Language
(ASL). These functions are used to control embedded controllers with the
standard ACPI interface (mostly through i/o ports 0x62 / 0x66).
The following methods are implemented and tested against the power
managements channels of a ITE IT8516E embedded controller:
* WAIT_EC_SC Wait for a bit in the EC_SC register
* SEND_EC_COMMAND Send one command byte to the EC_SC register
* SEND_EC_DATA Send one data byte to the EC_DATA register
* RECV_EC_DATA Read one byte of data from the EC_DATA register
* EC_READ Read one byte from ec memory (through cmd 0x80)
* EC_WRITE Write one byte to ec memory (through cmd 0x81)
To use the provided methods, one should include `ec/acpi/ec.asl` in the
EC device code. Prior doing so, two macros should be defined to identify
the used i/o ports:
* EC_SC_IO I/o address of the EC_SC register
* EC_DATA_IO I/o address of the EC_DATA register
Change-Id: I8c6706075fb4980329c228e5b830d5f4e9b188dd
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3285
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This driver communicates with the IT8516e on the Kontron KTQM77.
Since we don't know if the firmware and protocol are standard for
the chip or customized to the board, call it kontron/it8516e.
Change-Id: I7382172c6d865d60106c929124444821a07a5184
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This used to contain the path for the EC include files, but
those files are included in coreboot now.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4fce9831c5e21b0a69a6295dbda2580e1ca83369
Reviewed-on: https://gerrit.chromium.org/gerrit/47606
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3057
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
"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>
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
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>
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.
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>
Here's the great news: From now on you don't have to worry about
hitting the right io.h include anymore. Just forget about romcc_io.h
and use io.h instead. This cleanup has a number of advantages, like
you don't have to guard device/ includes for SMM and pre RAM
anymore. This allows to get rid of a number of ifdefs and will
generally make the code more readable and understandable.
Potentially in the future some of the code in the io.h __PRE_RAM__
path should move to device.h or other device/ includes instead,
but that's another incremental change.
Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Google ChromeEC is an EC with completely open source firmware.
See https://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/platform/ec.git;a=summary
for the EC firmware source code (aka more information about the ChromeEC)
This patch adds support for the ChromeEC on coreboot's side.
Great thanks to the ChromeEC team for this amazing work. It's another
important milestone towards a free and open firmware stack on modern
hardware.
Change-Id: Iace78af9d291791d2f5f80ccca1587b418738cec
Signed-off-by: Stefan Reinauer <reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/2481
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We're happy to announce coreboot support for the "Butterfly"
Chromebook, a.k.a HP Pavilion Chromebook.
More information at:
http://www.google.com/intl/en/chrome/devices/hp-pavilion-chromebook.html
This commit also includes support for the ENE KB3940Q embedded controller
running on Quanta's firmware.
Change-Id: I194f847a94005218ec04eeba091c3257ac459510
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2359
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The name is derived directly from the device path.
Change-Id: If2053d14f0e38a5ee0159b47a66d45ff3dff649a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The EC allows to select the order in which batteries are (dis)charged.
Make this setting available to the user.
Change-Id: Id2a98192565419dbb53f3a7cf0b2c46b672a3ed8
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/475
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
Logic is inverted (if argument is true, one would expect that
mute is enabled) and the wrong bit was used (1 instead 0)
Change-Id: I71133ba639f1fb0d3c3582f16211dd266a11cc64
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/334
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Those modules have basically the same Super I/O capabilities as
the Docking station. Unfortunately, the Super I/O in the module
shares the same I/O address as the Docking station, so we're not
allowed to connect the LPC Docking Bus if such a module is present.
To be able to detect this device and use it as early console for
coreboot, we have to initialize the GPIO Controller before, as
this device is detected via GPIO06.
Change-Id: If7c38bb6797f76cf28f09f3614ab9a33878571fb
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/282
Tested-by: build bot (Jenkins)
The mute bit is set by ACPI before poweroff/going to suspend.
So clear it after resume, to have working volume control
even if the ACPI doesn't clear it on resume.
OSPM should control Audio mute with ec bit 0x30:6, so it is
safe to clear this bit even if the user has audio muted.
Change-Id: I18bebe532bf21cfb61b3d294a396bf15012f9f1a
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/162
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
If power is unplugged/lost, we should undock the docking station.
The power loss can also be caused by the fact that the user removed
the thinkpad from the docking station without pressing the Undock button/hotkey
first. Without undocking it on this event, the thinkpad LPC switch will still
connect the Docking connector, which causes crashes when docking it again.
Change-Id: I9ed783e491827bde20264868eab2b3a79c232922
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/62
Tested-by: build bot (Jenkins)
Can be used to disable/enable Power output on USB ports.
Change-Id: I5eb52b33c9e3359b0e5874bda2c0c8d75c196bc2
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/37
Tested-by: build bot (Jenkins)
This option is PMH7 specific, and should be moved there,
so all Notebook utilizing a PMH7 have this option.
For Thinkpads without Touchpad (like the X60), simply
don't add 'touchpad' to cmos.layout.
Change-Id: Icdd0093670d565f1b16e2483aa286f4d63ccc52a
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/6
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Can be used to enable/disable Ultrabay power on Thinkpads
who control that with the PMH7. (i.e. T60)
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6546 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
returns 1 if a CDROM/HDD device is plugging in the
ultrabay. Return 0 if there's a battery or superio
extensions plugged in.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6545 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
My Notebook gets far to hot without fan, so just enable automatic
fan control by default.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Sven Schnelle <svens@stackframe.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6490 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Move the EC support code from the X60 mainboard to a generic
driver, as this EC is used in many thinkpads. Also move the
ACPI code to this directory for this reason.
This patch also adds a chip config, so that the initial setting
for basic register can be specified in devicetree.cb
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6485 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Patrick Georgi <patrick@georgi-clan.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6326 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Lenovo PMH7 (Power Management Hardware Hub) is found in
most recent (starting with X60/T60 AFAIK) Lenovo/IBM Laptops.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Patrick Georgi <patrick.georgi@secunet.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6325 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Adds a new src/ec subdir for embedded controllers (mostly found in laptops)
and converts Getac P470 and Roda RK886EX to use the new ACPI EC instead
of having their own copies of those functions.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6304 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Aaron Durbin