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