| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change configures MPU to prevent instruction fetch from the flash image
that is not running at the time system_disable_jump is called. Violating
the protection causes instruction access violation, then the EC reboots.
RO image protection is tested as follows:
...
[6.255696 MPU type: 00000800]
[6.255874 RAM locked. Exclusion 20005680-200056a0]
[6.256168 RO image locked]
...
> sysjump 0
Jumping to 0x00000000
=== PROCESS EXCEPTION: 03 ====== xPSR: 60000000 ===
r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8
r4 :200032f0 r5 :00000000 r6 :20002b70 r7 :20002df4
r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000
r12:00000002 sp :20002358 lr :0002a1a7 pc :00000000
Instruction access violation, Forced hard fault
mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0
=========== Process Stack Contents ===========
200023c0: 00000098 00000000 00000000 0002a785
200023d0: 00000002 20002dfd 00000007 20002b70
200023e0: 00000002 00025777 00000000 20002dfd
200023f0: 20002df4 20002dfc 00000000 00000000
Rebooting...
Memory management fault status register has bit0 set, indicating there was an
instruction fetch volation. FYI, RAM protection is still working:
> sysjump 0x20000000
Jumping to 0x20000000
=== PROCESS EXCEPTION: 03 ====== xPSR: 60000000 ===
r0 :00000000 r1 :2000541c r2 :00001388 r3 :20007fe8
r4 :200032f0 r5 :20000000 r6 :20002b70 r7 :20002df4
r8 :0002d308 r9 :20002df4 r10:00000000 r11:00000000
r12:00000002 sp :20002358 lr :0002a1a7 pc :20000000
Instruction access violation, Forced hard fault
mmfs = 1, shcsr = 70000, hfsr = 40000000, dfsr = 0
=========== Process Stack Contents ===========
200023c0: 00000098 00000000 20000000 0002a785
200023d0: 00000002 20002e06 00000007 20002b70
200023e0: 00000002 00025777 00000000 20002e06
200023f0: 20002df4 20002dfc 00000000 00000000
Rebooting...
TEST=Booted Peppy. Tested lid close & open. Ran Flashrom from userspace to
update main firmware then software-synched an EC image.
BUG=chrome-os-partner:16904
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Id4f84d24325566a9f648194166bde0d94d1124dc
Reviewed-on: https://chromium-review.googlesource.com/169050
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The spec does not mandate any way to read back the threshold settings
themselves, but when a threshold is crossed the AP needs a way to determine
which sensor(s) are responsible. Each reading of the EC_ACPI_MEM_TEMP_ID
register clears and returns one sensor ID that has crossed one of its
thresholds (in either direction) since the last read. A value of 0xFF means
"no new thresholds have tripped". Changing or enabling the thresholds for
any sensor will clear the unread event count for that sensor.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host, set a couple of thresholds to low values so they trip
immediately (I'm testing on Link):
# dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
#
# dptf 5 0
# dptf 6 10
# dptf 7 3
# dptf 5 2
# dptf 6 10
# dptf 7 2
On the EC console, see that two thresholds have triggered, and that there
are two bits set in the AP seen mask:
[45.755365 DPTF sensor 0, threshold -63 C, index 1, enabled]
[45.768940 DPTF sensor 2, threshold -63 C, index 0, enabled]
[46.169490 DPTF over threshold [0][1]
[46.169820 DPTF over threshold [2][0]
> dptftemp
sensor thresh0 thresh1
0 --- 210* I2C-USB C-Die
1 --- --- I2C-USB C-Object
2 210* --- I2C-PCH D-Die
3 --- --- I2C-PCH D-Object
4 --- --- I2C-Hinge C-Die
5 --- --- I2C-Hinge C-Object
6 --- --- I2C-Charger D-Die
7 --- --- I2C-Charger D-Object
8 --- --- ECInternal
9 --- --- PECI
AP seen mask: 0x00000005
>
Read the EC_ACPI_MEM_TEMP_ID register from the host, to get the two active
sensor IDs (0 and 2), then 0xff when those are seen.
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x00
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0x02
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 5; iotools io_read8 0x62
0xff
#
Change-Id: I8f047a517357617f18ad59d21fa13409bc81821b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/180224
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This renames constants used in compiler conditionals to uppercase.
BOARD_foo
CHIP_foo
CHIP_FAMILY_foo
CHIP_VARIANT_foo
CORE_foo
Mixed-case constants are still defined by the makefile, but are now no
longer used. I will make one more pass in a week or so to catch any
that are part of someone else's CL, since otherwise this change might
silently merge correctly but result in incorrect compilation. Then I
will remove defining the mixed-case constants.
BUG=chromium:322144
BRANCH=none
TEST=Build all boards. Also, "git grep 'BOARD_[a-z]'" should return no
results (similarly for CHIP, CORE, etc.)
Change-Id: I6418412e9f7ec604a35c2d426d12475dd83e7076
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179206
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Any of the EC's temp sensors can have up to two independent thresholds
attached to them. When the temperature crosses the threshold (rising or
falling), a EC_HOST_EVENT_THERMAL_THRESHOLD event is sent to the AP. It's up
to the AP to read the sensor values and figure out why the event was sent.
The thresholds are set and enabled with ACPI writes to three registers in
the EC interface space: EC_ACPI_MEM_TEMP_ID, EC_ACPI_MEM_TEMP_THRESHOLD, and
EC_ACPI_MEM_TEMP_COMMIT. Refer to the comments in ec_commands.h for details
on their use.
ACPI does not provide any means to read the threshold settings (the AP will
just have to remember), but there is an EC console command "dptftemp", that
can be used to examine the current settings.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the EC console, check the current threshold settings and temperatures:
> dptftemp
sensor thresh0 thresh1
0 --- --- PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
3 --- --- I2C-Charger-Object
4 --- --- I2C-CPU-Die
5 --- --- I2C-CPU-Object
6 --- --- I2C-Left C-Die
7 --- --- I2C-Left C-Object
8 --- --- I2C-Right C-Die
9 --- --- I2C-Right C-Object
10 --- --- I2C-Right D-Die
11 --- --- I2C-Right D-Object
12 --- --- I2C-Left D-Die
13 --- --- I2C-Left D-Object
>
> temps
PECI : 318 K = 45 C
ECInternal : 306 K = 33 C
I2C-Charger-Die : 309 K = 36 C
I2C-Charger-Object : Not calibrated
I2C-CPU-Die : 309 K = 36 C
I2C-CPU-Object : Not calibrated
I2C-Left C-Die : 306 K = 33 C
I2C-Left C-Object : Not calibrated
I2C-Right C-Die : 307 K = 34 C
I2C-Right C-Object : Not calibrated
I2C-Right D-Die : 307 K = 34 C
I2C-Right D-Object : Not calibrated
I2C-Left D-Die : 306 K = 33 C
I2C-Left D-Object : Not calibrated
>
In this case, the PECI temp is 318 K, so let's set a threshold at 322 K. On
the AP:
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Back on the EC console, we see that the threshold has been set:
[768.176648 DPTF sensor 0, threshold 49 C, index 1, enabled]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Now do something on the AP to increase the temperature (webgl aquarium,
etc). When the temp goes above 322 K, the EC console reports it and sends a
host event, and the "dptftemp" command indicates the over-temp condition:
[815.367442 DPTF over threshold [0][1]
[815.367878 event set 0x00000100]
[815.368069 sci 0x00000100]
[815.368619 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322* PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Log out and wait for the temp to drop. You'll see that trigger a host event
as well:
[854.375713 DPTF under threshold [0][1]
[854.376147 event set 0x00000100]
[[854.376396 event clear 0x00000100]
> dptftemp
sensor thresh0 thresh1
0 --- 322 PECI
1 --- --- ECInternal
2 --- --- I2C-Charger-Die
...
Change-Id: I6bb34c615f37477ccf37163caaa94737baed8dae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179962
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds three new registers to the ACPI->EC interface, which will allow
the AP to set/clear two DPTF thermal threshold points for each temp sensor.
The registers are
EC_ACPI_MEM_TEMP_ID 0x05
EC_ACPI_MEM_TEMP_THRESHOLD 0x06
EC_ACPI_MEM_TEMP_COMMIT 0x07
It doesn't actually do anything yet, but the AP can now write those values.
BUG=chrome-os-partner:23970
BRANCH=none
TEST=manual
On the host:
dptf() {
[ "$#" -eq "2" ] || return;
iotools io_write8 0x66 0x81
iotools io_write8 0x62 $1
iotools io_write8 0x62 $2
}
Now watch the EC console while running on the host:
dptf 5 1
dptf 6 80
dptf 7 2
dptf 7 3
The EC should say
DPTF sensor 1, threshold 7 C, index 0, enabled
DPTF sensor 1, threshold 7 C, index 1, enabled
Change-Id: I71fa57e3ca7c7b5bb8892e63212bf294b44dece5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179778
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified the commond timer module to expire timers as soon as time matches
the deadline instead of only after the deadline is passed.
BRANCH=none
BUG=chrome-os-partner:24490
TEST=On a peppy:
- Run EC tests on host.
- Run all EC tests on the target.
- Keep the system on for days and occasionally verify that system is up and the keyboard is working.
On a spring:
- Run all EC tests on the target.
Change-Id: Ieabfb769cf22ff8b04ca6d0a306312b90ea20ff3
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179460
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The port 62/66 ACPI commands were implemented in chip/lm4/lpc.c. They should
be handled in common instead of being tied to a particular EC.
BUG=chrome-os-partner:23774
BRANCH=none
TEST=manual
read EC_ACPI_MEM_VERSION
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 0; iotools io_read8 0x62
0x01
write & read EC_ACPI_MEM_TEST
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 1; iotools io_write8 0x62 0xa5
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 1; iotools io_read8 0x62
0xa5
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 2; iotools io_read8 0x62
0x5a
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 1; iotools io_write8 0x62 0xbb
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 1; iotools io_read8 0x62
0xbb
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 2; iotools io_read8 0x62
0x44
read & write EC_ACPI_MEM_KEYBOARD_BACKLIGHT
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 100
(keyboard lights up)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62
0x64
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 50
(keyboard dimmer)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62
0x32
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 3; iotools io_write8 0x62 0
(keyboard goes dark)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 3; iotools io_read8 0x62
0x00
read & write EC_ACPI_MEM_FAN_DUTY
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 100
(fan on full)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62
0x64
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 50
(fan on half speed)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62
0x32
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 0
(fan off)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62
0x00
# iotools io_write8 0x66 0x81; iotools io_write8 0x62 4; iotools io_write8 0x62 0xff
(fan back to EC control)
# iotools io_write8 0x66 0x80; iotools io_write8 0x62 4; iotools io_read8 0x62
0xff
test EC_CMD_ACPI_QUERY_EVENT
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x00
On EC console:
> hostevent set 0x0f000000
# ectool eventget
Current host events: 0x0f000000
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x19
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x1a
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x1b
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x1c
# iotools io_write8 0x66 0x84; iotools io_read8 0x62
0x00
# ectool eventget
Current host events: 0x00000000
Change-Id: I011a5a2051171ec1d37e55ce03e1ce74b93a7e14
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes the toolchain tries to put a relocation which is not suitable
to access variables in a read-only section.
The nds32 gcc uses GP-relative signed 17-bit relocation to access
variables stored in .rodata (eg lwi.gp $r0, [ +gp ])
That's wrong since $gp is pointing in the middle of .data and .bss in
the SRAM, while .rodata is sitting in flash.
Since on IT8380, the flash is at 0x00000 and the SRAM is at 0x80000
(512kB further), the linker will fail trying to create the signed 17-bit
relocation (it detect that it needs to truncate it)
Force the compiler to put another relocation as a workaround for now.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:24378
TEST=./util/make_all.sh ; make BOARD=it8380dev
check "version" and "gpioget" on spring, link and it8380dev.
Change-Id: Ife50adf3a26be28f113292f73a1a70e8d74b5d8c
Reviewed-on: https://chromium-review.googlesource.com/176913
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are detecting Apple charger type, we disable TSU6721 interrupt.
This, however, doesn't create a race condition, because any pending
interrupt fires immediately after we re-enable TSU6721 interrupt, and in
turns schedules charger task. As a result, charger task gets waken right
after it finishes its current iteration.
As for overcurrent detection, the current algorithm seems to do a good
enough job.
BUG=chrome-os-partner:23743, chrome-os-partner:23744
TEST=None
BRANCH=None
Change-Id: Ib3a6d562a305020ef5413e2a493e4163a6e70954
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179303
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "kbpress" command had a few issues if you wanted to reliably use
it for automation. Specifically it was not possible to guarantee how
much time would pass between the press of a key and the release of a
key. Sometimes you might press and release before the key was
officially "there" and sometimes you might get a press and hold of a
key.
Fix this:
1. Make it so that kbpress with no press/release parameter gives a
press and release (and guarantees that the press / release will
actually take effect).
2. Make it so that kbpress guarantees that when it finishes that the
key has actually been pressed or released.
BRANCH=pit
BUG=chrome-os-partner:24249
TEST=kbtype is (https://chromium-review.googlesource.com/178680) reliable
TEST=make -j32 BOARD=bds tests && make BOARD=bds runtests
TEST=Pick Ibe00a796bde7d06416889b621359671a2f68e162 and test.
Change-Id: Ia213ab2e8d8da273e3ac4876d97d5452df88f47d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178983
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 247650ecc90385417f5dcb2d60bb6ae1e5cfa32f)
Reviewed-on: https://chromium-review.googlesource.com/179325
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It worked on Link because the fan number and the fan channel were both 0.
Samus has two fans, connected to different GPIOs.
In the EC's ACPI interface block, register 0x04 is used to get and set the
fan's target duty cycle, as a percentage value. Writing a 0 to this register
will set the target duty cycle to 0, writing a 100 (0x64) will set it to
100%. Writing any other value will return the fan control to the EC, rather
than driving it manually from the host.
Likewise, reading from this register returns the current fan target duty
cycle, as a percentage. If the EC is controlling the fan automatically, the
returned value will be 0xFF.
BUG=chrome-os-partner:23972
BRANCH=samus
TEST=manual
You can monitor the fan state from the EC console with the "faninfo"
command. From the host side, test this interface from a root shell.
Read fan duty:
iotools io_write8 0x66 0x80
iotools io_write8 0x62 4
iotools io_read8 0x62
Set fan duty to 100%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 100
Set fan duty to 50%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 50
Set fan duty to 0%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 0
Set fan control back to automatic:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 -1
Change-Id: I3a133b0b16e2a5e1ce04b16cb2bf035a04a83daf
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179373
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The samus lightbar uses different LEDs from Link. Adjust the per-color
current limits accordingly. Also swizzle the layout, since LEDs 0/1 and 2/3
are swapped.
BUG=chrome-os-partner:24405
BRANCH=samus
TEST=manual
The colors were ugly and weird. Now they should be pretty and Googley.
Change-Id: I19f317243ff46852628b8b28f2bf6f5e02c6e631
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179160
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the non-core dependent code out of core/$(CORE) directory to
common/ directory.
Put all panic printing code in common/panic_output.c
Put timer management code in common/timer.c
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23574
TEST=./util/make_all.sh
use "crash divzero" and "panicinfo" on Link.
Change-Id: Ia4e1ebc74cd53da55fe24f69e96f39f512b9336d
Reviewed-on: https://chromium-review.googlesource.com/178871
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Jeremy Thorpe <jeremyt@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove jumped_to_image check in system_run_image_copy because it's redundant.
disable_jump will be set by VbExEcDisableJump explicitly, whether the EC stays
in RO or jumps to RW.
TEST=Built and booted Peppy. Ran flashrom from user space and verified
the EC firmware was updated after reboot.
BRANCH=none
BUG=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: If1a3cf6158b3bc97c965298d2ab958b5fa7a5d7e
Reviewed-on: https://chromium-review.googlesource.com/172651
Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Tested-by: Daisuke Nojiri <dnojiri@google.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nyan EC supports 2 different boards: Venice2 and Norrin. Venice2
uses 2S battery, and Norrin uses 3S battery. This CL is to support
2 different battery types (2S or 3S) automatically at init time by
reading battery's MANUF_NAME, DEVICE_NAME and DESIGN_VOLTAGE from
Smart Battery Interface to determine which battery type to use.
To workaround the problem that battery may not be attached at init
time, a patch is added to call battery_get_info() in PWR_STATE_INIT
state to get the current battery info. Note the battery info is only
determined once.
BUG=none
BRANCH=nyan
TEST=tested on Vencie2 with 2S battery and on Norrin with 3S battery
attached at init time and made sure correct battery info are
installed;
tested on Venice2 and Norrin without battery at init time, then
attached 2S or 3S battery and made sure correct battery info are
installed.
Change-Id: I135909c7fe1e1dfdb0f706e0eadba6e904b6221e
Signed-off-by: Yen Lin <yelin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/178088
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows boards to detect the battery and return the correct temp
ranges, which will be needed for upcoming boards.
In the board-specific implementations, it's pretty much just moving
the fields from one const struct to another, so the impact is minor.
BUG=chrome-os-partner:24310
BRANCH=none
TEST=build all platforms; verify pit and rambi still charge
Change-Id: I7be075b3abb4039577f6362316adc1860c121d5c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178424
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Smart batteries can report capacity in mAh or 10mW units. We forced
the units to mAh in charge_state.c's main loop, but that doesn't
guarantee that they're actually set before the capacity is read. It's
cleaner to check the capacity reporting mode when actually reading the
capacity.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=battery command reports the same capacity data before/after change
(on rambi, design=2940 mAh)
Change-Id: I4a4c80eaade72bb09627d5d65693c097e264a992
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The charge state machine asks for all of this stuff at the same time
anyway. Bundling it into a single function removes a number of
redundant (and painfully slow) I2C reads.
Also refactor the battery debug command so it doesn't have so many
local variables all in one function; it was consuming considerably
more stack space than any other debug command.
Spring still needs low-level access to the smart battery, so move the
two functions it needs directly into the Spring implementation.
BUG=chrome-os-partner:20881
BRANCH=none
TEST=charge/discharge rambi, pit and spring; watch debug messages and
LED and output of 'battery' debug command. All should behave the
same as before. Then run 'taskinfo' and see that the console task
has at least 20 bytes unused.
Change-Id: I951b569542e28bbbb58853d62b57b0aaaf183e3f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177797
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These boards are unloved and unsupported. They'll never grow up to be
laptops, and hardware is increasingly hard to come by.
Comparable functionality is available in the other, more-loved boards.
Removing these boards speeds up util/make_all.sh by 40%. (If you're
not running that before every upload, you should be...)
BUG=chrome-os-partner:24062
BRANCH=none
TEST=build all remaining platforms and pass unit tests
Change-Id: I4d8a49e4d52d7393471f1b1cbef059c8db4a4f77
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds include/dptf.h to define the DPTF interface functions.
As the first DPTF feature, it also adds a register to the EC's ACPI
interface block. Register 0x04 is used to get and set the fan's target duty
cycle, as a percentage value. Writing a 0 to this register will set the
target duty cycle to 0, writing a 100 (0x64) will set it to 100%. Writing
any other value will return the fan control to the EC, rather than driving
it manually from the host.
Likewise, reading from this register returns the current fan target duty
cycle, as a percentage. If the EC is controlling the fan automatically, the
returned value will be 0xFF.
BUG=chrome-os-partner:23972
BRANCH=none
TEST=manual
You can monitor the fan state from the EC console with the "faninfo"
command. From the host side, test this interface from a root shell.
Read fan duty:
iotools io_write8 0x66 0x80
iotools io_write8 0x62 4
iotools io_read8 0x62
Set fan duty to 100%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 100
Set fan duty to 50%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 50
Set fan duty to 0%:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 0
Set fan control back to automatic:
iotools io_write8 0x66 0x81
iotools io_write8 0x62 4
iotools io_write8 0x62 -1
Change-Id: I91ec463095cfd17adf452f0967da3944b254d558
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177423
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Converting some of the boolean variables in vfnprintf() to a single
flags word reduces stack usage by 8 bytes and function size by 12
bytes. So it's slightly more efficient in both respects.
Confirmed size and stack usage improvements via 'make BOARD=rambi all
dis' and looking at the disassembly for vfnprintf()
BUG=chrome-os-partner:24148
BRANCH=none
TEST=Run taskinfo command twice and compare stack used by CONSOLE task.
Run timerinfo and charger commands and verify output looks reasonable;
those exercise binary and 64-bit number printing.
Change-Id: Ie4396bb0bc01dc155956fa2d8ca84c6630006729
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177400
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=none
BUG=chromium:318342
TEST=Run "ectool boardversion" on device with and without support
for board ID. Note, boards without support will return an error.
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: Ib7599570c84a7ed5cf70ce9d8336467785b35569
Reviewed-on: https://chromium-review.googlesource.com/176543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds space for up to two ALS lux readings to be available to the AP
through the memory-mapped LPC region. If enabled, the values are updated
once a second.
The ALS will be reinitialized at every AP resume, since it's typically
unpowered otherwise. The reported value will be zero when the ALS is off.
BUG=chrome-os-partner:23380
BRANCH=samus
TEST=manual
Boot the AP, then from the EC console run "als" or just monitor the
memory-mapped region directly ("rw 0x40080780" on Samus), while pointing the
sensor at bright and dim areas. The value should change.
Change-Id: I705371fcd57345dc9adae1231ea30c7ff024aaf8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176142
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the driver and a console command to read an Intersil ISL29305
light sensor connected to the EC.
BUG=chrome-os-partner:23380
BRANCH=samus
TEST=manual
Run the "als" command from the EC console, while pointing the sensor in
various directions. It should give higher numbers when facing a light
source. If you get "Error 1", it means the ALS isn't powered.
Change-Id: I855ed64dab7fc60e29126ab3e97669be24dc6a64
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is preparatory work to introduce a second core architecture.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:23574
TEST=./util/make_all.sh
Change-Id: Icae8a7e475a4ba2a13f0d8f95629e8498a5a61da
Reviewed-on: https://chromium-review.googlesource.com/175419
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The smart battery status register holds some useful info. This displays it
along with all the other stuff.
This decodes the alarm and status bits, but not the error code, since that
field is only valid immediately after a failed i2c transaction (that's how
the battery indicates error). Since we do all sorts of automatic battery
probing in other threads, that value will never be reliable when we run the
"battery" console command.
BUG=none
BRANCH=none
TEST=manual
Run "battery". You should see a new line amongst the output:
Status: 0x00c0 DCHG INIT
Change-Id: I5e684198af2cf7767f89786c91a7d946ad95d4c2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175659
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That way all the users of jump tags don't need to know about the
padding requirements.
BUG=chrome-os-partner:23851
BRANCH=none
TEST=enable CONFIG_CMD_JUMPTAGS, then 'jumptags'. Output should be
something like this:
20007fbc: 0x5550 UP.1 2
20007fc4: 0x4b42 KB.2 3
20007fcc: 0x4c50 LP.1 12
20007fdc: 0x4d54 MT.1 8
All the addresses in the first column should be word-aligned. The
sizes in the last column don't need to be a multiple of 4.
Change-Id: I91f9c29701a007ef8a56b5b7e0ea09930dfbea31
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175591
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fan no longer needs a special priority to wait for the host memmap to
become available, since LPC inits earlier.
I2C and PECI don't need explicit ordering on freq change.
Thermal now uses the explicit prio for temp sensors done.
Commented hook test.
BUG=chromium:314768
BRANCH=none
TEST=boot link; enable/disable PLL; verify fanset and temps commands work afterwards.
Change-Id: I71766614dff2950dd307acd0635405e6b59e330a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175601
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Almost done. Comment changes only.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I974dfc12aa264e2035b3bae35a089c19344e7d45
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175484
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds explicit "int fan" args to the exported functions from
common/fan.c: fan_set_percent_needed() and fan_percent_to_rpm(). Within that
file, multiple fans are handled independently.
This is not complete, though. Host commands and sysjump support still only
handle a single fan, so at the moment multiple fans are treated identically
in those cases.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
All boards build, "make runtests" passes.
On a multi-fan system, the EC command "faninfo" displays multiple results:
> faninfo
Fan 0 Actual: 0 rpm
Fan 0 Target: 0 rpm
Fan 0 Duty: 0%
Fan 0 Status: 0 (not spinning)
Fan 0 Mode: rpm
Fan 0 Auto: yes
Fan 0 Enable: yes
Fan 1 Actual: 0 rpm
Fan 1 Target: 0 rpm
Fan 1 Duty: 0%
Fan 1 Status: 0 (not spinning)
Fan 1 Mode: rpm
Fan 1 Auto: no
Fan 1 Enable: no
>
and the "fanduty", "fanset", and "fanauto" all require the fan number as the
first arg:
> fanduty 0 30
Setting fan 0 duty cycle to 30%
> fanset 1 2000
Setting fan 1 rpm target to 2000
> fanauto 0
> fanauto 1
On single-fan systems, there is no visible change.
Change-Id: Idb8b818122e157960d56779b2a86e5ba433bee1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175368
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
More of same. Comment changes only; no code changes.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I8c42ed7d332cd9d461067e1aeac670855106cbcd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175405
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update comments with more info, or remove if no longer applicable.
No code changes.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: I5b56eeb500bc0f00e84e91ef99684f4b1b310972
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175418
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add bug links, reword, or remove as applicable.
No code changes, just comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: Id55dd530c10091d7ab9d0f942f750168fca793b4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175326
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add bug references. Remove one assert that can no longer be triggered.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I3f4d2e4f2f3343a8d0531cb0715d151eaa4d0b50
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175293
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Comment changes only; no code changes.
BUG=chrome-os-partner:11223
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I8f6f57514886dd1fda0e44cae1b036c22be481f8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175228
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No code changes, just comment fixes. Added config #ifdefs for the
debug commands as requested; they're enabled for Spring, so
functionality is unchanged.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build spring; see that ilim and batdebug commands still exist
Change-Id: I7c9f12281afa7ec68aa7e62dcfcd51682d88a16a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175216
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove comments if no longer applicable, or assign bug numbers if they
still are. Tidy some debug output. No code changes other than the
debug output.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms, pass unit tests
Change-Id: I2277e73fbf8cc93f3b1b35ee115e0f2f52eb8cf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175215
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than compile it by default for host-based tests, only compile
it for the few tests that actually use it. Since those (and all
boards) now only use if if they also have a keyscan task, we can get
rid of the #ifdefs in keyboard_mkbp.c as well.
And remove a TODO we'll never do...
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests. These pass:
util/make_all.sh
make BOARD=pit tests
Change-Id: I44d1806cfb375027a7ed0b33a5e9bdbbed8ccddc
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a logical difference between PWM controls for things like
backlights and fan controls for actual fans. This change separates them into
two different data structures, for better abstraction.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, make all boards, test on Link and Falco.
Change-Id: Ib63f2d1518fcc2ee367f81bf5d803360c1aa5c76
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175151
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just configuring fan support as yes/no, we'll use it to specify
the number of fans on the board. Undefined (not zero!) means no fan support
at all.
Syntax change only. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: Iff65efa69e05f3e1a54fdc2a8da9001b4e8487ca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175150
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This looks like a lot, but it's really just moving the non-board-specific
stuff from chip/lm4/fan.c into common/fan.c, updating the appropriate
headers, and renaming functions to better match the new location.
This is entirely code refactoring and renaming. No new functionality.
BUG=chrome-os-partner:23530
BRANCH=none
TEST=manual
make runtests, build all platforms, build and test on Link.
Change-Id: I7dc03d6732bad83cf838a86600b42a7cff5aa7aa
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175012
|
|
|
|
|
|
|
|
|
|
|
|
| |
BRANCH=none
BUG=chrome-os-partner:23608
TEST=Run "ectool gpioget GPIO_LID_OPEN" on a write protected machine
Change-Id: I578ca2828f66d6f4463150f5e108484115a977e8
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174821
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
No code changes, just updating comments.
BUG=chrome-os-partner:23558
BRANCH=none
TEST=compile bds project
Change-Id: I819244acafcf89a1e983bddecd82f770b0374ee1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No code changes, just tidying some comments and moving a TODO to a bug.
BUG=chrome-os-partner:23557
BRANCH=none
TEST=compile any project; hey, this is just a change in comments.
Change-Id: Ib1e3190ac9abdc90fb04c785e1f20b9cc66b1bc3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174447
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No code changes; just update comments with bug links
BUG=none
BRANCH=none
TEST=build all platforms
Change-Id: I8b845f9c43315b7db5a746a16c6618c3ee96979d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174614
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, it was really confusing whether I2C_PORT_HOST meant the
port where the EC was the master, or the port used to talk to the AP.
No functional changes, just a global find/replace and some tidying of
unused comments.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; pass unit tests
Change-Id: Ia591ba4577d3399729556e0234ba0db3a0e3c5ea
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174546
Reviewed-by: Alec Berg <alecaberg@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn't need to be compiled if there would be nothing for it to talk to.
BUG=chrome-os-partner:20739
BRANCH=none
TEST=build all platforms, pass unit tests
comment out chipset task in Rambi ec.tasklist; code still compiles
Change-Id: I004364b8c1fdf02c420162b5ad2843068a26b452
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Device-specific headers belong in driver/ or chip/. The include/
directory should be for common interfaces.
Code should not normally need to include driver-specific headers. If
it does, it should use the full relative path from the EC project root
(for example, drivers/charger/bq24715.h).
Change-Id: Id23db37a431e2d802a74ec601db6f69b613352ba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173746
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The common/ subdir was getting cluttered. Move drivers for external
components to a new driver/ tree, and move what used to be called
chipset_*.c to a new power/ directory.
This does not move/rename header files or CONFIG options. That will
be done in subsequent steps, since moving and modifying .c files in
the same CL is harder to review.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all boards; pass unit tests
Change-Id: I67a3003dc8564783a320335cf0e9620a21982d5e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173601
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Document some Pit-platform-specific assumptions.
No code changes.
BUG=none
BRANCH=none
TEST=build pit
Change-Id: I601ca4a57645ba45e7db01e271556a30d334f9cd
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174056
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|