Tidy code. No functional changes.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=discharge battery, then plug AC in and make sure it charges
Change-Id: I4cff018940ecb665be96655d6722f74dd6674f6d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36359
We only have one scan mask and no capability to change scan masks, so
don't reserve space for masks we're not using.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=type on keyboard; should still work
Change-Id: I8ad0c5c894f93c2a79ca646e7666b3279c90a63c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36347
Remove unused code paths. Simplify interfaces. Clarify comments.
Split the protocol constants into their own header file (since they're
used only by keyboard.c, not i8042.c, which is really keyboard
buffering... and will be renamed so in a followup CL.)
This cleanup reduces binary size by about 200 bytes.
BUG=chrome-os-partner:15579
BRANCH=none
TEST=type on the keyboard; it should still work.
Change-Id: I6acbab5fe5604b4b0c516ba3622e6f41820985d1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36271
Previously, all hook functions returned EC_SUCCESS, which was
meaningless because nothing ever looked at the return value. Changing
the return value to void saves ~100 bytes of code size and an equal
amount of source code size.
BUG=none
BRANCH=none
TEST=code still builds; link still boots
Change-Id: I2a636339894e5a804831244967a9c9d134df7d13
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/36372
This makes the timing for the S3 low-power indicator adjustable without
reflashing.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Boot, log in, run this to put the lightbar into demo mode:
ectool lightbar demo 1
ectool lightbar seq s3s0
The lightbar should act as though the system is asleep.
Then press the left arrow a couple of times and the down-arrow four or five
times. You should see the red light pulse every 5 seconds or so.
Now run
ectool lightbar params > /tmp/w
Edit /tmp/w to change the timing lines to this:
100 # .s3_ramp_up
100 # .s3_ramp_down
Then run
ectool lightbar params /tmp/w
After a cycle or two, you should see the lightbar flash instead of pulse.
Change-Id: If815ff2fb9a158c0e1f4dbb6a269ad07e122d84c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35839
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add EC commands for managing a list of keyscan events which the EC
should replay instead of its normal key scanning operation.
There are two commands: one adds to the list of events. The other
allows the list to be cleared, the sequence to be started, and the
resulting information to be collected.
BUG=chrome-os-partner:12179
BRANCH=none
TEST=manual for now:
On snow:
./ectool keyscan 10000 key_sequence.txt
See that the test passes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Change-Id: Ie4c3e4d0f5c1dbf642185fec99b9201d47532ae1
Reviewed-on: https://gerrit.chromium.org/gerrit/35117
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
I introduced a glitch in the parameterization CL. This fixes it, and makes
the choice between the gentle throbbing and occasional pulse something that
can be selected as a parameter. Default is the new pulsey style.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
Using the ectool that's part of this change, run these commands to flip
between suspend and active displays:
ectool lightbar seq s3s0
ectool lightbar seq s0s3
Change the "new_s0" value (0/1) and reload the params with
ectool lightbar params | tee /tmp/w
vi /tmp/w
ectool lightbar params /tmp/w
In each case you'll see some pretty patterns. Pass/Fail is an artistic
decision. No QA required.
Change-Id: I8de0b1b3cc77f65879befe95e110bbbce18846d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, any command which set the fan duty manually would leave
the PWM RPM controller disabled. Setting the fan back to auto mode
via 'ectool autofanctrl' or 'autofan' or 'ectool pwmsetfanrpm'
wouldn't turn the controller back on. Now it does.
BUG=chrome-os-partner:14307
BRANCH=link
TEST=manual
- Reboot in recovery mode and wait for INSERT screen
- From EC console
fanduty 100 -> fan turns on all the way
faninfo -> mode is duty
fanset 6000 -> fan turns down to a lower level
faninfo -> mode is rpm
fanduty 0 -> fan turns off all the way
faninfo -> mode is duty
(wait a min or so for the system to heat up)
autofan -> fan turns on
faninfo -> mode is rpm
- Reboot normally
- From root shell
ectool fanduty 100 -> fan turns on all the way
ectool pwmsetfanrpm 6000 -> fan turns down to a lower level
Change-Id: I3b07e8b49500f5f8a42f20909d2869cf63987d6d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35335
Reviewed-by: Sameer Nanda <snanda@chromium.org>
The spring board doesn't have one and we doesn't want to mess up with
that pin.
When the POWERLED task is not present, let's de-activate cleanly that
code.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14324
TEST=make BOARD=spring (no power_led.o compiled)
make BOARD=snow (power_led.o compiled)
make BOARD=link && make BOARD=bds
run on Snow and see the power LED working
Change-Id: Ib44f5df54ec4fdee1863814e6c7052fd6620fee8
Reviewed-on: https://gerrit.chromium.org/gerrit/35272
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This change replaces most of the hard-coded lightbar constants with values
that can be updated at run-time, so that if we change our minds about colors
and timing we can tweak some of the values without requiring an EC/BIOS
update.
It also adds the "ectool lightbar params" command to get and set those
values from the host. You can see the values from the EC console ("lightbar
params"), but there's no way to set them.
BUG=chrome-os-partner:8039
BRANCH=Link
TEST=manual
From the EC console, run
lightbar params
It should display the current values that can be changed.
Log in to the host and run this to see the same values:
ectool lightbar params
Or edit and change them with this:
ectool lightbar params > /tmp/vals.txt
vi /tmp/vals.txt
ectool lightbar params /tmp/vals.txt
The updated parameters are persistent across EC jumps (RO->RW), but are lost
when/if the EC reboots (as it will after the AP is off for 24 hours, for
example).
Change-Id: Ic2a3fd6f8062673432b48904933e0c7239b8658b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35289
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Previously, if the AP took fan control, the EC would never take it
back. This meant the EC would leave the fan off even if the system
was sitting at the INSERT screen or booted an alternate OS.
BUG=chrome-os-partner:15189
BRANCH=link
TEST=manual
- boot system
- from EC console, fanset 0
- faninfo shows fan at 0rpm
- from root shell, crossystem recovery_request=123 && reboot
- wait a few mins
- faninfo should show fan spinning again
Change-Id: I534c9978194085467f1df6eae971c55d4e8083be
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35309
S0 values are incorrect and may even need to be calibrated on a
per-system basis. Set them to 0 by default so that the EC doesn't
return inaccurate remote temperature readings before calibration data
is sent.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- temps -> remote temps are all not calibrated
- t6cal 1 s0 9301
- temps -> PCH D-Object temp now returns a temperature
Change-Id: I43facc60cf947ebd9441a8a629a76f7ffc8f3959
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35302
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual, from root shell
- ectool temps all -> prints all temps
- ectool tmp006cal 1 0 0 0 0
- ectool temps all -> sensor 3 not calibrated
Change-Id: I16ee818c948fe90ac7c18b230c5d9f9a0ec83ded
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35288
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This removes the need for a separate method to check sensor power, and
gets rid of temp_sensor.c knowledge of what powers each sensor.
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
- reboot
- within a second, type 'temps'; I2C sensors should return error 1
- type 'temps' again; all sensors should return data
- power off system
- type 'temps' again; I2C sensors and PECI should return error 8
- 'gpioset enable_vs 1'
- type 'temps' again; I2C sensors should return valid data; PECI should still
return error 8.
Change-Id: I17c353b3c483bc320769307c7715008ec729089b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35287
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This will be used in a follow-up CL to return specific error codes
(not powered, not calibrated, etc.)
BUG=chrome-os-partner:15174
BRANCH=link
TEST=manual
Power on system.
'temps' should return all good temps.
Power off system (into S5)
Only ECInternal temp should work; others should return Error 1
'gpioset enable_vs 1' and wait a second
Now all the I2C temps should display good data, but PECI will still be error 1.
Change-Id: I925434e71653ad53ad76bad992a7a8fdeadb088c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35286
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
1) Use floating-point more freely, since it's on all the time now, and
the old fixed-point code no longer compiled.
2) Sensitivity and Bn values are now in a RAM-based struct in
preparation for setting them at runtime. No changes from current
values.
3) If a sensor fails to read good data, is initialized, or loses
power, its die temperature history will be set to the next good
temperature, rather than persisting an arbitrary start value or old
state. This fixes reading wildly inaccurate object temperatures for
the first few seconds following boot/resume.
4) If a sensor loses power, wait for the sensor to report data-ready
before reading temperature/voltage. Otherwise, those read as 0, which
again throws off the first few seconds of data.
BUG=chrome-os-partner:14955
BRANCH=link
TEST=Boot system and set at login screen for a minute to reach thermal
equilibrium. Then reboot system, type 'temps' repeatedly. Data from
TMP006's should initially be Error; after a second or so it should be
good, and shouldn't change more than a few degrees.
Change-Id: Id0b42b9b18e94978ba7d3a1ee33194e44b1904bc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/35188
Experiments showed that some UVP batteries took ~30 seconds to restart
its gas gauge IC. This change adds 30 seconds polling check to determine
the condition.
Signed-off-by: Rong Chang <rongchang@chromium.org>
BRANCH=link
BUG=chrome-os-partner:13923
BUG=chrome-os-partner:14094
TEST=manual
Disconnect battery and plug in charger. The charging LED should turn
red after 30 seconds.
Change-Id: I425e63c428aeeaf1468bc2f9886457de1145cada
Reviewed-on: https://gerrit.chromium.org/gerrit/34886
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
We already shut down the main processor below 3%. Hibernating the EC
below 2% will further cut power draw and minimize the risk of
deep-discharging the battery.
BUG=chrome-os-partner:14839
BRANCH=link
TEST=manual
1) discharge battery below 3%; system should shut down. when powered
on again it should shut back down within ~10 sec.
2) discharge battery below 2%; when system shuts down it should also hibernate.
(I've also tested this with a hacked smart_battery.c which lies about
the battery state of charge, since that's faster than waiting for my
battery to discharge.)
Change-Id: I504ba927012430db5cf10b895a36e6cd6fdf4c8b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34793
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
At present the keyboard scan parameters are hard-coded, so changing them
requires a new EC image. This can be problematic if we want to adjust
the behavior of keyboard scanning since we must send an EC update.
Define the keyboard scan parameters and commands to get/set these
parameters.
Signed-off-by: Simon Glass <sjg@chromium.org>
BUG=chrome-os-partner:12179
BRANCH=snow,link
TEST=manual
Build for all boards
Change-Id: I715755cb5357503723b27ae33053dba1452e48e0
Reviewed-on: https://gerrit.chromium.org/gerrit/34656
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
This enables the OS to request the EC drop into its lowest-power
shutdown state. Targeted at end of factory flow, where the
at-shutdown variant is the desired variant because it allows the main
processor to shut down cleanly first.
BUG=chrome-os-partner:14838
BRANCH=link
TEST=from root shell,
ectool reboot_ec hibernate at-shutdown
shutdown -h now
System should shut down, and EC console should be unresponsive (since
it's hibernating). Press power button, and system should power back on.
ectool reboot_ec hibernate
System should shut down immediately. Press power button, and system
should power back on.
Change-Id: I8084a3a1bca6b7c201e090552b193fe1568708a2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34569
Reviewed-by: Vic Yang <victoryang@chromium.org>
Tell the host the battery is no longer charging when it hits 97%, and
set the power adapter LED to green.
This solves several problems:
1) The last 3% of charge takes a looong time. Kernel/ACPI/UI already
have a hack to show the battery as charged when it's about 3% from
full, but the EC still showed a yellow LED.
2) If the system is charged and you briefly unplug the adapter, the
LED turned yellow for a long time as it slowly trickle-charged. Now
it goes right to green.
3) A fully-charged battery will drop below 100% charge as it settles,
but won't accept more current at that time. This caused the LED to
turn yellow and stay there until the battery finally settled down to
~96%, at which point it'd accept more current and top itself off. The
whole time it did this, the kernel/ACPI/UI hack from (1) would keep
reporting "battery full". Now the LED stays green too.
BUG=chrome-os-partner:11248
BRANCH=link
TEST=manual
- Discharge system to <95% full.
- Plug adapter in. LED should come on yellow.
- At around 97% full, the LED should turn green.
- Around that the UI will display "battery full".
(Note that due to rounding, the UI may take a few minutes to display
"battery full" after the LED goes green; that's ok)
- Unplug and replug adapter. LED should come on green. UI still reports
"battery full".
Change-Id: Ie56fbf3a05239e73d2c765bb98d36aa5cfedc2ef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34452
With this CL, if CONFIG_FPU is defined (only for Link, ATM), the EC task
switcher will enable CONTROL.FPCA and expect all stack contexts to include
floating point state as well as normal state (an additional 18 words).
To support this, we need to increase the allocated stack space for each
task. The stack sizes are already chosen empirically, so I'm just rounding
them up a bit.
BUG=chrome-os-partner:14766
BRANCH=Link
TEST=manual
There should be no noticeable change. If you run the EC command "taskinfo"
you'll see the increased size each thread's stack, but everything that was
working before should continue to work just fine.
The additional overhead required to load and store another 18 words on each
context switch is not really measurable (I tried).
Change-Id: Ibaca7d7a2565285f049fda6906f32761e83207af
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34391
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Currently, the charge state machine sets the power LED green the first
time it hits IDLE. This causes the LED to briefly flash green when
the adapter is inserted, because the state machine goes
discharging->init->idle->charging.
Instead, add a new idle0 state in between init and idle which does not
set the power LED. This allows the state machine to go
discharging->init->idle0->charging, so the LED only goes from off->yellow.
If the system is actually fully charged, it'll go init->idle0->idle
and show green.
BUG=chrome-os-partner:14630
BRANCH=link
TEST=manual
- Remove adapter and allow system to discharge a bit
- Insert adapter
- Should see LED go from off directly to yellow
- Wait for charge
- Should see LED go green
Change-Id: I9b77f01fad27c8574133211c9fe250486609f3c1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34387
Reviewed-by: Rong Chang <rongchang@chromium.org>
1) Only send the host response immediately for commands which won't
return. This prevents double-sending a response for the disable-jump
command.
2) Remove references to the POWER_ON flag. This was never implemented
or used, since with EC software sync the EC always powers on after
rebooting.
3) Fix help text for reboot_ec command. (Both "A" and "RW" still do the
same thing, but "RW" is now the preferred option string.)
BUG=chrome-os-partner:12635
BRANCH=link (also applies to snow, but don't pick unless needed)
TEST=from a root shell,
flashrom -p internal:bus=lpc -r /tmp/ec.bin
flashrom -p internal:bus=lpc -w /tmp/ec.bin
ectool reboot_ec RW
ectool reboot_ec RO
ectool disable-jump
All commands should succeed.
Change-Id: Ibf5b4fb88d93e64fc7361a9f962ec7aa1df0cf3c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/34051
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
This adds basic ADC support for multiple channel conversion.
BUG=chrome-os-partner:14316
BRANCH=none
TEST=1. Boot on snow.
2. Use keyboard signal as input. Check read value changes as input
signal changes.
Change-Id: I3c15c37446fa9273d098f6d581573c11ced45b5e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33883
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This reduces power consumption in S3/S5 because the EC doesn't need to
poll the battery every 500ms.
BUG=chrome-os-partner:9676
BRANCH=link
TEST=manual
As much as can be tested with the current debug information:
- Boot system with AC adapter in. Charge state machine should go to
charging state.
- Remove AC adapter. Charge state -> discharging.
- Shut system down.
- Plug AC adapter in. Charge state -> init -> charging over the course of
a few seconds (NOT a minute).
- Remove AC adapter. Charge state -> discharging.
Really good testing requires a source-level change. Hack in a line of
debug output above task_wait_event(sleep_next) in
charge_state_machine_task() which prints how long the charge state
machine is sleeping. It should sleep for ~250ms when charging, ~500ms
when discharging and the system is on, or ~60000ms when discharging
and the system is off. (I did this when writing this change, but
removed it because it clutters up the debug console output.)
Change-Id: I7d3e291fbc40bfcc67d1fb4982d91f0e6bf2e785
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33921
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
This reduces oscillations in the charging algorithm. This change also adds
more debug output so it's easier to see what the charging state machine is
doing.
BUG=chrome-os-partner:9572
BRANCH=link
TEST=discharge battery; charge battery; note infrequent but useful debug output
Change-Id: I4c8609c2ca8a6cab3eae151ecf2bb1520103fece
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33811
Reviewed-by: Rong Chang <rongchang@chromium.org>
Yet another set of tweaks to the lightbar patterns:
At Startup or wake from sleep, Google colors cycle in.
While running, > 25% power level in the battery:
All blue, in a breathing effect (cycle up and down 30%).
While running, <= 25% power level in battery:
Same as above, but with red
Shutting down, or going into sleep:
Cycle out the Google colors (Note: the effect is only visible for S0->S3,
because shutting down kills power to the lightbar before we can react).
While sleeping:
Similar to now, but only using Blue and red for battery indication as above.
The EC doesn't have access to the ALS, so we use the keyboard backlight to
control the lightbar brightness instead:
If keyboard backlight is OFF (which it is when ambient is bright), use max
brightness for lightbar.
If keyboard backlight is ON, use keyboard backlight brightness.
BUG=chrome-os-partner:13870
BRANCH=Link
TEST=none
This is an aesthetic change. Nothing to test, only artisitic criticism.
Change-Id: Ib0b98eef18984945a83e988588c225025c4e8e52
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33824
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This manifested as the lightbar task missing transitions between CPU states.
The underlying cause was that when a task talks over the I2C bus, the I2C
communication was using the task scheduler to wait for an interrupt to
signal completed I2C traffic without blocking the other threads, but while
doing so it was not preserving pending events. This CL seems to fix it.
BUG=chrome-os-partner:12431
BRANCH=all
TEST=manual
The original bug is tricky to reproduce without adding some delay to the I2C
task code, but you can do it. Boot the CPU, then from the EC console
repeatedly alternate these two commands:
lightbar seq s0
lightbar seq s3
You should see the lightbar pattern turn off and on, but occasionally you'll
type the command and the EC won't change the pattern.
With this change applied, it should *always* work.
Change-Id: Ie6819a4a36162a8760455c71c41ab8a468656af1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33805
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We recently changed the way host messages are passed to the EC to make it
work nicer across I2C. When we did, we updated all the internal structs
except those used for lightbar commands. This CL updates the lightbar
commands too.
BUG=chrome-os-partner:11277
BRANCH=all
TEST=manual
This shouldn't change anything, but you can ensure that by poking at the
lightbar manually. On Link, run this from a root shell:
ectool lightbar seq stop
ectool lightbar 4 ff 00 ff
ectool lightbar seq run
With the first command, the lightbar pattern should freeze.
With the second command, it should turn magenta.
With the third command, it should resume pulsing as before.
Change-Id: Ic5dc4c827b3b4459288d7d9bd7d06af8a5176b3c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33798
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Some designs will have the PMU not directly connected to the AP but
behind the EC.
For easier bring-up, it's nice to be able to force power rails.
Signed-off-by: Rong Chang <rongchang@chromium.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:10912 chrome-os-partner:14324
TEST=manual
On snow, switch on and off the backlight using the API
BRANCH=none
Change-Id: I74e05308043546cb11f7f2cdbe644944c0a0a35e
Reviewed-on: https://gerrit.chromium.org/gerrit/26234
Reviewed-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
At other times, the battery should follow the normal charging rules.
Using the trickle charging logic has 2 problems here:
1) Battery voltage is near maximum, so trickle charging logic starts
out with voltage less than the actual battery voltage, and less than
the charging spec.
2) Trickle charging only exits when battery requests more current
(which it won't if it's near full) or on 4-hour timeout, not when
battery reads 100%. So this can cause overcharging.
Note that we still limit the charging current to what the battery asks
for, but if that's less than the minimum current from the charger we
simply provide the minimum and don't fiddle with the voltage since
that may interfere with the battery's ability to determine it's fully
charged.
BUG=chrome-os-partner:14402
BRANCH=link
TEST=manual
1. charge laptop to full
2. quickly unplug and plug charger
3. look at debug log; should either not charge at all (if charge is currently
100%) or charge at 8400mV (if charge is less than 100%).
Change-Id: Ifd5a9eb2e9bb791f74196713b645d1c9211eb736
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/33729
Reviewed-by: Rong Chang <rongchang@chromium.org>
the PMU VACG signal used to detect AC state is connected to a GPIO, so
it's a board specific configuration.
On top of that, Daisy variants have custom logic on that line which is
not present on the next boards, so we need to update it before doing BSP
for next-gen boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:14313
TEST=make BOARD=snow && make BOARD=daisy
on snow EC console, type "pmu" command with AC plugge and unplugged, see
that the "ac gpio" line reflects the right value.
BRANCH=none
Change-Id: If1e19b89b2f2de45d8dddc8340931e56c5f7f0a5
Reviewed-on: https://gerrit.chromium.org/gerrit/33630
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The old spi driver has atrophied in various ways. It doesn't support
the new protocol and does not build either.
Rewrite the driver to:
- Use dma for reception (rather than just reception)
- This makes message reception more robust and allows us to process
the new multi-byte commands
- Add timeouts for rx and tx so that we don't wait forever
- Increase buffer sizes to deal with new larger messages
- Always send a preamble byte regardless of SPI clock speed
(previously above 10MHz we sometimes miss this)
- Use the NSS line to delineate transactions. When it drops, a
transaction is starting. When it rises the transaction is immediately
terminates regardless of state. This keeps the AP and EC in sync even
in the event of timeouts, bus errors and other oddities.
- Implement the new protocol which has a checksum, version byte, etc
- Set up tx dma in advance and kick it when ready, thus ensuring that
a message body is always attached immediately after the preamble
- Use the new host_cmd_handle_args structure, which makes things much
easier for us, since we don't need globals, and can use the
send_response handler to know when a slow command is complete.
- Handle the new type of 'slow' commands properly
BUG=chrome-os-partner:10533
TEST=manual
build and boot to kernel on snow
Change-Id: I11767d1a6f045a86f6c9a0b4b1e943b660e4da33
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32076
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Otherwise the host needs to tell the EC how big this image is (which
it knows, but it's inconvenient for it to provide).
BUG=chrome-os-partner:13511
BRANCH=all
TEST=manual
1. ectool echash recalc ro -> prints hash of RO code (offset 0)
2. ectool echash recalc rw -> prints hash of RW code (offset non-zero)
In each case, size should be an exact number and not the size of the
whole RO or RW section. So for link, output should be something similar to:
localhost ~ # ectool echash recalc ro
Hashing EC-RO...
status: done
type: SHA-256
offset: 0x00000000
size: 0x00012a64
hash: 03a66c076d6dd4b4aa9ed6386713f45291f5143f9af2093003e632485899daf1
localhost ~ # ectool echash recalc rw
Hashing EC-RW...
status: done
type: SHA-256
offset: 0x00014000
size: 0x000123d1
hash: 0d6225e70f0b1e0419e987370371e00783f945827ef25915a8fb8549159dd2a4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
3. At ec console, 'hash ro' or 'hash rw' should regenerate the same
hash values printed above.
Change-Id: I3f6085d29927b8cdf9dabc6930f0fdc7222bd8b5
Reviewed-on: https://gerrit.chromium.org/gerrit/33123
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Previously this was in lightbar.h. ec_commands.h should not require
other header files.
Also make brightness local variable static, so it won't leak outside
lightbar module.
This is simply code cleanup; values themselves have not changed.
BUG=none
TEST=if it builds, it's fine
BRANCH=none (not required in link branch since it's just cleanup)
Change-Id: I5722fb677fcec99e0826e3dfc0b22033781b576f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32815
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Yung-Chieh Lo <yjlou@chromium.org>
The code for warm reboot is overly specialized, and makes it hard to
add other key cominations for testing.
BUG=chrome-os-partner:13763
BRANCH=link
TEST=manual
1. boot system
2. hold down (in order) R+T+alt+VolUp. System does not reboot.
3. let go of T (so only R+alt+volup are pressed). System reboots.
Change-Id: I14cdb7f790e8a772712085a77eaf4299487788db
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32439
Reviewed-by: Simon Glass <sjg@chromium.org>
This has been deprecated in favor of a host event to trigger recovery mode.
BUG=none
BRANCH=link
TEST=manual
1. Power+Esc+Refresh -> recovery mode
2. Press power -> off
3. Press power -> boots normally (NOT recovery)
Change-Id: I9288785ce1c0a446867dc54d1b6ec2f556896688
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32426
Reviewed-by: Simon Glass <sjg@chromium.org>
Increase stack size slightly for vboot hash task since the vboot
SHA256 function allocates ~300 bytes of stack data. Reduce stack size
for watchdog, power LED, and a few other tasks with simple call trees
where we can be sure an error path isn't going to blow past the
reduced stack.
This frees up ~1KB of RAM on STM32.
BUG=chrome-os-partner:13814
BRANCH=all
TEST=boot system; shmem should show more unused RAM; taskinfo should show
tasks still have unused stack
Change-Id: I47d6b77564a0180d15d86667cc0566a8919b776e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32608
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a precursor to supporting task-specific task sizes. I've
benchmarked this vs. the current stack pointer method; no measurable
performance difference.
BUG=chrome-os-partner:13814
TEST=boot EC; taskinfo; if it boots and doesn't print garbage, it worked
BRANCH=all
Change-Id: Ia326c3ab499ac03cce78dbacaa52f735601a171e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32603
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This would improve boot speed when compared to storing in eMMC because
initialing eMMC is slow.
So far other platforms do not have this need because CMOS is quite
efficient; thus it is left unimplemented in lm4.
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
BRANCH=snow
BUG=chrome-os-partner:10660,13094
TEST=On Snow, see VbNvContext is preserved across power cycles (you have
to patch U-Boot to test this)
Change-Id: If5072c678b87bc47a3a82a1dff2afa3896304f36
Reviewed-on: https://gerrit.chromium.org/gerrit/31832
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
This only adds support in the EC; it doesn't add an ectool command.
We'll add that later. This also fixes a bug where the reserved byte
in the panic data structure wasn't being set to 0.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. crash unaligned -> system crashes
2. hostcmd 0xd3 -> returns a hex string 01010100...506e6321
3. hostcmd 0xd3 -> returns a hex string 01010500...506e6321
Change-Id: I1de8e19c44c835055d893986b42d152dc704c35f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32183
Reviewed-by: Simon Glass <sjg@chromium.org>
Jump data now precedes the panic data, if any, in memory.
BUG=chrome-os-partner:7466
BRANCH=all
TEST=manual
1. boot system
2. sysjump rw --> display should stay on and keyboard should still work
(this verifies jump data is properly read across sysjump still)
3. crash unaligned --> system should reboot
4. panicinfo --> should print the same crash dump as before, with (NEW)
5. panicinfo --> ditto, without (NEW)
6. sysjump rw
7. panicinfo --> ditto, without (NEW)
Change-Id: I88285724e82a15553ab25877e3d8ec4c74a4dd5a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/32051
This is in preparation for saving panic data across reboots for later
retrieval.
BUG=chrome-os-partner:7466
TEST='crash divzero' or 'crash unaligned'; should print dump and reboot
BRANCH=all
Change-Id: I997d160b00d03759eb9c69b53ab0f7a5ae144183
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/31951
Reviewed-by: Simon Glass <sjg@chromium.org>
