| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ectool gpioget - returns all GPIOs (with flag info)
ectool gpioget <GPIO_NAME> - get value of <GPIO_NAME>
ectool gpioget count - returns number of GPIOs
ectool gpioget all - returns all GPIOs (with flag info)
BUG=chromium:344969
TEST="ectool gpioget [<subcmd> <GPIO_NAME>]" returns correct information
on squawks
BRANCH=none
Change-Id: Ib6f0d8135a76501f08b084bfd7eb1f2689d5d6e0
Signed-off-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196680
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added config option CONFIG_USB_PD_TX_USES_SPI_MASTER which switches
to use SPI master for PD transmit. The advantage of SPI master mode
is at the end of the tranmission, we don't have to send any dummy 0
bits. When the option is set, the CPU_CLOCK must be set to 38.4MHz,
so that the SPI master can generate the correct clock frequency.
BUG=chrome-os-partner:28309
BRANCH=none
TEST=Tested by connecting two fruitpies together across CC1. One
fruitpie has been modified such that the MISO and MOSI lines are
swapped and is running PD TX in SPI master mode with 38.4MHz clock,
while the other is running PD TX in SPI slave mode. On EC console
ran pd charger on one board and pd dev on other board. Verified
that communication works with no errors. Ran for 10 minutes in each
configuration.
Change-Id: Ib24030d34d95d59f4ac6c2dae98bf7adda1ada01
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197215
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Charger V1 only. This is a clearer name for the intent of
the function to override the charging parameters requested
by the battery. This also disabmiguates this function with
a new host command to get and set arbitrary vendor
parameters in the battery.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=`make buildall -j`.
Change-Id: I1e8762d359c0e91c5b2a539553d22c12c9850c03
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195823
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197164
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also adds 'battparam' console command.
BUG=chrome-os-partner:25145
BRANCH=ToT
TEST=Run 'ectool batteryparam set 0 0x1234'
'ectool batteryparam get 0'
and on the console:
'battparam 0'
'battparam 0 0x1234'
on a board that implements parameter 0.
Change-Id: I9cc54d001631f53dd39ae64cfdeececaa1747181
Original-Change-Id: Ib2812f57f2484309d613b23dab12ad43e0417bd2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the micro runtime for Zinger, wait for events with interrupt disabled
to avoid race conditions where the event interrupt happens just after we
tested it and before going to sleep.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make BOARD=zinger, test Zinger PD communication from Firefly.
Change-Id: I10b919450a61fac7ea50e84dd73bcc568150e179
Reviewed-on: https://chromium-review.googlesource.com/197051
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using a "non-servo" debug dongle or integrated FTDI chip to flash a STM32
microcontroller, add the option to toggle the reset of the
microcontroller if the control exists.
This was not done for the original Toad version because it cannot
control the reset line, but now Firefly, Zinger, Fruitpie debug
interfaces can do it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=./util/flash_ec --board=zinger
Change-Id: Ia21e3b3403e56b4c0797582659d9a3a0c26bb8bb
Reviewed-on: https://chromium-review.googlesource.com/197050
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The external interrupts above 15 are not used for GPIO IRQ handling, but
for special purpose interrupts from internal peripherals (e.g. RTC,
comparator, wake-up ...). When processing the GPIO interrupts, we should
explicitly skip those interrupts, else if a GPIO interrupt happens
first followed by another EXTINT, the loop in gpio_interrupt() will try
to process it and do an out-of-bound read of the exti_events array.
This will retrieve a garbage handler triggering a memory fault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=on Firefly, press the buttons to trigger GPIO interrupts while
there are a bunch of comparator interrupt on EXTIN21 (due to on-going
USB PD communication). I no longer see HardFaults.
Change-Id: Id90fab30215b0f7f8060c19de63a7ca8418b7b3c
Reviewed-on: https://chromium-review.googlesource.com/197019
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From time to time (usually under heavy interrupt load), the runtime on
Cortex-M0 was panic'ing at the "svc" instruction with a HardFault
exception (inside the wait_event() function).
The issue was probably the following :
the wait_event() code is doing an atomic_read_clear() whose critical
section disables interrupts and re-enables them using "cpsie i",
then do __schedule() call which is essentially a "svc" instruction.
According to ARMv6-m reference manual :
"If execution of a CPS instruction:
increases the execution priority, the CPS execution serializes that
change to the instruction stream.
decreases the execution priority, the architecture guarantees only that
the new priority is visible to instructions executed after either executing
an ISB instruction, or performing an exception entry or exception
return."
So, when we are executing the "svc", PRIMASK.PM can still be seen as 1
(while it was set to 0 by "cpsie i") and in that case the software
interrupt is replaced by a HardFault.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:28296
TEST=run Firefly board under load for extended periods of time.
Change-Id: Ie355c36f06e6fe2fee5cca8998a469fa096badad
Reviewed-on: https://chromium-review.googlesource.com/196659
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a shortcut in smart battery driver and i2c passthru. Once
the battery cut-off order is submitted (in the factory line),
the EC will no longer talk to battery.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=See below
> remove AC, cutoff: expect system is off.
> cutoff, then remove AC: expect system is off.
> cutoff, wait for 1 min, then remove AC: expect system is off.
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Change-Id: Ied963c19d17d581ce99e4543469cf2fa165f0439
Reviewed-on: https://chromium-review.googlesource.com/196657
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CL fcf26a4 enabled periodically charge_request(). However, that
could fail and generates lots of error message in the EC console if
the AC is not on and charger refuses the request (even it is 0v/0mA).
BUG=none
BRANCH=tot,nyan
TEST=make runtests. Tested on big. Expect NO below annoying error message
[1.353104 charge_request(0mV, 0mA)]
[1.453170 charge_request(0mV, 0mA)]
[1.553281 charge_request(0mV, 0mA)]
[1.653317 charge_request(0mV, 0mA)]
in the follwing cases:
AC on, battery attached, power on, then remove/plug in AC.
AC on, battery attached, power on, then remove/plug in battery.
AC on, battery removed, power on, then plug in and remove battery.
AC off, battery attached, power on, then plug in and remove AC.
'chgstate' also shows good state. At final, charge for 10 mins.
Change-Id: Icc729c52246df1ecfb7f289b5078dbc122b20a74
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196678
Reviewed-by: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Reviewed-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are running a minimal runtime with less overhead. This allows us to
run UART at 38400 bps. Let's update the config for easier debugging.
Also fix a potential underflow bug.
BUG=None
TEST=See debug output at 38400 bps
BRANCH=None
Change-Id: Ic9e4f9d545f5dbc4a0816a843b0f01a4cf219666
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196190
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements a simple SPI driver for the two chips to exchange
packets.
There are both sync interface and async interface. Sync interface is
easier to use, and async interface frees the CPU while the DMA takes
care of the communication.
BUG=None
TEST=Hello test passed
BRANCH=None
Change-Id: I9823bad5cae6d1fa8f3658d17af4b998d3735a3e
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195533
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The two chips work together, so let's teach them how to tell master from
slave. After identification, the two chips shake hands through the two
sync signals.
BUG=None
TEST=Disable handshake on master. See slave fail. Vice versa.
BRANCH=None
Change-Id: Idb6a56128f608dd2ee5c453f75abea475fe1779f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195395
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add bq24735 driver and move to here for further developing
BRANCH=big
BUG=None
TEST=test basic charing/discharging function
Change-Id: I66c22a29cf94383cec86c5cf53db82494504fa77
Reviewed-on: https://chromium-review.googlesource.com/196541
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So that host and EC commands will be defined in common/battery.c.
The board-specific battery.c can focus on the proprietary method.
BUG=chrome-os-partner:28248
BRANCH=tot,nyan
TEST=make buildall runtest
Tested "cutoff" in EC console on big.
Change-Id: I213c0d601d0241c8dea309d6ac60c72452d2d100
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196621
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some chargers support a timeout mechanism that it would stop charging
if no voltage/current setting comes from battery or EC. This is designed
for safety.
In charger v1, it always updates charger periodically. But in v2, old code
only updates charger when needed. New code updates the charger periodically.
Also keep the ability for debugging. A manual mode is introduced so that
any requested volt/curr from host and force idle mode request would trigger
this mode. To leave this mode, just disable the force idle mode.
BUG=chrome-os-partner:28201,chrome-os-partner:28208
BRANCH=nyan
TEST=See below.
Plug AC and battery. Wait for 10 mins and the battery is charged normally.
'chgstate idle on': the charger doesn't charge the battery.
'chgstate idle off': charge again.
Plug in AC and remove battery: No annoying repeated message and works fine.
Plug in battery and remove AC: No annoying repeated message and works fine.
Power up machine with battery only: No annoying repeated message and works fine.
Power up machine with AC only: No annoying repeated message and works fine.
Change-Id: I00d62f8afa2fe2627ea9259f11679ced02af897a
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the basics for the accelerometer potion only of the ST
lsm6ds0 accel/gyro. Still need to add the acceleration interrupt
functionality, and all of the gyro portion of the chip.
BUG=none
BRANCH=none
TEST=Tested on a samus prototype hacked up to have the lsm6ds0 connected
to the EC i2c bus. Added motion sense task to the samus tasklist, added
accelerometer information to the samus board file, and tested console
functions interacting with accelerometer. The data seems reasonable,
and can successfully change data rate and range.
Change-Id: I7949d9c20642a40ede82dc291b2c80f01b0a7d8b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196426
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Charger v2 assumes the battery_get_info() always returns non-NULL even
if the battery is not detected, for example, in the over-drained
situation. Thus, add a new struct so that we know what the conservative
setting is to pre-charge the unknown battery.
BUG=chrome-os-partner:28112
BRANCH=nyan,big,blaze
TEST=See issue tracker for the test procedure.
Change-Id: Ica4fe75d154e2f195eb1da19ba045346da383b6c
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195596
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Devin Lu <Devin.Lu@quantatw.com>
Tested-by: Devin Lu <Devin.Lu@quantatw.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The EC and host have different ways of computing and presenting
the battery charge level. This change adjusts the charge levels
at which the charging LED indicates a full and low battery to
match what is presented to the user in the host UI.
BUG=chrome-os-partner:27743,chrome-os-partner:27746
BRANCH=rambi,tot
TEST=Run "battfake 91" which charging, verify charging LED turns
green and the UI reports 95%.
Run "battfake 13" while discharging, verify charging LED blinks
amber (1 sec on, 1 sec off) and the UI reports 10%.
Change-Id: Iaffffb57a7fbfd14ebb90363cbd4aa1a9becf022
Original-Change-Id: I203c90a65e4aa2907a14077a9276674ecfa292f2
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194347
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On the Nyan EC, we almost run out of the stack of console task.
Instead of making that struct static or global, we print the cached data.
Read the issue tracker for more detailed discussion.
BUG=chrome-os-partner:28027
BRANCH=tot
TEST=verified on nyan with/without battery.
The "battery" console command doesn't crash the system.
Change-Id: Id5246724760aed4cf1df827baf115007b2ffb48e
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194875
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This chip got small flash and RAM, so the common runtime is disabled.
Now the code only boots and print something every second to check debug
console and timer are good.
BUG=None
TEST=Boot and see console output
TEST=make buildall
BRANCH=None
Change-Id: I01150e8250a404628d1a3b81e677ac4c29782d7f
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195382
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
just picks up this commmand for factory.
BRANCH=ToT
BUG=None
TEST=Run ectool chargecontrol command with each option (normal,
idle, discharge) on blaze. Verifiy battery can discharge.
Change-Id: Id57b42796a26aaf85258048260d06923b78f0773
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This would move all tegra boards to charger v2.
Also removed the unnecessary charge_keep_power_off(), which was
designed for USB power port and doesn't apply to Tegra platform.
BUG=none
BRANCH=nyan,big,blaze
TEST=build and run on nyan.
Change-Id: I9517a8885726ad6dce5a2865402da4b9551e009f
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194384
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Devin Lu <Devin.Lu@quantatw.com>
Tested-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added storing of FPU regs on context switches when CONFIG_FPU is defined.
On context switches, EXC_RETURN[4] is checked in order to tell which tasks
have used floating point and which have not. The FPU regs are only stored on
task stacks for tasks that use the floating point. Tasks that use floating
point will therefore require roughly an additional 128 bytes of stack space,
and context switches will take about 32 clock cycles longer for each task
involved in the switch that uses FP.
For tasks that don't use floating point, the stack usage actually decreases
by 64 bytes because previously we were reserving stack space for FPU regs
S0-S15 on every context switch for every task, even though we weren't doing
anything with them.
If a task only uses the FPU for a brief window, it can call
task_clear_fp_used() in order to clear the FP used bit so that context
switches using that task will not backup FP regs anymore.
BUG=chrome-os-partner:27971
BRANCH=none
TEST=Tested on glimmer and peppy. Added the following code, which uses the
FPU in both the hooks task and the console task. Note, I tested this for
a handful of registers, notably registers in the group s0-s15 which are
backed up by lazy stacking, and registers in the group s16-s31 which are
backed up manually.
float dummy = 2.0f;
static void hook_fpu(void)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.3f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Hook float 0x%08x\n", tmp.i);
/* write FP reg. */
tmp.i = 0x1234;
asm volatile("vmov s29, %0" : : "r"(tmp.f));
}
DECLARE_HOOK(HOOK_SECOND, hook_fpu, HOOK_PRIO_DEFAULT);
static int command_fpu_test(int argc, char **argv)
{
union {
float f;
int i;
} tmp;
/* do a dummy FP calculation to set CONTROL.FPCA high. */
dummy = 2.7f*7.8f;
/* read and print FP reg. */
asm volatile("vmov %0, s29" : "=r"(tmp.f));
ccprintf("Console float 0x%08x\n", tmp.i);
if (argc == 2) {
char *e;
tmp.i = strtoi(argv[1], &e, 0);
if (*e)
return EC_ERROR_PARAM1;
/* write FP reg. */
asm volatile("vmov s29, %0" : : "r"(tmp.f));
} else {
task_clear_fp_used();
}
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(fputest, command_fpu_test, "", "", NULL);
When you call fputest 5 from EC console before this CL, then on the next
HOOK_SECOND, the value of register s29 is 5, instead of 0x1234 because
register s29 is not saved on context switches:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00000005
When this CL is in use, the register holds the correct value for each task:
Hook float 0x00001234
> fputest 5
Console float 0x00001234
Hook float 0x00001234
> fputest
Console float 0x00000005
Hook float 0x00001234
Change-Id: Ifb1b5cbf1c6fc9193f165f8d69c96443b35bf981
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194949
Reviewed-by: Vincent Palatin <vpalatin@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add LED behavior for blaze that will the same as falco and kip.
BUG=None
BRANCH=ToT
TEST=manual
Check battery LED show Amber when battery in charging.
Check battery LED show white when battery fully.
Check battery LED show blinking every 500ms when charging error.
Check PWR LED light when system power on.
Check PWR LED off when system power down.
Check PWR LED will blinking every 1sec when system into suspend.
Change-Id: I830952361d3282ff78d29a9a33bd09b64b093ee1
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/193744
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set battery cut off command and config battery configuration for blaze.
BUG=chrome-os-partner:27120
BRANCH=ToT
TEST=manual
build ec and flash to blaze board,
verify battery works.
Verify battery cut off function is workable.
Change-Id: I2e1f7de9c6370a2a02fb56fc4520f4bc062b4d6b
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193000
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Modify voltage_max
2. Set CP point
BUG=chrome-os-partner:27859
BRANCH=Big
TEST=Plug in AC and battery, use UART command "charger" to check
v_batt and I_in and the values are correct.
Change-Id: If83a444338e8d520e6c2f4d04ca6016c14cea8bd
Reviewed-on: https://chromium-review.googlesource.com/193584
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:27736
BRANCH=ToT
TEST=Verify battery charges and 'battery' console command returns
sane values.
Original-Change-Id: I57d9d432bce4ed28678dddc43fa5166905525557
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193338
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Conflicts:
driver/battery/smart.c
Change-Id: Idae79859961da888e652b3af306ba49c467b412e
Reviewed-on: https://chromium-review.googlesource.com/193655
Tested-by: Dave Parker <dparker@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add the USB Power delivery PHY configuration,
and all the pins and details to use the real Zinger
board.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=none
Change-Id: Ic2d3616c9fd2bf3ebeccba74a5519697e7c3e899
Reviewed-on: https://chromium-review.googlesource.com/194220
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add all the pins configuration to use the real FruitPie board
and the USB Power Delivery configuration.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make BOARD=fruitpie
Change-Id: I8c20118400cb6a2e26b541a9ee2da5b706299fcf
Reviewed-on: https://chromium-review.googlesource.com/189862
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implementation of the physical layer for USB Power Delivery
communication using the STM32 chip.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=none
Change-Id: I2a4adeef572b97a284bf52ab9d14d23246c56d18
Reviewed-on: https://chromium-review.googlesource.com/189867
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The protocol layer implementation for USB Power Delivery messaging.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=none
Change-Id: I7db75b004cf9dbf13fa1df95336f206e93236fc9
Reviewed-on: https://chromium-review.googlesource.com/189866
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactored keyboard scan enable/disable flag such that it is a mask of
potential disable sources. When all disable sources are off, scanning is
enabled, otherwise scanning is disabled. This fixes a recently introduced
bug in which enabling/disabling keyboard scanning due to lid angle in S3
was interfering with enabling/disabling keyboard scanning due to power
button. This also allows for easy expansion for future causes for disabling
keyboard scanning.
BUG=chrome-os-partner:27851
BRANCH=rambi
TEST=Manual tests with a glimmer. Used the ksstate console command to
check state of keyboard scanning under all permutations of power button
pressed/unpressed, lid switch open/closed, and lid angle in tablet position
vs. laptop positon.
Change-Id: Ied4c5ebb94510b1078cd81d71373c0f1bd0d6678
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194287
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add other helpers for compact switch on ARMv6-M.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=none
Change-Id: I711ee8361ff1545acd978974d9f9fc306ca43b78
Reviewed-on: https://chromium-review.googlesource.com/190711
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the battery pack is missing, don't constantly spew console messages
about it. Just note it once, and move on. But if we're precharging to try to
awaken a dead battery, say so and also say so when we either give up or the
battery awakens.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
I unplugged and replugged the battery while watching the EC console. It
stops the whining.
Also tested without CONFIG_BATTERY_PRESENT_CUSTOM defined. It precharges,
gives up, continues, etc.
Change-Id: I5d4224cd1a6bf90ed6a1cf404260cdf6c61fc125
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves some of the smart battery mocks, and adds some more tests for
the new change state machine.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make coverage
Line coverage of this file jumps from 53% to 93%.
Change-Id: I4a9b8818cefaffd3022cebe08a36d592b0611295
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193690
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had duplicate values in both v1 and v2 headers. Let's consolidate them in
one place, and prefix the constants with "CHARGE_", so people don't use them
randomly.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
No functionality changes, refactor/rename only.
Change-Id: I0ee599a2e3bf0835c2c0a7e57872ad9015701a4b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we use 'kill -9' to kill other users of the serial port then we
end up with stale lockfile warnings. Try to use a normal kill first
to be a little nicer.
BRANCH=ToT
BUG=None
TEST=flash_ec and no longer get stale lockfile messages from cu.
Change-Id: Idb39ca803a9c54b6fe972f6854515ea5a8bdab03
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194190
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a sub-command to the motionsense host command (0x2b) for getting/setting
the lid angle at which the keyboard is disabled as a wake source in S3. The
value can be anywhere from 0 to 360 degrees, default set to 180. Note, this
only takes affect for boards that have CONFIG_LID_ANGLE_KEY_SCAN defined.
Modified ectool motionsense command to use new host sub-command.
Also modified the lid angle measurement in the EC to be in the range [0, 360],
instead of [-180, 180], and changed casting of lid angle as an int to round
to nearest.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
Using default keyboard disable lid angle of 180, made sure that when lid
angle is past 180, key presses do not wake system, and when lid angle is
less than 180, key presses do wake up system.
Used ectool motionsense kb_wake to set the keyboard disable lid angle to 0.
Made sure that keyboard never wakes up the system. Set keyboard disable lid
angle to 360 and made sure that the keyboard always wakes up the system.
Change-Id: I437164c6e38c29169ef6e20e86c9cf2a1c78f86e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193663
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194172
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added arg to ectool motionsense command to print the active flag.
BUG=none
BRANCH=rambi
TEST=Tested ectool command on glimmer
Change-Id: I4066302d388857b2646a4ee778aa7f671e9b7d2a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193630
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
(cherry picked from commit 6c09268ca19d7d3db497beff65a5db79f33657cb)
Reviewed-on: https://chromium-review.googlesource.com/194082
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I used '&&' instead of '&' for bitfield operations. Hooray for test coverage!
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
Change-Id: I7e6343df4aead456d4984bf77667aa5cf852aa15
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193735
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The host should be responsible for setting any required
charge throttling at resume. EC the should not restore
the previous charge current limit as the the charging and
thermal state of the device are likely to be different
when the device resumes.
BUG=chrome-os-partner:27369
BRANCH=ToT
TEST=Suspend the device with the adapter unplugged.
Plug in the adapter and resume. Verify that the charging
LED doesn't flash two or three times at resume. (tested
on squawks)
Change-Id: I1fbba0652419501193e713e130830a005c6b5a22
Origianl-Change-Id: I1e4615d99ee9a386b25e58b991e846c5d2beaa39
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192686
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193341
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added enum for motion sensor ID's into ec_commands.h so that the host
can easily send host commands targeting the desired accelerometer.
Changed sensor present flag to just senosr flags, currently with only a
single mask defined for sensor present. This allows for easier future
expansion of various flags.
Also, added a motion sense module flags to the dump sub-command for flags
that represent all sensors, such as is the motion sense task active.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Manual test on a glimmer by testing ectool motionsense command
Change-Id: Iac052269a60db9ff4506f0490c3a0c6daad5b626
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193122
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changed the ec_rate sub-command of the motion sense command. Now it
permits any value for the rate as an argument and then bounds that
to within the min and max. This matches the behavior of the other
sub-commands such that for any argument the command will return
success, but if the arg is not valid, it finds the closest valid value.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer by using the ectool motionsense command. Made
sure if you give it a value outside of the range [5, 1000], then it
simply bounds it to the closest value in that range:
> ectool motionsense ec_rate 0
5
> ectool motionsense ec_rate 100
100
> ectool motionsense ec_rate 1100
1000
Change-Id: If71299e3ab27bcfac87103c672793ac61f88100e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192525
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193308
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created a host command to set/get various motion sensor parameters and
added an ectool command to use that host command.
The host command is created such that the first argument is a
sub-command. Sub-commands created include:
dump: dumps all current motion sensor data
info: returns general information about each motion sensor
ec_rate: set/get the EC sampling rate of sensors
sensor_range: set/get the sensor range (ie +/- 2G,4G,8G)
sensor_odr: set/get the sensor output data rate (ie 50Hz, 100Hz, ...)
For sensor_range and sensor_odr parameters, since the host doesn't know
what are valid values for the parameter, the host can specify to round
up or down to the nearest valid value. For example, the host can specify
to set the output data rate to at least 100Hz, and the EC will return
the closest valid output data rate that is at least 100Hz.
BUG=chrome-os-partner:27321
BRANCH=rambi
TEST=Test on a glimmer using ectool from vt-2 prompt:
> ectool motionsense help
Usage:
motionsense - dump all motion data
motionsense info NUM - print sensor info
motionsense ec_rate [RATE_MS] - set/get sample rate
motionsense odr NUM [ODR [ROUNDUP]] - set/get sensor ODR
motionsense range NUM [RANGE [ROUNDUP]]- set/get sensor range
>
> ectool motionsense
Sensor 0: 0, 0, 1024
Sensor 1: 1024, 0, 0
Sensor 2: None
> ectool motionsense info 0
Type: accel
Location: base
Chip: kxcj9
> ectool motionsense ec_rate
10
> ectool motionsense ec_rate 1000
1000
> ectool motionsense odr 0
100000
> ectool motionsense odr 0 40000 1
50000
> ectool motionsense range 0 8
8
After running this I verified on the EC console that all the parameters
were set appropriately. I tested the EC sampling rate was 1000ms by
running lidangle on and making sure samples were displayed roughly every
second. I verified the sensor odr and range by defining
CONFIG_CMD_ACCELS and typing:
> accelrange 0
8
> accelrate 0
50000
Change-Id: I444e2f0eafabd607f1c7aa78b5c4e91f6cb06387
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192064
Reviewed-on: https://chromium-review.googlesource.com/193307
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This replaces the obsolete and temporary (ha!) EC_CMD_CHARGE_DUMP host
command with EC_CMD_CHARGE_STATE. This is used to monitor and adjust the new
charge state implementation, including any board-specific customizations.
This command is a single catch-all command with multiple subcommands
(similar to EC_CMD_LIGHTBAR_CMD) so that we don't have to keep adding new
top-level host commands just to support incremental changes.
BUG=chrome-os-partner:23776
BRANCH=ToT
TEST=manual
From the AP, try these commands:
ectool chargestate show
ectool chargestate param
ectool chargestate param <NUM>
ectool chargestate param <NUM> <VALUE>
Watch the EC console and use its "chg" command to verify the effects of
setting various params.
Note: the Samus-specific fast-charging profile override is param 0x10000.
You can check it with the EC console "fastcharge" command.
Change-Id: Iad2f773a085bc25c05073b3eed9866f122ae9d78
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193305
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the battery happily reports that it's current temperature is
6280C, which is just a little bit high. This just treats unreasonably high
temperatures as an error.
BUG=chrome-os-partner:27527
BRANCH=ToT
TEST=manual
Make the change, watch the EC console while the AP is running and the
battery charges and discharges. The problem is intermittent, but when it
occurs it shuts the AP down immediately. With this change, it just prints a
warning instead.
I've also added a check for this to test/sbs_charging_v2.c
Change-Id: Ibfa53cf0244499ec52d4887bcd06fb9126c07a6c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193277
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the host somehow fails to see an edge on the keyboard IRQ line, it
won't read the 8042 data register. The EC won't ever send another
IRQ, because it only does so after filling the register. So the
keyboard will hang.
Work around this with a retry mechanism. If the AP hasn't responded
after 3 additional keyboard events, generate another IRQ. So a stuck
key will get unstuck if you tap it a few times. That's reasonable,
and matches what people do already if they have a sticky key due to
crud accumulating in the keyboard.
I've tested this when the system is booted to the OS. I don't see any
additional IRQs generated on the EC console ("KB extra IRQ"), so the
host is keeping up with the keyboard input stream.
If I'm in dev or recovery mode and bang on the keyboard right after
powering the system on (when the BIOS isn't yet paying attention to
the keyboard), I can see extra IRQs generated. This shows the retry
mechanism is working. The extra IRQs have no negative effect on the
boot process, and the keyboard works normally when the OS does
eventually boot.
BUG=chrome-os-partner:27222
BRANCH=rambi
TEST=Bang on the keyboard like a monkey. Keyboard should still work.
Change-Id: Idd41b2d133267f48f959bca0cf062a18ca6551fb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193272
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Samus' power sequence is not in common/power, so it was overlooked when
enabling deep sleep support. Fix it.
BUG=chrome-os-partner:27705
BRANCH=ToT
TEST=manual
Verify that the EC is not going into deep sleep while the AP is on by
looking at the EC console:
With the AP on:
> idlestat
Num idle calls that sleep: 1518647
Num idle calls that deep-sleep: 414
Time spent in deep-sleep: 0.000000s
Total time on: 316.642174s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020001
>
With the AP off (or in S3):
> idlestat
Num idle calls that sleep: 1846586
Num idle calls that deep-sleep: 831
Time spent in deep-sleep: 11.089183s
Total time on: 388.695558s
Deep-sleep closest to wake deadline: 698us
> sleepmask
sleep mask: 00020000
>
Change-Id: Iba708b6d53f96ef6d49d42bcf6d21db4732399b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193223
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|