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>
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>
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>
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
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>
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>
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
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>
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>
This GPIO was configured as TTL. It should be open drain instead.
BUG=chrome-os-partner:27280
BRANCH=ToT
TEST=manual
Hard reboot, lightbar still works.
Try turning it off and on from the EC console:
> gpioset LIGHTBAR_RESET_L 0
lightbar goes dark.
> gpioset LIGHTBAR_RESET_L 1
> lightbar init
> lightbar on
lightbar comes on again.
Change-Id: If4d4beade8c95f3f231eeed435e35350ce866cea
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/192871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These are not currently checked by gerrit, but will be at some point
in the not-too-distant future.
The board/ directory gets additional owners to make it easier for
partner eng to make changes in ToT.
BUG=chrome-os-partner:27404
BRANCH=none
TEST=none (since gerrit doesn't check owners yet)
Change-Id: Ie21b9530fcc6d708ab987d9de80676f91faa72b9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191947
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is a complete rewrite of the charge_state task used by x86 platforms.
Rather than having a bunch of state-specific functions, each with their own
error handling and special cases, this is organized like so:
Forever:
1. Read everything we can from the battery and charger.
2. Figure out what we'd like to do (including error handling).
3. Allow for customization to override that.
4. Do it.
Things I need to file bugs for are marked with "TODO(wfrichar)". I'll file
the bugs after this CL goes in, so that they'll have something relevant to
refer to.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=manual
make buildall -j
Try it on Samus, watch it charge from nearly empty to full, both with and
without fastcharge enabled.
Also undefine CONFIG_BATTERY_PRESENT_CUSTOM, plug and unplug the battery to
be sure the trickle charging logic is correct when it can't tell if the
battery is present.
Change-Id: I3935cd3b87f322eb52178f8a675a886c16b75d58
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191767
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Vic points out a corner case that the battery LED could be off by
the followng steps:
1. charge the battery to very full
2. disconnact the AC so that the LED is off for discharge.
3. plug AC again, then charger enters INIT state -->
IDLE0 --> IDLE where those states don't toggle LED.
BUG=none
BRANCH=big
TEST=Reproduced this bug on big. Verified this has been fixed by this CL.
Change-Id: I7125acd6b11953675ac6d4085e31e0560b384015
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189757
This returns all the parameters of the charger that must be monitored
frequently. While some of the fields are charger-specific, all of the
parameters are present in all supported chargers.
Nothing uses this yet.
BUG=chrome-os-partner:20881
BRANCH=ToT
TEST=make buildall -j
All targets build; all tests pass.
Change-Id: Id3e00532469b193aeab3acf93e94afe3ffb8c6b6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191985
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In most cases we can't actually know whether a battery is present until
we've been able to talk to it. This adds that NOT_SURE case.
BUG=none
BRANCH=ToT
TEST=none
Nothing uses this case yet, and the only time that battery_is_present() is
called is when we have hardware to detect the battery (which always returns
YES or NO). This is just preparation for charge_state_v2, which will need
the NOT_SURE case for trickle charging.
Change-Id: Ic5793de080529d50c98860450a021a1abae168db
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191782
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Using minimal runtime to fit the charger flash and RAM size.
It is currently more an experiment than the final layout written in the
stone.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run on STM32F051 Discovery with
limited RAM and Flash to mimic STM32F031.
Change-Id: I10ee1decfd1f1448edbc909f0e997367921c4b53
Reviewed-on: https://chromium-review.googlesource.com/189405
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Looks like this board just missed a change to temporarily fork the
charger code while it is being refactored.
BUG=None
BRANCH=nyan,blaze
TEST=make -j BOARD=blaze
Change-Id: I4ca630cc5210486928fbeda9af3e9c11ddbc8daa
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/191214
once firmware branch exists, this commit need go into it and
doesn't need to be carried in master forever
BRANCH=blaze
BUG=chrome-os-partner:27120
TEST=USE="nyan_blaze" emerge-nyan_blaze chromeos-ec;flash nyan
board, verify ec is alive and version is reported as blaze
Change-Id: I115890a7122440a25c3d1f5e4b94248099a1de99
Signed-off-by: Neil Chen <neilc@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/190610
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Enable low power idle for Samus.
BUG=none
BRANCH=none
TEST=tested on samus. made sure EC comes up with no obvious
problems and that the EC goes into deep sleep a minute after
no console activity.
Change-Id: I00e196560759dfd62915e645319de606f2f29df3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190791
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Making room for a new charge_state implementation.
BRANCH=ToT
BUG=chrome-os-partner:23776
TEST=make buildall -j
No new functionality, just renaming some files.
Change-Id: I80ce861f09129a518e180cac20d32e867a93cd46
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190852
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After Alex's CL 8a9817a, the i2c driver no longer hardcodes the
I2C port pin (Ya!). Remove the conflict pin setting in board files.
BRANCH=nyan,big
BUG=chrome-os-partner:26620
TEST=build and run on nyan board. Everything looks good.
Change-Id: Iee2c5f10f642da7ad00f503b6e615cb6aa472459
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189245
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Remove power_led_task and add the big-specific LED logic
BRANCH=big
BUG=None
TEST=manually
>> ectool led power blue: PWR LED blue
>> ectool led power yellow: PWR LED orange
>> ectool led power off: PWR LED off
>> ectool led power auto: PWR LED auto control
>> ectool led battery blue: BAT LED blue
>> ectool led battery yellow: BAT LED orange
>> ectool led battery off: BAT LED off
>> ectool led battery auto: BAT LED auto control
Signed-off-by: Cloud Lin <cloud_lin@compal.com>
Change-Id: I5ded361a46c627e4e4e6fcb6bddea9b487a46768
Reviewed-on: https://chromium-review.googlesource.com/188631
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Until we have real hardware, use the STM32F072B Discovery board as a
test vehicle and do a configuration compatible with both boards.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=run EC console on STM32F072B Discovery board,
and pass all available unit-tests on target.
Change-Id: Ica691f9fc915d2873761025e7c019f8a6484b9b1
Reviewed-on: https://chromium-review.googlesource.com/188984
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Big can't be powered on by using 4s LGC AC14B8K battery.
Thus, add 4s battery definition to ec.
BRANCH=big
BUG=chrome-os-partner:26533
TEST=flash ec to big device and confirm battery works
Change-Id: I32d2eb2fabc70f3fc075a49a67c1fd4d30975981
Signed-off-by: MilesDY_Chen <MilesDY_Chen@compal.com>
Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188651
The charger task was holding this either on or off in S3, no matter what we
wanted. We really only need to set it at S3->S0 or S3->S5, or when the
lid opens or closes. The rest of the time we should be able to turn it off
and on with gpioset, for testing purposes.
BUG=chrome-os-partner:26502
BRANCH=ToT
TEST=manual
Check the state with
gpioget TOUCHSCREEN_RESET_L
Open and close the lid, suspend the AP with powerd_dbus_suspend, etc. The
touchscreen should be on when the lid is open and the AP is in either S3 or
S0, off when the lid is closed or the AP is off.
Then
gpioset TOUCHSCREEN_RESET_L 1
gpioget TOUCHSCREEN_RESET_L
gpioset TOUCHSCREEN_RESET_L 0
gpioget TOUCHSCREEN_RESET_L
The change should persist as long as nothing else changes.
Change-Id: If7b6f809b1b28ae2699d0fbc6c9b2305fc57cbff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188869
Reviewed-by: Randall Spangler <rspangler@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>
The EC had inputs with internal pullups on SUS_STAT#, SUSPWRDNACK, and
SLP_SX#. But we never used those signals for anything. The pullups
cost 1.5 mW power in S3. So, remove those signals and their pullups.
They can be turned back on via CONFIG_CHIPSET_DEBUG.
BUG=chrome-os-partner:25568
BRANCH=rambi
TEST=build with and without CONFIG_CHIPSET_DEBUG. Verify gpioget and
powerindebug show the signals only when it's defined.
Change-Id: I0851243615c91a3aa8aa1b28df70809b578d2e74
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188389
Reviewed-by: Dave Parker <dparker@chromium.org>
Added rotation of accelerometer data into a standard reference frame
so that the host does not have to know about the orientation of the
sensors.
Also added a calibration routine to calibrate the rotation matrix to
get to the standard reference frame. Cleanup up calibration in the
process to make it more user friendly.
Changed the default accelerometer sampling rate to 100Hz.
BUG=chrome-os-partner:25599
BRANCH=rambi
TEST=Tested the full calibration routine on a glimmer at my desk.
Used 'taskinfo' and verified that the higher sampling rate does not
bog down the EC. I found that the motion sense task is running for
about 200ms every 10 seconds, so about 2% CPU load.
Change-Id: I9ca1a4252f62a54016009c7d5e43b4cb1adf7e1d
Original-Change-Id: Id554511f7cc9549dfc9ed2d6337216bfa639359d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187172
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188385
This was always supposed to be open drain.
BUG=chrome-os-partner:22870
BRANCH=ToT,samus
TEST=manual
Try turning it off and back on again. ;-)
gpioset TOUCHSCREEN_RESET_L 0
gpioset TOUCHSCREEN_RESET_L 1
gpioset TOUCHSCREEN_RESET_L 0
Change-Id: I5e2a49c979294f68b86e2c91d2ccee5f6128ef5a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188045
Reviewed-by: Randall Spangler <rspangler@chromium.org>
