Currently, when a host command is received which would overlap with an
ongoing host command, we ignore it silently. This commit simply logs a
line to the EC console stating that we are ignoring the overlapping host
command.
BRANCH=None
BUG=chrome-os-partner:23806
TEST=make -j buildall tests
TEST=Build, flash, and boot samus. Using ectool, read 64K from flash
while also querying the current EC switch positions. Observe the log
message being printed to the EC console.
Change-Id: Ic0d249ccec2efb9600bcf8567392add1ee6295d9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/290545
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Allow more than one SPI master.
Add CONFIG variables to address the system SPI flash.
To have SPI master ports, spi_ports array must be defined.
BRANCH=smaug
TEST=compile
BUG=chrome-os-partner:42304
Change-Id: Id43869f648965c1582b7be1c7fb3a38f175fda95
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/288512
Commit-Queue: David James <davidjames@chromium.org>
Avoid duplicating servo configurations for every chip.
BRANCH=none
BUG=chrome-os-partner:22990
TEST=None. This is an intermediate step to make it clear what's happening.
CQ-DEPEND=CL:273950
Change-Id: I448543b6ab9d39423955e8d2589b6035c59e838a
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273906
Reviewed-by: Randall Spangler <rspangler@chromium.org>
mutex_lock() is called from MEC1322_IRQ_ACPIEC0_IBF
interrupt context, causing deadlock and assertion
in __wait_evt().
In the interrupt context it now checks for mutex lock first.
If the mutex is already locked,, it will disable ACPI
interrupts and defer the memmap mutex lock.
Added LPC interrupt disable/enable functions as needed.
Increased deferred function count where needed.
BRANCH=None
BUG=chrome-os-partner:40820
TEST=Test for suspend-resume, cold, warm reboots and
other general stability.
Change-Id: I3dda0d4635a6b6281faf200c8c7b6fcba8877254
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/280418
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
This unifies all the EC header files to use __CROS_EC_FILENAME_H
as the include guard. Well, except for test/ util/ and extra/
which use __TEST_ __UTIL_ and __EXTRA_ prefixes respectively.
BUG=chromium:496895
BRANCH=none
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Iea71b3a08bdec94a11239de810a2b2e152b15029
Reviewed-on: https://chromium-review.googlesource.com/278121
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no need for the usb flag, remove it.
There is no need for the unprotect flag, remove it.
BRANCH=none
BUG=chrome-os-partner:22990
TEST=run flash_ec before and after
Change-Id: I201bad7f5be63a90bb8168e21baef2c6fa8d85b4
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273904
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Now that we've removed boards from ToT, also delete board-specific
code used only by the removed boards.
There are still more things to remove (unused charging chips, LED
drivers, COMx support). More CLs coming.
BUG=chromium:493866
BRANCH=none
TEST=make buildall -j
Change-Id: Ie6bdeaf96e61cadd77e3f6336c73b9b54ff4eabb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/276524
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Allow timeout to be set at runtime by controller.
BUG=chrome-os-partner:40780
TEST=Manual on Glados. Verify PD I2C communication is functional.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I582e47c7bebfed7a639789c90064d86ffe1a5401
Reviewed-on: https://chromium-review.googlesource.com/274967
Reviewed-by: Alec Berg <alecaberg@chromium.org>
i2c_xfer was previously implemented at the chip-level, but now we want
to add some global retry logic. Rename the chip-level i2c_xfer functions
to chip_i2c_xfer and add a new global wrapper function i2c_xfer.
BUG=chrome-os-partner:39613
TEST=Run "battery" from EC console on Cyan, verify that values + strings
are correctly printed.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: If37c85cc3cf94fd53feb6931553e10c30ad6cad6
Reviewed-on: https://chromium-review.googlesource.com/272939
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our existing GPIO macros use port# / gpio#, but the concept of different
GPIO ports does not exist on the mec1322. Therefore, add new GPIO macros
for chips which do not have distinct GPIO ports.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: Ibda97c6563ad447d16dab39ecadab43ccb25174b
Signed-off-by: Steven Jian <steven.jian@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/262841
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Since stm32 and mec1322 now support open-ended i2c_xfer, we can move the
lm4 i2c_read_string implementation to common code and delete all
chip-specific versions.
BUG=chrome-os-partner:39613
TEST=Run "battery" from EC console on Cyan and Oak, verify that battery
info + strings are correctly printed.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I06369df64bb2eb747d163664b4c96eeacb4b1faa
Reviewed-on: https://chromium-review.googlesource.com/272938
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
- Use CONFIG_*_MEM when dealing with images in program memory.
- Use CONFIG_*_STORAGE when dealing with images on storage.
- Use CONFIG_WP when dealing with the entire WP RO region.
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Manual on Cyan with subsequent commit. Verify that FMAP matches
actual layout of image. Verify flashrom succeeds flashing + verifying EC
image using host command interface.
BRANCH=None
Change-Id: Iadc02daa89fe3bf07b083ed0f7be2e60702a1867
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270269
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On hard reset / hibernate, RAM will be erased and panic data will
normally be lost. When software panic data saving is enabled, try to
save this data just before hard reset and restore it when we come back
up.
BUG=chrome-os-partner:37380
TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash
divzero" on console. After hard reset, verify that "panicinfo" dumps
data and shows divzero exception code.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb
Reviewed-on: https://chromium-review.googlesource.com/255912
Reviewed-by: Randall Spangler <rspangler@chromium.org>
All current boards in ToT place pstate at the end of the RO section.
Remove the unused option to place it at the end of the RW section;
we'll never do that again.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I0d279a4c9786bb33367a7387423481cc9b94e115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253636
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The new toolchain is putting again the __enter_hibernate function in
flash (.text) rather than in SRAM (.iram.text) after inlining both the
hibernate() and __enter_hibernate() function.
Workaround this issue by forcing "noinline" on __enter_hibernate().
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=all
BUG=chrome-os-partner:35774
TEST=make BOARD=samus dis
and check the disassembly, the __enter_hibernate is called in SRAM
through a veneer.
Change-Id: I015928ebe18ba8fd93252eece3e8a0fcf4b2a037
Reviewed-on: https://chromium-review.googlesource.com/242691
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
If the AP ignores the LPC_ST_BUSY bit (which is software-defined) and
tries to send a second host command while the first one is still
processed, we discard it.
This doesn't prevent the host to re-write the command arguments stored
in LPC shared mem (aka LPC_POOL_CMD_DATA) but when we will call
host_packet_receive, we will have either the old arguments or the new
arguments (or even a mix of both, which is less unlikely to pass the
checksum check), and we will copy them once before calling the HOSTCMD
task. So the host command task will have a single coherent (not
changing) view of the arguments when performing its input validation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:31492 chrome-os-partner:23806
TEST=Boot Samus and play with ectool
Change-Id: I9aa1b8cdac05e323b91998188bd873826e83c274
Reviewed-on: https://chromium-review.googlesource.com/242593
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Chipset sometimes needs I2C, therefore i2c_init should have a higher priority
than power_common_init so i2c is available by the time the chipset might be
talking to the battery.
BUG=chrome-os-partner:35502, chrome-os-partner:35173
TEST=There is no "battery not responding" message at startup on veyron
TEST=EC boot takes less than 1 second on veyron
BRANCH=none
Change-Id: Ib10b653decc7703e706d4dd1976abf0fdbc25ac2
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241102
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The recent change to decrease the time to wake up from deep sleep when
not using LFIOSC was too agressive. Increase the time to wake up based
upon the worst observed case.
BUG=chrome-os-partner:35184
TEST=Manual on Samus. Go to deep sleep, verify that no "overslept by
Xus" prints are seen.
BRANCH=Samus
Change-Id: Ib9fe2eba5e29a112e03fffaedbc5ae53d6d650ff
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239242
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Decrease the time to wake up from deep sleep when not using
LFIOSC (when using PIOSC in deep sleep). This helps keep us
in deep sleep longer and therefore save power.
BUG=none
BRANCH=samus
TEST=Load onto samus and run for a couple of hours, varying from
S0 to S5, with and without EC. Use idlestats to check that closest
we get to missing deadline is 86us away.
Change-Id: I3eee908e9f42a1c5b549e93d63588a3cb6e29a5d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238412
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The fans on samus have a recommended minimum duty cycle of 20%
while running, but 30% in order to start. We've been using the
EC's built-in fan controller for the start requirement, but it
has a minimum fast-start duty cycle of 50%. It turns out that
that speed is noticeably noisy.
This change handles the startup with logic in the EC instead, so
that the fan only tries to spin at 30% initially (or if it drops
too much below the minimum turning speed).
BUG=chrome-os-partner:33429
BRANCH=ToT,samus
TEST=make buildall -j
Boot the system, let it idle with the browser windows closed, the
browse a bit, then idle. Listen for changes to the fans.
Before, I could hear the fans kick in and out as the AP load
changed. Now it's much quieter.
Change-Id: Id35215520c064eb6843686ec8bb5f3618dac6cf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BRANCH=master
BUG=chrome-os-partner:29139
TEST=Buiid an EC FW image and run on Rambi to test if key loss is
improved and any side effect somes with this change. Need more test
units to confirm this.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: I2399e33d2ca3defe8cd9b1f94ab0af1db7f84635
Reviewed-on: https://chromium-review.googlesource.com/225557
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mohammed Habibulla <moch@chromium.org>
Updating the fan speeds according to the manufacturer's specs.
The fan vendor recommends that the minimum fan speed be a 20%
duty cycle. Since the built-in fan controller has a tach-based
feedback loop, I'm using the RPM value instead of the duty cycle
(20% is 2286 RPM, according to the vendor).
The vendor also wants a 30% duty cycle to start turning, but the
built-in fan controller provides support for fast-start too. The
controller's minimum fast-start duty cycle is 50%, but it also
has a programmable number of revolutions that it will wait before
backing off.
Holding my ear down close to the fans while they start and stop,
it seems that the minimum 2 revolution start period is sufficient
and provides the least noise. Of course, since I've never had any
problems starting the fans directly at 1000 RPM this noise is a
little more noticeable than that. It's quite possible that the
built-in controller is smart enough to make 1000 RPM work by
bumping the duty cycle up until the fans turn even if the fans
don't like it.
BUG=chrome-os-partner:32892
BRANCH=ToT,samus
TEST=manual
Listen closely and run the EC console "faninfo" command to see
the fans start and stop as the system boots and idles.
Change-Id: I47c9e7cef3f9f4bd815a13032fe10234decd62ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224830
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The valid and writable flags the EC sends back to the AP are incorrect.
They are a little bit different on differnt chips, so let's move it to
flash physical layer. This is not any causing problem, but we should fix
this.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222661
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added atomic or/clear when modify a share register
LM4_SYSTEM_SRI2C_ADDR among different i2c ports.
BUG=None
BRANCH=ToT
TEST=Verified on Samus.
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Change-Id: Ibf64b05a800ce2b8ddf9735bd3a762ab02031bc8
Reviewed-on: https://chromium-review.googlesource.com/213196
Reviewed-by: Alec Berg <alecaberg@chromium.org>
When the EC sends longer commands to the PD chip (such as flash
erase/write over the passthru from AP), allow it to take a second
instead of the default 100ms timeout.
BUG=chrome-os-partner:30935
BRANCH=none
TEST=samus boots
battery command works from EC console
ectool passthru of flash erase to PD works (requires hacked ectool)
Change-Id: I08ff94f7ac6aee351aa73c9d28b5fd715d463b3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209936
Reviewed-by: Alec Berg <alecaberg@chromium.org>
It would be really nice to be guaranteed to see watchdog warnings
before we actually hit a watchdog reset even if something strange is
going on with the CPU. Let's increase the margin between the timer
and the independent so that the hardware watchdog is really hit as a
last resort.
It seems like a 1.6 second hardware watchdog wouldn't be the end of
the world so let's bump that way rather than increasing the number of
warnings.
BRANCH=ToT
BUG=chrome-os-partner:29162
TEST="waitms 1000" on EC console no longer ever reboots and "waitms
2000" usually does.
Change-Id: Ic5e5ddec22fb8484cc7c552b19d3f2043c105d0c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204895
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Fix bug and actually increase watchdog timeout to 1.8s.
BUG=none
BRANCH=none
TEST=put a 3 second blocking delay in pd_task and make
sure watchdog reboots. set blocking delay to 1.5seconds
and make sure no reboot.
Change-Id: Ie66621a3bd98354f9fd22b9b10a866d004277340
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204471
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Created a new smaller task size, 384, for tasks that don't need much
stack space including PDCMD and ALS tasks.
BUG=none
BRANCH=none
TEST=loaded on samus, ran taskinfo, made sure we were comfortbaly
under the smaller task size for those tasks that changed.
Change-Id: Icfa26eeaeed26171ec8b2d888e1190be32f688d1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202719
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The i2c timeout on lm4 is currently 1 second, which is very long.
This changes it to 100ms. Note, the biggest transfer we might
every do is probably ~256 bytes to do a flash program using a host
command over i2c. And the slowest bus speed is ~100kHz. So, worst
case, the transaction shouldn't be more than about 25ms.
Decreasing the timeout is useful when peripherals are not plugged
in. For example, the ALS is sampled in the hooks task every second.
We don't want the ALS sampling to be delayed for a second because
it will throw off all of our other hooks.
BUG=chrome-os-partner:29003
BRANCH=none
TEST=ran on a samus and tested i2c commands to various peripherals
Change-Id: I5e1b6d0f8b100cbcb6cd9209c6198e31d99bb085
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202515
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With change b610695b61, we fixed a problem
with the number of FP regs that were being saved on the stack. That change
decreased the required stack size for non-FP tasks by 64 bytes, but
increased the size needed for FP tasks (such as the lightbar).
The lightbar task was previously using within 64 bytes of its alloted stack,
so handling the task switching correctly meant that it now overflowed.
The hooks task had the same problem, but was hidden by the lightbar task.
This CL bumps the LARGER_TASK_STACK_SIZE up a bit, and switches the lightbar
task to use it instead of the default size.
BUG=chrome-os-partner:27971, chrome-os-partner:28407
BRANCH=ToT
TEST=Try it on both Link and Samus.
Before this change, the Samus lightbar was overflowing its stack every time
the AP booted (causing the lightbar to do things). With this change, it
doesn't. Here are typical stack sizes after this CL:
Task Ready Name Events Time (s) StkUsed
0 R << idle >> 00000000 28.394913 328/512
1 HOOKS 00000000 0.534085 640/768
2 R LIGHTBAR 10000000 5.359356 520/768
3 CHARGER 00000000 0.094674 384/512
4 CHIPSET 00000000 0.003353 320/512
5 KEYPROTO 00000000 0.002814 312/512
6 HOSTCMD 00000000 0.002942 244/512
7 R CONSOLE 00000000 0.193776 340/768
8 POWERBTN 00000000 0.000392 248/512
9 KEYSCAN 00000000 0.409337 332/512
Change-Id: Ica93608c8adb225410a62ec3a0a27944c479270a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197733
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In some cases, the system will boot to S0 from the point of view of
the EC, but PLTRST# will never deassert. Work around this by waiting
50 ms for PLTRST# to deassert. If it doesn't, force the chipset all
the way down by deasserting RSMRST#, then pulse the power button to
turn it back on.
Also add a powerfail debug command to simulate this failure event, so
that the recovery process can be tested.
Add API to the LPC module to get the state of PLTRST#, and to the
power button state machine to force it released when we shut down the
chipset and and force another power button pulse as we reset the
chipset.
BUG=chrome-os-partner:28422
BRANCH=baytrail
TEST=1. Boot system. Should boot normally. Shut system down.
2. powerfail
3. Boot system. On the EC console, should see the system come up,
go back down through G3S5, then come back up. From the user's
point of view, it just boots.
1. Boot system. Should boot normally. (That is, powerfail is not sticky)
Change-Id: Ia57f196606f79b9f2fce7d9cd109ab932c3571aa
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197523
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Previously, you could use EC_CMD_ACPI_QUERY_EVENT to read events that
were masked off (that is, events which would not generate SCI/SMI/wake
signals). The handlers for those signals on the host would still act
on the masked-off events - for example, causing unwanted power button
keypresses/releases.
Now, EC_CMD_ACPI_QUERY_EVENT will only return events which are unmasked.
This does not affect storing of events at event generation time.
Events are still queued; they won't be dropped until the host attempts
to read the next event. This gives the host a chance to set a mask
later in boot (but before querying any events) to capture events which
happened early in the boot process.
BUG=chrome-os-partner:26574
BRANCH=rambi
TEST=At EC console, type 'hostevent set 0x80' but don't press enter.
Hold down the power button; UI starts fading to white.
Press enter at the EC console to issue the hostevent command.
System should continue shutting down, not fade back as if the
power button were released.
Change-Id: Id2cb14b0979f49cdd42424b9a61b310a2bb506f5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194935
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The KBD_IRQ#, SMI#, and SCI# lines on the host are sensitive to
falling edges. When generating an interrupt, wait long enough to make
sure the lines are high before pulling them low, so that it reliably
generates a falling edge. This solves a problem where calling the
IRQ-generation function twice in rapid succession could cause two low
pulses without an intervening logic-high as seen by the host (and thus
not a falling edge as seen by the host).
This is most visible on the keyboard line, because it can generate
back-to-back events on multi-byte scan codes. Once the keyboard
mailbox is full, the EC will never attempt to fill it, and thus it
also won't attempt to generate another keyboard IRQ. And since the
host missed the IRQ, it doesn't know it needs to empty the mailbox.
It could theoretically happen for the other lines, so fix them now
just to be safe.
This change should be low-impact and free from side effects. 4 usec
is a very small additional delay. Even 65 usec added delay for
SCI/SMI is small, given that SCI/SMI events are typically much less
frequent (if they're happening very frequently, something else is
tragically wrong with the system...)
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard shouldn't get stuck.
Orig-Change-Id: Id4e6de793b1f007f713bac8aa195ddd78feeea3e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
(cherry picked from commit 569651b82e309ddd86b9c165d131e34cb7f7b2b5)
Change-Id: I62a9ad0fa85121b3345c057f0e3fc6b3cc29e97e
Reviewed-on: https://chromium-review.googlesource.com/193174
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
This prevents other task events from continuing the ADC
conversion prematurely; potentially leading to a panic
if the conversion interrupt occurs after the ADC has
been powered down.
BUG=chrome-os-partner:26919
BRANCH=rambi
TEST=Perform ADC conversions while running a deferred function
calling itself on a 10mSec delay. Verify no panics after ~6 hours.
Change-Id: Ic3894849c154b3f058e812b2da816e7cffb12cbf
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191302
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When we are calling the re-scheduling routine at the end of an irq
handling routine, we need to ensure that the high registers are not
currently saved on the system stack.
On Cortex-M3/M4, the compiler is normally doing tail-call optimization
there and behaving properly, but this fixes the fact that insanely large
interrupt handling routines where sometimes not compile and not running
properly (aka issue 24515).
This also prepares for one more core-specific DECLARE_IRQ routine on
Cortex-M0.
Note: now on, the IRQ handling routines should no longer be "static".
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24515
TEST=make -j buildall
revert the workaround for 24515, see the issue happening only without
this CL.
Change-Id: Ic419369231925568df05815fd079ed191a5446db
Reviewed-on: https://chromium-review.googlesource.com/189153
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Refactored the i2c unwedge code to place it in the common directory
so that any EC chip can use it.
Added to the STM32F and LM4 boards, code to automatically detect and
unwedge the i2c bus at the start of an i2c transaction. Note that STM32L
already had this ability.
To enable unwedging of the i2c port though, the gpio pins for SDA and
SCL must be defined in the i2c_ports[] array in the board.c file. This
allows the i2c module to bit bang the unwedging for the given port. If
SDA and SCL are not defined for the port, then the unwedge code will
not run.
BUG=chrome-os-partner:26315, chrome-os-partner:23802
BRANCH=none
TEST=Manual testing on machines with different EC chips.
Testing made extensive use of https://chromium-review.googlesource.com/66389
in order to force wedging of the i2c bus so that we can attempt to unwedge
it. Note that you can easily test if the bus is wedged by running i2cscan.
On pit and spring:
On pit, after each of the following, I verified that the bus was automatically
unwedged.
On spring, the unwedge only runs at reboot, so, for the non-reboot wedge
commands, I manually ran console command unwedge, and verified that the bus
became unwedged.
(1) Bit bang a transaction but only read part of the response.
Command to wedge: i2cwedge 0x90 0 2 2
(2) Bit bang a transaction to do a "write" and stop while the other side is
acking. Command to wedge: i2cwedge 0x90 0 1
(3) Same as (1) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 6 2
(4) Same as (2) but do a reboot instead of returning and see
that the unwedge works at init time w/ no cancelled transactions.
Command to wedge: i2cwedge 0x90 0 5
On glimmer:
Added code to call i2c_unwedge in accel_init(). Then tested unwedging the
accelerometer with the following. One extra difficulty testing this with
the accelerometer is that sometimes the bit you stop on is high, which
means it won't be wedged at all, the next start transaction will reset
the bus. So, sometimes running i2cwedge won't wedge the bus and sometimes
it will depending on the acceleration data.
(1) Big bang transaction to do a "read" of accelerometer and stop partway:
i2cwedge 0x1c 0x0f 2 2
i2cscan to make sure bus is actually wedged
i2cunwedge
i2cscan to make sure bus is now unwedged.
(2) Bit bang transaction to do a "read" and stop partway, then reboot:
i2cwedge 0x1c 0x0f 6 2.
i2cscan to verify that the bus is working after the reboot.
Change-Id: Ie3328e843ffb40f5001c96626fea131c0f9ad9b1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188422
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We copied that delay because it seemed to be necessary on early LM4
chips to avoid glitching the UART. But on current boards (e.g. rambi)
this does not seem to be necessary, and delays boot by 31ms. So,
remove the delay.
BUG=chrome-os-partner:23794
BRANCH=rambi
TEST=boot system; see little to no glitching on EC uart, and system boots ok
hibernate 1; see little to no glitching on EC uart, and system boots ok
Change-Id: I9d4b5927da4282e47e1b09be838104c64f25268c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185232
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This significantly decreases the task swapping overhead when doing
many transfers.
Also fix a bug where on error, i2c_xfer() would issue a stop
condition, but not actually wait for it to complete before returning;
this could interfere with the next transfer in a back-to-back
scenario.
BUG=chrome-os-partner:25015
BRANCH=lm4 (more specifically, rambi and derivatives)
TEST=battery command should show the same info as before
i2cscan should show devices at bus 0 0x12, 0x16, bus 5 0x98
no charger errors on boot
Change-Id: I2195f0f9800b03a54fa33170dbae6705382578c7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182503
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Implement LED color policy (crosbug.com/p/23957)
Update battery vendor information (crosbug.com/p/24684)
BUG=chrome-os-partner:24885
BRANCH=rambi
TEST=manual
system on, lidclose -> power LED off
system on, lidopen -> power LED on
system suspended -> power LED blinks green every 2 sec
system suspended, lid closed -> power LED off
system off -> power LED off
plug AC in, battfake 95 -> charging LED green
plug AC in, battfake 94 -> charging LED orange
unplug AC, battfake 10 -> charging LED off
unplug AC, battfake 9 -> charging LED blinks orange
battcutoff -> after a few sec, system powered down
plug back in AC -> system comes back on
charger -> I_in < 1700
Change-Id: I89161e2c024d85197b8612a40a61dd50c106549e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/181755
