In order not to leak power to the PP3300_PCH rail
mark the PCH_SMI_L as open drain.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20175
BUG=chrome-os-partner:20054
BRANCH=None
TEST=Built and booted Faloc. No ill effects.
Change-Id: Ia4071067af177684579e146199f9ea174788b933
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58681
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
It was found that PL6 behaves in an inverted way when it is
configured as open drain. Add notes about determining why this
is. Apparently PL6 is an oddity w.r.t. the other pins.
BUG=chrome-os-partner:19811
BRANCH=None
TEST=built
Change-Id: I2d5b27f49c4e51ba4eb75cda9c798b9a5793f767
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58679
Reviewed-by: Duncan Laurie <dlaurie@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>
The gpio pin used for RCIN# should be configured as open drain as the
rail is pulled up by a non-EC rail. Driving it high would leak power.
BUG=chrome-os-partner:19355,chrome-os-partner:20173
BRANCH=none
TEST=manual: boot on falco without RCIN# causing reset and
the 'apreset warm' EC command works as expected.
Change-Id: I197928fd3cac27db3add9dd842e3171f23c9d71e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58590
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 adds the BQ24738 smart battery charger, and a placeholder for the Falco
battery pack. I don't have either documentation or a battery to use to test,
so the battery pack stuff is just a guess (see crosbug.com/p/20142).
BUG=chrome-os-partner:20098
BRANCH=none
TEST=none
Well, if you like, from the EC console, run "charger". It should say
something like this:
> charger
Name : bq24738
Option: 1111100100010010 (0xf912)
Man id: 0x0040
Dev id: 0x000f
V_batt: 0 (1024 - 19200, 16)
I_batt: 0 ( 128 - 8128, 64)
I_in : 3968 ( 128 - 8064, 128)
>
But since I don't have either a battery or a spec, I had to guess at the
battery configuration. To test the charger, we kind of need a battery.
Change-Id: I6e63d6b5aa8be4ba15e2c427d2e86364ef6251b3
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58466
This measures the analog voltage from the AC adapater's ID pin. The values
don't seem to match what we expected, so there's more work to come. Still,
here it is.
BUG=chrome-os-partner:19594
BRANCH=none
TEST=manual
From the EC console, run "adc". You should see a line like this:
ADC channel "AdapterIDVoltage" = 553
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idf84ceb6cd85d66d879f07bf4f26881ec078f638
Reviewed-on: https://gerrit.chromium.org/gerrit/58465
BUG=chrome-os-partner:18788
BRANCH=none
TEST=none
The connection to the LVDS controller is unstuffed, so there's nothing to
test without some soldering.
Change-Id: I5e6d9a3705554335512611b6b463568251b848b6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/58268
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
I don't think there are any power-sequencing changes.
BUG=chrome-os-partner:18788
BRANCH=falco
TEST=none
Nothing to test yet.
Change-Id: I2d0b7085fb5a5b853385049b61fe7796709702ae
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56137
The IOUT pin of the smart battery charger can be used to monitor the AC
adapter current (default) or the battery charging current.
BUG=none
BRANCH=none
TEST=manual
Discharge the battery a bit, and connect to the EC console. With the AC
power plugged in, the "battery" command should show charging status,
including current.
The "adc" command will display the A-D converters, including the current
measurement. For example:
> battery
Temp: 0x0b88 = 295.2 K (22.1 C)
Manuf: SMP-COS20
Device: OC2
Chem: LION
Serial: 0x0005
V: 0x4130 = 16688 mV
V-desired: 0x41a0 = 16800 mV
V-design: 0x39d0 = 14800 mV
I: 0x008e = 142 mA(CHG)
I-desired: 0x0080 = 128 mA
Mode: 0x6001
Charge: 98 %
Abs: 94 %
Remaining: 1871 mAh
Cap-full: 1923 mAh
Design: 2000 mAh
Time-full: 0h:23
Empty: 0h:0
>
> adc
ADC channel "ECTemp" = 317
ADC channel "ChargerCurrent" = 455
>
That current is significantly higher than the "I:" reported by the "battery"
command. But look at the charger options:
> sbc 0x12
0x7904 (30980)
>
Bit 5 controls the IOUT Selection. When clear, it monitors the current from
the AC adapter. Set bit 5 to monitor the current provided to the battery:
> sbc 0x12 0x7924
> adc
ADC channel "ECTemp" = 318
ADC channel "ChargerCurrent" = 128
>
That matches what the smart battery sees.
Change-Id: I2fe351304421dfb22d83ef13d416aa44c9f56e8a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57940
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds the initial support for Slippy's battery. The data I have is
unclear and incomplete, so this is NOT the final form. It seems to work
right now, and hasn't caught fire or anything, but it will need futher
tweaks.
BUG=chrome-os-partner:19976
BRANCH=none
TEST=manual (and watch it!)
Connect the EC console and watch what happens. You should see the battery
charging, discharging, etc. Keep an eye on it, though, and never leave it
unattended when on AC - we don't have the full data sheets available yet.
Change-Id: Id9bf93dc04a1399a9cdbc2156b3fac74be62038f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57814
Reviewed-by: Randall Spangler <rspangler@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
The WAKE# pin was being driven low when the power button was
pressed and no other events were occuring. This causes a PCIE
wake event to be observed on the host. This is incorrect. Therefore
only assert the WAKE# pin when any other event but the power button
has occured.
The implementation introduces a board-specific callback,
board_process_wake_events(), which handles the specific logic
for the wake events.
BUG=chrome-os-partner:19810
BRANCH=None
TEST=Manual. Both power button wakeup and lid events were tested. The
presence of PCIE Wake no longer exists for S5->S0 transitions.
Change-Id: If1311ccc36629b04d2d9e021c3e103e379836a3a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56970
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The firmware defines had two almost-identical sets. Coalesce into one
consistent set.
Link had 256 KB flash, but only allowed 2 80KB images. Future
LM4-based platforms (slippy/peppy/falco/etc) will now use the entire
flash, with RO=124KB, pstate=4KB, RW=128KB. This matches what the
STM32 platforms do, where pstate is contiguous with the RO firmware.
No functional change to STM32-based platforms.
BUG=chrome-os-partner:19176
BRANCH=none
TEST=build all platforms and dump_fmap ec.bin.
- stm32-based platforms should report RO=61440@0, RW=65536@0x10000
- link should report RO=81920@0, RW=81920@0x14000
- slippy should report RO=129024@0, RW=131072@0x20000
Change-Id: I20b1d95c16250d9a5d228ead06eef03d96548823
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56655
Haswell devices have EC control of the WWAN power rail.
Expose a new wireless switch enable flag for this under
the existing wirless enable command.
This change also abstracts the wireless enable function
to call a per-board handler so the different boards can
do the right thing based on their GPIO setup.
The haswell boards will switch WLAN radio and WWAN power
rails based on the switch inputs. These boards do not have
EC control of bluetooth radio/rail power.
WLAN (power and radio) still defaults to enabled. Disabling
with ectool will turn off the radio but keep the power enabled
in order to prevent the PCIe device from disappearing.
WWAN (power) still defaults to disabled. Disabling with
ectool will turn off the power rail.
BUG=chrome-os-partner:19871
BRANCH=none
TEST=manual: boot on slippy
DEFAULT:
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 1
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 0
ENABLE WWAN:
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_lte_en
GPIO pp3300_lte_en = 1
DISABLE WLAN (radio):
> ectool wireless 0x7
Success.
> ectool gpioget pp3300_wlan_en
GPIO pp3300_wlan_en = 1
> ectool gpioget wlan_off_l
GPIO wlan_off_l = 0
Change-Id: I6f760b8cf5ab47d8f7f0dd8cd4d3e6563464043e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57215
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This enables ASSERT() for easier debugging.
BUG=chrome-os-partner:19235
TEST=Add ASSERT(0) in lid_sw test and see error message:
ASSERTION FAIL: test/lid_sw.c:91:run_test - 0
BRANCH=None
Change-Id: I7df7d5984e5d787fdc5ad2b6b24fec669e95c97e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56691
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Falco / Peppy EC builds were previously broken because the board
creation came after I502ab033c3eb36661cc3ee97320874b3fbf6fc0d was put up
for review, but before it landed. Apply the same changes as slippy board
to fix the build.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=emerge-{falco/peppy} chromeos-ec
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7299343835ef8d08c6a2d2c7b4f797dc968a15d7
Reviewed-on: https://gerrit.chromium.org/gerrit/56668
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
This change copies the slippy board configuration as a starting
point for peppy. This change is essentially the same as
https://gerrit.chromium.org/gerrit/55820
BUG=chrome-os-partner:19640
BRANCH=none
TEST=manual
Tested on slippy as there are no peppy-specific changes yet.
cros_workon --board peppy start chromeos-ec
emerge-peppy chromeos-ec
~/trunk/src/platform/ec/util/flash_ec --board peppy
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I4c5f7a77fa55a6364effe838f7a656d56bfad9fb
Reviewed-on: https://gerrit.chromium.org/gerrit/56332
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
Write protect signal naming is now consistent across boards.
New CONFIG_WP_ACTIVE_HIGH is present on systems where the write
protect signal is active-high (e.g. Link). This will be used in the
next CL, which moves flash_get_protect() to flash_common.c
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo properly reports WP signal status
Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56087
Reviewed-by: Vic Yang <victoryang@chromium.org>
The gpio pin used for RCIN# should be configured as open drain as the
rail is pulled up by a non-EC rail. Driving it high would leak power.
The current GPIO_HI_Z macro uses GPIO_HIGH as the default state.
However, it has been found that this actually drives the pin to ground.
It is still unclear how Link works or doesn't.
BUG=chrome-os-partner:19355
BRANCH=none
TEST=manual: boot on slippy without RCIN# causing reset and
the 'apreset warm' EC command works as expected.
Change-Id: I71425075f8d77b3d7e576a59fc24f823790e2655
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56269
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This change just copies slippy and tweaks a few things that were
slippy-specific instead of not-link-specific (there are still bugs
open for those things).
BUG=chrome-os-partner:18788
BRANCH=none
TEST=manual
Since there are no Falco-specific changes yet (just slippy with another
name), I can try it on Slippy:
cros_workon --board falco start chromeos-ec
emerge-falco chromeos-ec
~/trunk/src/platform/ec/util/flash_ec --board falco
I also built and tested Link EC, to make sure nothing broke there either.
Change-Id: I9b3682032bd51adab4450520dfe52e3036750ef9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/55820
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Daisy doesn't have a write protect signal, so emulate it as a fake
signal which is always low; this maintains the current behavior on
daisy.
BUG=chrome-os-partner:15613
BRANCH=none
TEST=flashinfo shows gpio not asserted
then short across the WP screw and flashinfo shows it asserted
Change-Id: I329424efe1c3b065976e17395e2bf9588cdce88c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51500
Reviewed-by: Vic Yang <victoryang@chromium.org>
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>
The current lm4 pwm module was using board-specific
pins during this configuration. Move the implementation
of configure_fan_gpios() to the board-specific files
so that the pin configuration policy isn't a part of the
common infrastructure.
BUG=chrome-os-partner:19504
BRANCH=none
TEST=successfully booted slippy with backlight turning on in OS.
Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51471
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When system is locked, the console is disabled. However, we need console
for debugging and testing. This CL uses a bit from back-up register to
indicate if the console should always be enabled. (This bit is currently
used by fake WP, which is removed in this CL.) With this, we can set
this bit with console command 'forceen 1' to ensure console is never
disabled.
To prevent device shipped in this state, the chip name is postfixed with
'-unsafe' so that the device is not able to pass HWID check.
BUG=chrome-os-partner:19293
TEST=Manual
BRANCH=spring
Change-Id: I88556e973ca542c1bdc27ba64988718291e01a26
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The PROCPWRGD signal is not well documented. It's not known if
it is an input or an output. Emperically it was discovered that
driving this pin during the resume path causes resume to fail.
Therefore, ignore the pin by setting it to an input.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transition from S0 to S3 and back to S0
Change-Id: I55dc16c75c286af06806e2513197f0bb2c7b9d04
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51358
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Still some work to do here but this now works.
NOTE: This makes the system behave like a normal
cros device where the power is applied automatically.
For some (other, unknown) reason the "reboot ap-off"
is not passing flags correctly to keep it off.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transition from G3 to S0
Change-Id: I694136b9611e18ac8fb7b1e960bd10caa258ce28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51077
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The recovery pin input from servo is open drain and needs
an internal pullup enabled so it is not always low.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=manual: ensure rec_mode can be turned off
$ dut-control rec_mode:off rec_mode
rec_mode:off
Change-Id: I387a53eb5b64bb0bf3a87fc47b5cca9b2063f6a9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50993
Slippy uses UART2 instead of UART1 and so the EC needs
to be able to tolerate having the host use a different
interface. There are of course many ways to accomplish
that but this approach adds two config variables to specify
the host uart and the host uart irq.
The UART port setup is split out to allow them to be
configured separately rather than needing to be adjacent
in a for loop.
The interrupt functions were renamed (to ec and host) in
order to indicate which interface they are responsible for.
BUG=chrome-os-partner:19356
BRANCH=none
TEST=boot slippy and see host serial output
Change-Id: I1913ff3d650f329224c9654eee7bb7412fae5402
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50837
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>
This is causing the host to reset because this pin is
going low when it is left as open drain, despite having
a 3.3V pullup.
BUG=chrome-os-partner:19355
BRANCH=none
TEST=manual: boot on slippy without RCIN# causing reset
Change-Id: I59e9316e85ce618edc84c7dd988d70ea4de1e71a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50836
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
This is the first version of pthread-based RTOS emulator. With this, we
will be able to test high-level modules entirely on the host machine.
BUG=chrome-os-partner:19325
TEST='make runtests' and see tests passing.
BRANCH=None
Change-Id: I1f5fcd76aa84bdb46c7d35c5e60ae5d92fd3a319
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This specifies the Slippy GPIOs. Because the power controls are completely
different from Link, we have to gut the power sequencing task to do nothing.
For bringup and test, we'll just manually set and get the GPIOs until we
know exactly what we need to do.
This is where the fun starts...
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Built everything, Link still works.
Change-Id: Ic1ce1d4085298f49dd98d99e81e04835eca5f11c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50004
Temp sensors, I2C devices, ADC inputs, and keyboard GPIOs are all different.
This removes the things we don't need, connecting some of the things we
will.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=none
Doesn't break Link.
Change-Id: Ifb9775d921f6e9952497bffa98d405353ed4df71
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49964
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Also renaming to avoid confusion as to what's being charged.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Build everything, Link still works.
Change-Id: I4205a1210c7dfe57cfbbdd740970ef57e6a011b8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49775
Reviewed-by: Randall Spangler <rspangler@chromium.org>
