The console task should be higher priority than the host command task,
since that allows debugging problems with host commands.
The keyboard scanning task should be higher priority than both of
them, since it's extremely latency-sensitive. As currently written,
long-running host commands such as I2C passthru can interfere with
keyboard scanning.
BUG=chrome-os-partner:22681
BRANCH=none (potentially affects pit, but apparently not noticeably)
TEST=type bursts of 6-8 characters quickly while doing a flash update
of the EC; should not drop characters.
Change-Id: I48db014053750a5f1fae5d06df34768975bb8297
Reviewed-on: https://chromium-review.googlesource.com/169334
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
This timing values act as most similar with 8042 which we used in snow
And some keyscan jig can not regognize current debounce timing, It based
on 8042 timing.
BUG=chrome-os-partner:22019
TEST= build and update ec, reboot and see keyscan is fine
Change-Id: I48f01f2e1247db5fa324b0896301616c42032585
Signed-off-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/168003
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
ADC module on STM32L is clocked by HSI oscillator, and thus we need to
switch to HSI if using MSI. After the conversion, if the system is not
in S0, clock is switched back to MSI again.
There are several register bits that can only be written when ADC is
powered down. For now, let's just power down the ADC after each
conversion.
Currently ADC watchdog is not working and is disabled on STM32L.
BUG=chrome-os-partner:22242
TEST=Try multiple all-channel and single-channel reads in S0 and S5.
BRANCH=None
Change-Id: I769dda8a9c69ac9de1eb22d6d259034eef8c1ac4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167454
This unifies the PWM module interface for LM4 and STM32. Now PWM
channels are defined in board.h/board.c. Instead of calling functions
named pwm_set_fan_duty(x), one can now use pwm_set_duty(PWM_CH_FAN, x),
which prevents additional functions added when we have a new PWM
channel.
BUG=chrome-os-partner:18343
TEST=Limit input current on Spring.
TEST=Check power LED in S0/S3/S5 on Snow.
TEST=Check keyboard backlight functionality on Link.
TEST=Check fan speed control/detecting on Link.
BRANCH=None
Change-Id: Ibac4d79f72e65c94776d503558a7592f7db859dc
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/64450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
With CONFIG_HOST_COMMAND_STATUS, the EC can respond to a command
with EC_RES_IN_PROGRESS, indicating to the AP that it should poll
for completion of the command with EC_CMD_GET_COMMS_STATUS. The
kernel, however, only guarantees the atomicity of single commands.
As a result, i2c passtrough or keyboard commands could be issued
while the AP is polling for completion of a flashrom command. By
disabling CONFIG_HOST_COMMAND_STATUS, we eliminate polling of the
EC status by the AP so that there is no interleaving of commands.
BUG=chrome-os-partner:20978
TEST=flashrom on Pit
BRANCH=pit
Original-Change-Id: I48b29a0dbbcc56fc55f72ca64b8aff51036740e3
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66703
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2db4fcfb267b938fcc35af2a0d2e374f99551743)
Change-Id: Iac7c15ec337d618cd6d95439d4b922bf3ec43916
Reviewed-on: https://gerrit.chromium.org/gerrit/66828
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Andrew Bresticker <abrestic@chromium.org>
Rather than have every board check for tasks before declaring their
config macros, have config.h know what configs are invalid without
their corresponding tasks.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms and pass unit tests
Change-Id: Iecf6eb44782e15565eaaf6d69c6288ee8d2e4c4c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/65010
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
GPIO alternate functions used to be configured throughout the code,
which made it hard to tell which ones you needed to configure yourself
in board.c. It also sometimes (chip/lm4/i2c.c) led to GPIOs being
configured as alternate functions even if they weren't used on a given
board.
With this change, every board has a table in board.c which lists ALL
GPIOs which have alternate functions. This is now the only place
where alternate functions are configured. Each module then calls
gpio_init_module() to set up its GPIOs.
This also fixes a bug where gpio_set_flags() ignored most of the flags
passed to it (only direction and level were actually used).
On stm32f, gpio_set_alternate() does not exist, and pins are
configured via direct register writes from board.c. Rather than
attempt to change that in the same CL, I've stubbed out
gpio_set_alternate() for stm32f, and will fix the register writes in a
follow-up CL.
BUG=chrome-os-partner:21618
BRANCH=peppy (fixes I2C1 being initialized even though those pins are used
for other things)
TEST=boot link, falco, pit, spring
Change-Id: I40f47025d8f767e0723c6b40c80413af9ba8deba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64400
The power button LED is on PA2, not PB3. Remove a line of code
accidentally left in from copy-paste at the start of pit bringup.
BUG=chrome-os-partner:21676
BRANCH=pit
TEST=boot pit
Change-Id: Id991b16d69bca0a411efa72211c5dc407923240d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/64714
Reviewed-by: Vic Yang <victoryang@chromium.org>
We've been declaring a bunch of statically-sized arrays:
extern struct foo_t foo[FOO_COUNT];
And then initializing them like so:
struct foo_t foo[FOO_COUNT] = {
/* blah */
};
That only catches cases where we initialize with too many entries. It
doesn't catch cases where we haven't initialized enough. This change tests
for both cases like so:
extern struct foo_t foo[];
struct foo_t foo[] = {
/* blah */
};
BUILD_ASSERT(ARRAY_SIZE(foo) == FOO_COUNT);
The affected arrays are:
adc_channels[ADC_CH_COUNT]
gpio_list[GPIO_COUNT]
temp_sensors[TEMP_SENSOR_COUNT]
x86_signal_list[X86_SIGNAL_COUNT]
i2c_ports[I2C_PORTS_USED]
BUG=chrome-os-partner:18343
BRANCH=falco,peppy
TEST=build all platforms
All platforms should still build, all tests should still pass.
Change-Id: Ibb16dc3201f32df7cdc875648e89ba4ffb09f733
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63833
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Before this change, powerinfo host command supports only one target
with USB charging. This change adds a common powerinfo host command
and console command for TPSChrome based targets.
BRANCH=None
BUG=chrome-os-partner:20326
TEST=manual
build and flash pit target, check console command 'powerinfo'.
check ectool powerinfo with and without AC adapter.
Change-Id: I2cfd8dfa011e23f819c6bae19cf22b4a7343f044
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63350
Reviewed-by: Vic Yang <victoryang@chromium.org>
This change moves vendor specific temperature ranges to battery pack
files or board setup files. And added a host test case to verify that
does not change x86 smart battery charging state machine behavior.
BUG=chrome-os-partner:21181
BRANCH=None
TEST=manual
build test: util/ecmakeall.sh
hosttests: make hosttests && make runtests
Change-Id: I48e76826b5555f64b78e3c063ce5f02416c72aa2
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62978
Reviewed-by: Vic Yang <victoryang@chromium.org>
No functional changes, just renaming config options.
Remove README, now that all options described in it have been moved to
config.h, and the remaining information is out of date. (Yes, we
should have a README which describes the organization of the EC
repository, but that's a matter for another CL; this one's about
cleaning up config options.)
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: Iafefbe94369f1217c698f11d358bc0ecac2bdfde
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63145
Reviewed-by: Vic Yang <victoryang@chromium.org>
All of these were defined on all but a few platforms, and those
explicitly #undef them. So define them as enabled by default in
config.h so the board.h files are cleaner.
No functional changes; just rearranging/renaming config constants.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; FEATURES=test emerge-falco chromeos-ec
Change-Id: I1201a1472ae29641e9e219c2a0347691ca64cd28
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63102
Reviewed-by: Vic Yang <victoryang@chromium.org>
No functional changes, just documenting and renaming.
All boards which use the PMU must provide pmu_board_init(). This was
already true - except that Daisy's pmu_board_init() was implemented as
part of pmu_init() instead of its code living in board.c; I've moved
the code there now.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I85ad06dc3b6287ad917fe13acf83182f24a8f23d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62906
Reviewed-by: Vic Yang <victoryang@chromium.org>
No functional changes, just documenting and renaming.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I0b0d3cdce535d90ce437e82e96346fc3ca9be7b0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62673
Previously, code which needed to work on all STM32F platforms needed
to specify them by name (CHIP_VARIANT_stm32f100 ||
CHIP_VARIANT_stm32f10x), and we needed extra symlinks in the
chip/stm32/ directory to allow the build system to find
family-specific files.
Add a CHIP_FAMILY level of abstraction, so that things which are
common across all STM32F platforms don't need to specify every STM32F
variant. Make the chip build look for family-specific filenames
instead of variant-specific filenames (except for config*.h, which is
actually variant specific).
In the few places where things actually are variant-specific, keep
using the existing CHIP_VARIANT defines.
Code refactoring only; no functional changes.
BUG=chrome-os-partner:20567
BRANCH=none
TEST=build all platforms
Change-Id: I1da831aadabf8b8dd9dfde423cac13c9f43eb953
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60247
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Power LED PWM now uses the same functions as the hardware timer.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=Suspend system. Power button LED pulses smoothly still.
Change-Id: Ib5ca6655d815462baaf68600ad14c4c0c680a6af
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59838
Automatically drop the clock speed to 1 MHz MSI, then disable HSI and
move to lower-power flash mode. This cuts power from 2400uA to 150uA.
Note that at 1 MHz, we drop received characters on the UART if you
type too fast (or copy/paste, or use arrow keys). Clock speed can be
manually overridden back to 16 MHz via 'clock hsi'.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=with AP on, 'clock' reports 16 MHz.
with AP off, 'clock' reports 1 MHz.
Change-Id: I070c80db0aa5f3a98a7bad6050890bcc2fe008d6
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59832
Modules which care about system clock frequency now hook HOOK_FREQ_CHANGE.
- hwtimer
- i2c
- uart (which is now also smart enough to use x8 oversampling instead of
x16 when the system clock is too slow to support x16)
Added 'clock' debug command to set system clock frequency.
STM32F platforms don't change clock frequency; on those platforms,
clock_get_freq() simply returns CPU_CLOCK, so behavior of those
platforms is unchanged.
BUG=chrome-os-partner:20414
BRANCH=none
TEST=from EC console:
- reboot ap-off -> to make sure AP is off during testing
- clock msi2 -> reports 2MHz clock
- battery -> reports battery info
- clock msi1 -> reports 1MHz clock
- battery -> reports battery info
- clock hsi -> reports 16MHz clock
- battery -> reports battery info
- power on -> AP powers on and host commands succeed
Change-Id: Ib8276bf124727e4fb502297ca8b3d6d4b6170241
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59645
Clean up timer initialization code to be more general, so that we can
use timer 9 for the LSB on STM32L. Then use timer 4 for the watchdog
helper.
BUG=chrome-os-partner:18781
BRANCH=none
TEST=From EC console:
timerinfo -> current time still counts up properly
waitms 2000 -> prints watchdog info before rebooting
Change-Id: Ib0ba496b0eadb93756dcd1841857546910baf2a9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59612
Reviewed-by: Simon Glass <sjg@chromium.org>
GPIO_HI_Z was a bit misleading (it's high impedance by default, but it's
actually an output not an input), but when we added GPIO_HI_Z_OPEN to mean
"open-drain output, pulled low by default", it got too confusing.
This renames those macros to:
#define GPIO_ODR_HIGH (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_HIGH)
#define GPIO_ODR_LOW (GPIO_OUTPUT | GPIO_OPEN_DRAIN | GPIO_LOW)
BUG=chrome-os-partner:18788
BRANCH=none
TEST=none
No functional change, just renaming some macros. If it compiles, it should
be unchanged in behavior.
Change-Id: Ic84d7be8531f2b240a8eca4f6cfe5291ebd2d5ef
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58596
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Frank's reworks turn AC_PWRBTN_L from a signal which co-mingled
AC-detect and pwower button press to a straight AC detect signal.
Switch from the hacky snow version of extpower to the simple gpio
version.
BUG=chrome-os-partner:20034
BRANCH=none
TEST=manual, using gpioget command
1. With AC plugged in, AC_PRESENT=1
2. Press power button. Still AC_PRESENT=1
3. Unplug AC, AC_PRESENT=0
4. Press power button. Still AC_PRESENT=0
Change-Id: I35df4ba80d0003310f3e01d9815158cfa3d0cb51
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58550
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This costs 232 bytes RAM; we still have over 6KB free.
BUG=chrome-os-partner:19945
BRANCH=none
TEST=taskinfo shows timing and interrupt counts
Change-Id: I1c4e4eac44b48c66b075b8ea209b4748c55b7fcb
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57511
When AP is off, turn off pullup on NSS, and set MISO to an input so
the SPI module won't drive it high if the last sent bit was a 1. This
reduces leakage when the AP is off.
This patch also fixes a bug where gpio_set_alternate_function() set
the wrong pins to normal-mode when func=-1; that didn't hit anything
else because that functionality wasn't used on STM32 until now.
BUG=chrome-os-partner:19304
BRANCH=none
TEST=boot pit
On EC console, with AP on, 'rw 0x40020000' returns
read 0x40020000 = 0x6569aa20 <- must have 0x____aa__
Then 'apshutdown' and 'rw 0x40020000' returns
read 0x40020000 = 0x65690020 <- must have 0x____00__
The 'power on' and AP turns back on. At u-boot prompt,
'sspi 2:0 256 9f00000000' returns
FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFEEC010001
(some number of 0xFD's followed by FEEC...) This shows SPI
functionality is restored when AP is powered back on, and not
just at init time.
Change-Id: Ia3cd3e0bc222dc663d635509918fa3d383fd7971
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51182
Reviewed-by: Simon Glass <sjg@chromium.org>
SPI is always enabled on pit, so remove #ifdefs
SPI1_CLK was aliased to AC_STATUS, which is left over from snow and
doesn't exist on pit. That caused it to be driven high briefly during
EC boot.
Also set SPI pins for 40MHz speed so we can try faster SPI clock.
BUG=chrome-os-partner:19304
BRANCH=none
TEST=boot system; sspi 2:0 256 9f prints a bunch of FDs then FEEC010001
Change-Id: I10352cff3669d6a087939d9d8e302d70708e9ee3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51023
Reviewed-by: Doug Anderson <dianders@chromium.org>
I've simplified the SPI module, since we only ever use SPI1 (and there
were already a number of places which assumed this was true).
Somewhere along the way I fixed a number of problems keeping the code
from compiling and working on STM32L. The code isn't currently used
anywhere else, but should still work there (that is, I don't think I
broke it working on STM32F if you re-enable it on some STM32F
platform).
BUG=chrome-os-partner:19073
BRANCH=none
TEST=from u-boot console, sspi 2:0 64 9f0000
u-boot prints: FDFDFDFDFDFDFDFD
ec prints: [193.740912 HC 0x9f][193.741141 HC err 1]
[sjg: gpio optimization back in for now]
[dianders: add comment as rspangler requested; update SOBs]
Change-Id: Ib9419403e4e44dadc1f17681e48401882cb49175
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49684
1) Port needs to be open-drain. Missed this when porting from STM32F
because open-drain and alternate function are set in the same register
on STM32F and are different regs on STM32L.
2) Queue a stop condition if a transaction failed, so the clock goes
back high.
BUG=chrome-os-partner:18969
BRANCH=none
TEST=i2cscan finds both the PMU at 0x90 and the battery at 0x16
Change-Id: I708b925e4e30da9d5864b74641b1cbe90c9313fe
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49898
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Now that I2C works, we can re-enable the charging task to debug
battery charging.
BUG=chrome-os-partner:18657
BRANCH=none
TEST=in EC log, should see battery state messages
Change-Id: I600d0152ba416c13420ce853b55206afba9f6cec
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49649
Also moves the handy i2cscan command to i2c_common. The
platform-dependent interface is now i2c_xfer().
Still more to do in follow-up CLs; for example, i2c_read_string() has
platform-dependent implementation, and the i2c/i2cread console
commands aren't common yet.
BUG=chrome-os-partner:18969
BRANCH=none
TEST=i2cscan on link, spring
Change-Id: Ia53d57beaa157bece293a4262257e20b4107589e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49492
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Queue: Daniel Erat <derat@chromium.org>
Commit-Queue: Simon Glass <sjg@chromium.org>
I2C communication doesn't work on pit yet, so the charger task is
spewing errors to the console. This change allows the task to be
disabled cleanly on pit, and has no effect on other platforms.
BUG=chrome-os-partner:18657
BRANCH=none
TEST=build all platforms and see that charger task is still compiled
everywhere but pit
Change-Id: I788e817d5630fb1a28694819f4ef9948a503a744
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49344
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CONFIG_ macros should be set directly. Expanding the task names in the same
way made it difficult to tell what was a configuration choice and what was
due to changes in ec.tasklist
BUG=chrome-os-partner:18343
TEST=build all, run link
BRANCH=none
Change-Id: Ib82e34f974238ee2dd216f33b701b6f4c6a4f1f1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49098
Reviewed-by: Randall Spangler <rspangler@chromium.org>
STM32-based platforms now use the same lid debouncing code as
LM4-based platforms, generate lid-open / lid-closed events, and
trigger lid-change hooks.
This is needed for disabling keyboard scanning when the lid is closed,
as well as future changes to mask off wake events when the lid is
closed.
BUG=chrome-os-partner:18896
BRANCH=spring
TEST=build all platforms; check that spring boots when lid is opened
Change-Id: I09a6e91119c3739297fe49b7eacac6efda988284
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48924
Reviewed-by: Vic Yang <victoryang@chromium.org>
Pit uses GPIO PA2=TIM2_CH3 instead of Snow's PB3=TIM2_CH2. Other than
that, the timer setup is identical (STM32F and STM32L are compatible
in this respect, anyway).
BUG=chrome-os-partner:18657
BRANCH=none
TEST=build snow, pit; no pit boards to test on yet
Change-Id: I8ba68f99641038e12c9a9c9dd29e3b64410a5eef
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48403
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a function which handles translation of PWROK from logical level
to physical level.
Also implement chipset_force_shutdown() in gaia_power.c, so PMU code
doesn't need to know about PWROK physical level.
BUG=chrome-os-partner:18738
BRANCH=none
TEST=build all platforms; boot spring
Change-Id: I360266ef89b6ead49a633cd57b7530f791b04c9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48251
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The latest schematics move a few signals between GPIOs. Update the
GPIO map to match.
BUG=chrome-os-partner:18657
BRANCH=pit
TEST=build pit (can't test the binary yet; no hardware)
Change-Id: I2d135412723fbe5cf4e7c1dbeb05fc68e6bb8c9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48231
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is left over from when we had a pair of macros for each GPIO
register, one which concatenated its base address name and one which
took a base address. Only the latter has survived, but its naming is
longer than it needs to be and isn't consistent with other register
banks (USART, TIM, etc.).
No code changes, just renaming macros.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I15a282fd01db2a25219970e28ce551d8dc80193f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48226
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
gpio_set_level() now allows setting the pin level if GPIO_LOW or
GPIO_HIGH is specified. Previously, stm32 platforms did this even
though the definition of gpio_set_level() said it wouldn't work.
Fixed gpio_set_level() not setting level after warm reboot on stm32
because it was checking the GPIO_DEFAULT flag in the wrong place.
Fixed LM4 still mucking with alternate function settings and levels
even if GPIO_DEFAULT was specified.
And checked gpio_list[] and all of the calls to gpio_set_flags() to
make sure everything still behaves the same way it did before (or
better, in the case of actual bugs).
BUG=chrome-os-partner:18718
BRANCH=none
TEST=build all platforms; boot spring and link
Change-Id: I4b84815f76060252df235ff9a37da52c54a8eac5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48058
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The MODER register is used to set (alt-func | analog | gpio-in |
gpio-out). So there's no need to force things to be normal GPIOs in
board config, since gpio_pre_init() will clear the alternate
function-ness as part of setting the GPIO direction.
BUG=chrome-os-partner:18657
BRANCH=none
TEST=build pit and test-boot on daisy
Change-Id: I82db9d9f4d8877464d62c1ff2efaef36822fc0ca
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47904
For most tests, we don't need to power the AP. Let's exclude chipset
task to save memory space.
BUG=chrome-os-partner:18598
TEST=Run pingpong test on Spring
BRANCH=none
Change-Id: I545c5b3e1c27b0067d4ffe09a7971d32b75d6039
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47833
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This only needs to be defined if CONFIG_USB_CHARGE is defined (that
is, if the board has a USB charge controller.
(Note the difference between providing power over USB vs. receiving
power over USB; the names are confusing and I'll rename one of the two
imminently.)
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I7355b4248bb2d4f5f71cc9f8d9d8f9d6c0069f2b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47658
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This changes current TASK() syntax to TASK_BASE() and TASK_NORMAL(),
where TASK_BASE is necessary for the EC to boot on a board and
TASK_NORMAL represents the task that can be removed in a test binary.
Tasks introduced by a test should be listed as TASK_TEST().
Note that this CL breaks current tests (many of them are broken anyway),
which will be fixed in up coming CLs.
BUG=chrome-os-partner:18598
TEST=Build link/bds/spring/snow/daisy/mccroskey. (mccroskey failed for
unrelated issue)
BRANCH=none
Change-Id: Ic645cdae0906ed21dc473553f1f43c2537ec4bb9
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47531
GPIO mapping is correct for current schematics.
Things to fix are #ifdef'd out with PORT_TO_PIT, but those require
changing other files (which is most tidily done in separate CLs).
BUG=chrome-os-partner:18657
BRANCH=pit
TEST=build pit (can't test the binary yet; no hardware)
Change-Id: Id1d1bb0c2925cfc0c21ee2d91666028aa6d2a707
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47599
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
