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>
The rambi board has issues using the SERIRQ method
for triggering the keyboard IRQ. Namely, the current
level-shifter in place for the bidrectional SERIRQ
signal introduces delay resulting in the SERIRQ
being out of phase with the clock. Moreover, there
appears to be a mismatch of expectations with the
number of start frames on the SEIRQ line. Bay Trail
uses a fixed 8 while the TI docs suggest it only
supports 6.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi with keyboard working in
kernel with interrupts.
CQ-DEPEND=CL:177223
Change-Id: I05c2b113d801b3fc434a402620cebae0301839f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177189
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On certain boards it's no feasible to use the SERIRQ
method for generating the kebyboard interrupt. To that
end provide CONFIG_KEYBOARD_IRQ_GPIO option which
specifies the negative edge-triggered gpio for the
keyaboard interrupt.
BUG=chrome-os-partner:23965
BRANCH=None
TEST=Built and booted rambi using this option. Keyboard
works in kernel with interrupts for i8042 device.
Change-Id: I64f7e9530841c184d2a33821126ec446c96bb0f0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177188
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is the initial commit of mec1322 support. This includes:
- Basic GPIO driver. Interrupt not supported yet.
- Microsecond timer
- UART driver
The script to pack the firmware binary will be checked in in
following-up CL.
BUG=chrome-os-partner:24107
TEST=Build and boot on eval board
BRANCH=None
Change-Id: I9013c908049d1f740f84bb56abca51b779f39eef
Signed-off-by: Vic (Chun-Ju) Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175716
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Indicate when usleep() and udelay() may be called.
No code changes, just comments.
BUG=none
BRANCH=none
TEST=Build any platform. Heck, it's just comments.
Change-Id: I0182c153c29965b25d5294d838c1406c30115099
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177452
Reviewed-by: Vincent Palatin <vpalatin@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>
The keyscan task is short enough on stack space that turning on
keyboard debugging causes a stack overflow. This was previously not
the default, but https://chromium-review.googlesource.com/#/c/174373/
made it the default. Reverting that change just masks the problem;
enabling keyboard debugging on Spring would still cause a stack
overflow.
Rather than reverting that change, increase the stack size of the
keyscan task so that it doesn't overflow. There is sufficient space
to do this. Even after increasing the keyboard stack from 256 bytes to
320 bytes and doing a 'sysjump rw' to force jump tags to populate,
'shmem' reports 132 bytes free.
BUG=chrome-os-partner:23834
BRANCH=none
TEST=Boot Spring.
ksstate on
Bang on keyboard for a bit
taskinfo -> shows KEYSCAN task at 292/320 bytes free
sysjump rw
shmem -> shows 132 bytes free, 0 used
Change-Id: Idf9fdce5b9e6ca4d05d80a62ae9ea831ed508e3a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177355
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This gives the AP a chance to reboot, before the EC kills it by dropping rails.
BUG=chrome-os-partner:24120
BRANCH=none
TEST=on AP, write 0xe to 0xcf9; system should reboot instead of shutting down
Change-Id: I322a1193e90b4de37a4adaf547e1c6bf5be077c3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177305
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Not sure why, but it doesn't seem to work consistently on my Spring.
Transmit works fine, but on some boots receive doesn't seem to pick up
received characters. Rather than churning Spring to fix this, just
disable receive DMA - which doesn't benefit Spring much anyway,
because it never downclocks its core to 1 MHz.
BUG=chrome-os-partner:24141
BRANCH=none
TEST=Boot Spring; typing into console works. After 'apshutdown', typing still
works (including arrow keys). Repeat 20 times. Repeat on Pit.
Change-Id: I5d9875b583c8e2a38b9070c4dfa31fd5a982a144
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177352
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Otherwise UART output gets garbled because there's a delay between
changing core clock and the UART divider. Fortunately, the glitch is
cosmetic and doesn't affect proper EC operation.
BUG=chrome-os-partner:23982
BRANCH=none
TEST=power on, power off on pit or nyan --> no UART glitch
Change-Id: I32bef119b850a340fc616b83a4b088b20f17267f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177087
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Poll down AP_RESET_L pin to shutdown AP immediately, instead of
press the power button for 8 secs.
BRANCH=nyan
BUG=chrome-os-partner:23895
TEST=verified on nyan board 2.0 with follwoing tests:
power off / power on: PASS. Tested 5+ times.
lid close / power off / lid open: PASS. Tested 5+ times.
button on / off: PASS. Test 5+ times. ~20% not boot (HOLD=1).
power off / button on: PASS. Tested 5+ times.
button off / power on: PASS. Test 5+ times. ~60% not boot (HOLD=1)
button off / lid open: PASS. Test 5+ times. ~40% not boot (HOLD=1)
Change-Id: Iecc97f38ac7bd923745994594356029836d7b4e6
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177241
For some reason the SCI# is not working properly when the
LPC module controls the pad. Instead, utilize CONFIG_SCI_GPIO
option and put that GPIO pad into open-drain mode.
BUG=chrome-os-partner:24003
BRANCH=None
TEST=Built and booted rambi with dependency change. 'lidclose' and
'lidopen' cause ACPI interrupts.
Change-Id: I5df455bc2fc9af4c43517a93c5a35dc598fd54e9
Reviewed-on: https://chromium-review.googlesource.com/176805
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The LPC module has a dedicated control for SCI#.
However, certain situations require a dedicated
GPIO for asserting the SCI# signal.
Introduce CONFIG_SCI_GPIO to meet this requirement.
BUG=chrome-os-partner:24003
BRANCH=None
TEST=Built and booted rambi with dependency change. 'lidclose' and
'lidopen' cause ACPI interrupts.
Change-Id: I34c5f0ba5ff60151972921f251c71d3769a9ef8b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176804
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of hardcoding the common files for host utils in the generic
rules, let's declare them in the build.mk file using the same system as
the Linux kernel build.
if a binary "foo" declared in "host-util-bin" or "build-util-bin" has a
matching "foo-objs" variable, it will be build from all objects declared
in "foo-objs" else it uses directly "foo.o" (single source file).
This is preparatory to add new "build" tools sharing common sources.
note: the dependencies on the utils are a bit less fine-grained as a
result of this change, but given the low number of tools, that should be
acceptable.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=./util/make_all.sh
Change-Id: Ieffce7ca6f5b685ffb7d1f4626b99aff07b61443
Reviewed-on: https://chromium-review.googlesource.com/176174
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
A cprintf could increase 96+ bytes of stack usage and may overflow
the stack of idle task, which is 256 bytes on stm32.
BUG=chrome-os-partner:23982
BRANCH=nyan
TEST=verified on nyan
Change-Id: If96a1c51010116a2b4f3d67481ec0acc7bf78dd9
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176619
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The ACOK buffer from EC to PCH was not being triggered when
the chipset powers up or down, instead it was only triggering
when AC state was changed.
Since we want it to be driven in S5 I added HOOK_CHIPSET_PRE_INIT
to the power sequence in the G3S5 state transition.
BUG=chrome-os-partner:23752
BRANCH=none
TEST=power on samus proto1b with AC inserted and see PCH_ACOK
go high, power off and see it go low again. Ensure that it is
also changed with AC state transitions.
Change-Id: I4cbe123322e234dc07f10fd1cdff5a8b771a4e02
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176630
Reviewed-by: Bill Richardson <wfrichar@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
The backlight_interrupt() function is defined to NULL if the magic
CONFIG_BACKLIGHT_REQ_GPIO is not defined.
Enabling that exposed an issue where the backlight workaround was
attempted in interrupt context and should instead be deferred since
it involves i2c transactions.
BUG=chrome-os-partner:23752
BRANCH=none
TEST=build and boot on samus proto1b and see recovery screen
Change-Id: Id1377033c791a5c279fdb4faeecc4b2c0d142eaa
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176514
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In board.c, we initialize this struct:
struct i2c_port_t {
const char *name; /* Port name */
int port; /* Port */
int kbps; /* Speed in kbps */
};
extern const struct i2c_port_t i2c_ports[];
The port field refers to the physical I2C bus on the EC.
Meanwhile, in board.h, we've identified the bus where each I2C device is
attached:
Up until this CL, we've been picking one of those device-to-bus macros to
initialize port fields of the i2c_ports[] array. That's wrong and confusing.
This change specifies the physical channel with the physical number.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Renaming only. There should be no change in observed behavior.
Change-Id: I5427c26290572133f060b6cf0d9ebea5015adba1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176176
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
The struct lightbar_params used to communicate lightbar settings between the
AP and the EC uses just "int" for some of its fields. The AP currently uses
32-bit values for "int" in both 64-bit and 32-bit mode, but that's just luck
since C only requires that "int" be at least 16 bits.
This change makes the size explicit.
BUG=none
BRANCH=none
TEST=manual
There should be no visible change.
ectool lightbar params > /tmp/foo
ectool lightbar params /tmp/foo
Change-Id: I4d77c16b3c68e179292b824938d2d012e917ad13
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176364
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Added low power idle functionality to rambi but left it off by default.
To turn it on, define CONFIG_LOW_POWER_IDLE in rambi's board.h file.
BRANCH=none
BUG=chrome-os-partner:23947
TEST=Verified that the EC does not go into deep sleep when in S0, and that
it does go into deep sleep in S3, S5, and G3. Tested to make sure that
flashec works when the EC is in low speed deep sleep. Also verified
that the EC console times out after the timeout period and that it wakes
up on the next command. Did not measure power usage.
Change-Id: I0ab1a2dc7ca7ae4577fe5d0894c1bf82205dfea6
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176159
Reviewed-by: Todd Broch <tbroch@chromium.org>
The XPSHOLD is not floated. It connects to +1.8V_VDDIO, which indicates
high when AP is on. So, bring it back.
Also remove the duplicated GPIO definition (GPIO_PWR_LED1).
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
BUG=chrome-os-partner:23929
BRANCH=nyan
TEST=verified on nyan. successfully boot up the machine.
Change-Id: I293a899bcdf255f36f6117627f66ed8231c9a70f
Reviewed-on: https://chromium-review.googlesource.com/176046
Reviewed-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Commit-Queue: Yung-chieh Lo <yjlou@chromium.org>
Tested-by: Yung-chieh Lo <yjlou@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Added ability to erase and program flash to iteflash.
BRANCH=none
BUG=chrome-os-partner:23576
TEST=generate random 192kB file, write it to the ITE chip, read flash
back and make sure file read in matches file written.
Change-Id: Id525b43e523a3d710ee65b623fec07800cf7f347
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176022
Reviewed-by: Vincent Palatin <vpalatin@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
We read a counted string (byte 0 = count, bytes 1 - count = chars) and
convert it to a null-terminated string. Since both have a 1-byte
overhead, we can use the destination buffer instead of using a
stack-based buffer.
BUG=chrome-os-partner:23928
BRANCH=none (pit is affected, but battery console command isn't used on
end user systems)
TEST=battery command shows correct strings (SDI / 4302D40 / LiP), and doesn't
stack overflow.
Change-Id: Ic0f111cde2d57b41d6ce9287e0c771acc09a8869
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176116
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Changes somewhere in the recent past have caused I2C operations to
consume more stack space. The current failure mode is that after some
debug command or infrequent battery operation, the system fails.
Clean up and enable stack overflow detection by default, and add a
debug command (disabled by default) to verify overflow detection
works.
This adds several instructions to each context switch, but it's still
fairly inexpensive, and represents only a few percent increase in the
size of svc_handler(). That's better than silent failures.
BUG=chrome-os-partner:23938
BRANCH=none
TEST=Enable CONFIG_CMD_STACKOVERFLOW, then run the 'stackoverflow' command.
This should cause a stack overflow to be detected in the CONSOLE task.
Change-Id: I9303aee5bd9318f1d92838b399d15fb8f6a2bbf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176113
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Bolt uses Link's battery, but doesn't override the smart battery charge
profile with CONFIG_BATTERY_VENDOR_PARAMS. But the image still compiles and
includes the battery_vendor_params() function, although it's never called.
This CL stops doing that.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
Build all targets.
Confirm that Link still has battery_vendor_params():
$ make BOARD=link
$ nm build/link/common/charge_state.o | grep vendor
U battery_vendor_params
$ nm build/link/driver/battery/link.o | grep vendor
00000009 T battery_vendor_params
$
Confirm that Bolt does not have battery_vendor_params():
$ make BOARD=bolt
$ nm build/bolt/common/charge_state.o | grep vendor
$ nm build/bolt/driver/battery/link.o | grep vendor
$
Change-Id: I48a535208bdcfd3d2cb26f6f15a28a728dbe4d0b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175731
Reviewed-by: Randall Spangler <rspangler@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
Temporary fix to the bug in which we miss wake events when in deep
sleep with the LFIOSC (32kHz) clock and the EC is cold. This fix
involves simply using a faster clock, 250kHz, when in low speed
deep sleep. This fix consumes more power but solves the bug.
Renamed EC console command dsleepmask to dsleep.
BRANCH=none
BUG=chrome-os-partner:23678
TEST=Go in to low speed deep sleep by going into either S3 or G3
and letting the EC console timeout. Then freeze-spray the EC chip.
Wake up the EC via the console and make sure that the idlestats
show that we have not missed a deadline.
Change-Id: I4f9844f1937bc8c95cf1540502f7d8fb4cbc097e
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175614
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rambi has a 65W adapter, so shouldn't be asking for 4A @ 19V.
BUG=chrome-os-partner:23597
BRANCH=none
TEST=charger command shows I_in = 3392 mA (which is the closest step below
3.42A that the charger can set).
Change-Id: I4b044b594566a6abcb94c3f674a0d287c8fc2b30
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175611
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
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>
Refine the GPIO list according to the schematic. Comment out the XPSHOLD in
power/tegra.c for compiling. Will fix later.
BUG=None
BRANCH=None
TEST=emerge-nyan chromeos-ec &&
make runtests -j 32 && make BOARD=nyan tests -j 32
Change-Id: Id0d682fd5d48e8a8a07785e86c07f45f07d866ab
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175534
Modify board.h and board.c to describe both fans.
BUG=chrome-os-partner:23530
BRANCH=samus
TEST=manual
Power things up, poke at the fans through the EC console. Observe that
they're both working and controllable:
faninfo
fanset 0 2000
faninfo
fanduty 1 30
faninfo
fanauto 0
faninfo
fanauto 1
faninfo
Change-Id: I2ba9356f084be12dab0fe0b9a004f66feace1878
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175369
Cortex-M3 and Cortex-M4 are not using exactly the same instruction set.
Cortex-M3 is using ARMv7-M ISA which is a subset of the ARMv7E-M used by
the Cortex-M4 core (even though the delta is small).
Let's restrict each core to the right subset of instruction by pushing
the -mcpu/-march configuration in the chip specific area.
Note: GCC 4.8 is now using the full ARMv7E-M instruction set and will emit
"undefined instruction" on Cortex-M3 without this patch.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:314194
TEST=build *and* run on Spring and Link.
Change-Id: I2f9b87fec689e8d1097809cab437a2bd32dfa194
Reviewed-on: https://chromium-review.googlesource.com/175487
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@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>
All the current data buffers *are* aligned, but we should check anyway
just to avoid unpleasant surprises in the future. This matches what
we do on STM32L. On STM32F, we copy a byte at a time so alignment of
the source data doesn't matter.
BUG=chrome-os-partner:9526
BRANCH=none
TEST=manual
flasherase 0x20000 0x1000
flashwrite 0x20000 0x200 -> succeeds
flashwrite 0x20201 0x200 -> fails
Change-Id: Id1a0fd8f6871e1fcdc3f55ec25eea40f33b5214c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175532
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Fixed bug in which two different tasks reading two different ADC
channels could interfere and cause the ADC clock to get disabled
when a read is still in progress, thus causing a reboot.
Added a runtime assert to verify that developers don't sample the
same ADC channel from multiple different tasks, which could cause
hard to trace reboots.
BRANCH=none
BUG=chromium:313872
TEST=1) Added console command to continuously read an ADC channel not
read anywhere else. Verified that when running this console command
I could reproduce the bug every few minutes.
2) Wrote code in adc.c to protect the ADC clock resource.
3) Ran console command from step 1 for ~2 hours with no reboots.
Change-Id: Ic1905dde12871a4b93957702f7f31a25a2762bb4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175404
Reviewed-by: Randall Spangler <rspangler@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>
- disable PP1800_PGOOD internal pullup
- add PP3300_DSW_EN control on PF6, turned on in S5 and off in G3
- change PCH_WAKE_L and PCH_PWRBTN_L to open drain signals
- add PCH_BL_EN interrupt on PM3 for rising edge to put backlight
controller into PWM mode, remove 1 second hook
- add samus-specific extpower handler for AC_PRESENT to buffer the
AC_PRESENT input to the new PCH_ACOK output on PM6. this is driven
high in S5/S3/S0 when AC_PRESENT is high, otherwise driven low.
BUG=chrome-os-partner:23752
BRANCH=samus
TEST=emerge-samus chromeos-ec
Change-Id: Ie8ab538610e41914212ee1f3a6287b63474fb85b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175281
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Right now, firmware changes are rejected if the HWTest or VMTest
stages fail. This is unnecessary as firmware changes are very unlikely
to break these stages.
BUG=chromium:285940
BRANCH=none
TEST=none, this is just copied from the coreboot repository
Change-Id: Id7ccff542b8abada41072ef26cd2b7d3ae179fd3
Signed-off-by: David James <davidjames@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175410
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The current chroot toolchain properly compiles the SVC instruction, so
there's no need to hard-code the opcode. That was a workaround for
binutils < 2.22 (that is, binutils versions more than 2 years old).
BUG=chrome-os-partner:23721
BRANCH=none
TEST=compare EC binaries before/after this change; only the
datestamp should be different
Change-Id: I9c6282768c4562926397866ac3be218c393e3865
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175172
