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>
Problems with existing thermal control loop:
* Not multi-board friendly. thermal.c only supports Link and needs
refactoring. Temp thresholds and fan speeds are hard-coded.
* Only the PECI temp is used to determine the fan speed. Other temp sensors
are ignored.
* Has confusing data structures. Values in the CPU temp thresholds array mix
ACPI thresholds with fan step values.
With this change, the thermal task monitors all temp sensors in order to
perform two completely independent functions:
Function one: Determine if the host needs to be throttled by or informed of
any thermal events.
For thermal events, each temp sensor will have three threshold levels.
TEMP_HOST_WARN
* When any sensor goes above this level, host_throttle_cpu(1) will be called
to ask the CPU to slow itself down.
* When all sensors drop below this level, host_throttle_cpu(0) will be called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_HIGH
* When any sensor goes above this level, chipset_throttle_cpu(1) will be
called to slow the CPU down whether it wants to or not.
* When all sensors drop below this level, chipset_throttle_cpu(0) will be
called.
* Exactly AT this level, nothing happens (this provides hysteresis).
TEMP_HOST_SHUTDOWN
* When any sensor is above this level, chipset_force_shutdown() will be
called to halt the CPU.
* Nothing turns the CPU back on again - the user just has to wait for things
to cool off. Pressing the power button too soon will just trigger shutdown
again as soon as the EC can read the host temp.
Function two: Determine the amount of fan cooling needed
For fan cooling, each temp sensor will have two levels.
TEMP_FAN_OFF
* At or below this temperature, no active cooling is needed.
TEMP_FAN_MAX
* At or above this temperature, active cooling should be running at maximum.
The highest level of all temp sensors will be used to request the amount of
active cooling needed. The function pwm_fan_percent_to_rpm() is invoked to
convert the amount of cooling to the target fan RPM.
The default pwm_fan_percent_to_rpm() function converts smoothly between the
configured CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX for percentages
between 1 and 100. 0% means "off".
The default function probably provide the smoothest and quietest behavior,
but individual boards can provide their own pwm_fan_percent_to_rpm() to
implement whatever curves, hysteresis, feedback, or other hackery they wish.
BUG=chrome-os-partner:20805
BRANCH=none
TEST=manual
Compile-time test with
make BOARD=falco runtests
On the EC console, the existing fan commands should work correctly:
faninfo - display the fan state
fanduty NUM - force the fan PWM to the specified percentage (0-100)
fanset RPM - force the fan to the specified RPM
fanset NUM% - force the fan to the specified percentage (0-100) between
its configured minimum and maximum speeds from board.h
(CONFIG_PWM_FAN_RPM_MIN and CONFIG_PWM_FAN_RPM_MAX)
fanauto - let the EC control the fan automatically
You can test the default pwm_fan_percent_to_rpm() with
fanset 1%
faninfo
The fan should be turning at CONFIG_PWM_FAN_RPM_MIN. Let the EC control it
automatically again with
fanauto
Also on the EC console, the thermal settings can be examined or changed:
> temps
PECI : 327 K = 54 C
ECInternal : 320 K = 47 C
G781Internal : 319 K = 46 C
G781External : 318 K = 45 C
>
> thermalget
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 0 0 0 G781Internal
3 0 0 0 0 0 G781External
>
> help thermalset
Usage: thermalset sensor warn [high [shutdown [fan_off [fan_max]]]]
set thermal parameters (-1 to skip)
>
> thermalset 2 -1 -1 999
sensor warn high shutdown fan_off fan_max name
0 373 387 383 333 363 PECI
1 0 0 0 0 0 ECInternal
2 0 0 999 0 0 G781Internal
3 0 0 0 0 0 G781External
>
From the host, ectool can be used to get and set these parameters with
nearly identical commands:
ectool thermalget
ectool thermalset 2 -1 -1 999
Change-Id: Idb27977278f766826045fb7d41929953ec6b1cca
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66688
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The BOOTCFG register configures a couple of important things: whether to
allow jumping into the builtin ROM bootloader at reset, and whether or not
to allow JTAG access for programing and debugging.
The default is "no" and "yes". But the BOOTCFG register can be locked so
that it can't be changed again, which means that if the wrong values are put
into it, the system is pretty much bricked.
On Link, we wrote a BOOTCFG value that allowed a GPIO to be used as a bypass
to optionally trigger the ROM bootloader, but on Slippy and its derivatives
that GPIO is not pulled up. If you program the Link values into BOOTCFG on a
Slippy, the system is stuck in the ROM bootloader more or less forever.
This change disables that GPIO, keeps JTAG enabled, and locks those settings
for all LM4 chips (it's a chip config now, not a board config). We've never
actually used the GPIO to invoke the ROM bootloader, but we have managed to
brick a number of systems just by having it enabled, so we're going to lock
it into a safe configuration now.
BUG=chrome-os-partner:19247
BRANCH=falco,peppy
TEST=manual
Reflash, boot, power cycle (actually unplug the EC from AC and battery) a
few times. It should continue to work.
Change-Id: Iaf1a81d6814104421a56425490e3d5164ea9b617
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66538
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Randall Spangler <rspangler@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
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>
Add a CONFIG_CHIPSET_X86 option that determines if
chipset_x86_common.o is built.
BUG=chrome-os-partner:20372
BRANCH=None
TEST=built bolt and link. All other boards should be covered.
Change-Id: I980a8fc68a31162b920429e695631909c5f6a4db
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63208
Reviewed-by: Randall Spangler <rspangler@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.
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
These are now described in config.h. The various BQ chargers now also
use a consistent naming for their sense resistor options.
No functional changes, just renaming, and removal of obsolete
never-defined configs.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: Ie274546fe45f5ffc6fd0f26096c4622805baf8a0
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62540
BUG=chrome-os-partner:21180
BRANCH=slippy
TEST=Run ectool chargecontrol command with each option (normal,
idle, discharge) on Slippy. Verifiy battery is discharging
in discharge mode via EC console 'battery' command.
Signed-off-by: Dave Parker <dparker@chromium.org>
Change-Id: I0461b20fc15c99380327b9a282efff7f1ed93baf
Reviewed-on: https://gerrit.chromium.org/gerrit/62851
This lets us read the internal and external values on the
G781 temp sensor.
BUG=chrome-os-partner:21180
BRANCH=slippy
TEST=run ec 'temps' command on Slippy.
Change-Id: Ib3a2a89efd4cfbc4a49696c79daa37bc1880a3ef
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/62847
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Power button logic is common across all platforms and is not
LM4-specific, so move it to its own module. Switch.c will eventually
be moving to common/ and will common across all platforms (not just
x86), and splitting out the x86 power button logic is needed before
that too.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=manual
1) power on system with both lid and power button.
2) power+refresh -> reboots
3) power+refresh+esc -> recovery mode
4) power+refresh+downarrow -> reboots, AP stays off
5) toggling recovery GPIO via servo should generate SW debug output
showing bit 0x10 toggling
Change-Id: I07714e2c035dceece66f90407983397d2697e7d5
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61780
These were briefly used on link, and are not used by any other
platform. The values for those platforms are almost certainly wrong,
and incorrect information is worse than no information.
This does not remove reading the stuffing resistors - it just removes
the assumption that they map to PROTO1 and EVT.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=compile all platforms
Change-Id: I2ba19fd52660559bfd1d8e3b8a9949e9b8abbddf
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61929
Chipset control of wireless power uses the new API instead of overriding
the wireless power itself.
Refactor board-specific support for it to just a few config #defines
instead of board-specific functions. This makes some assumptions
about the polarity of the enable signals. Not making those
assumptions would require defining an array of structs or some other
heavier-weight board-specific info. Since the assumptions hold for
all current boards, let's make them now because this is a step in the
right direction, and reserve doing something more general until we
actually have a use case for it (so we build in just the flexibility
we need).
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms; see that link wifi turns on at boot and off at
shutdown (verify via 'gpioget' from EC console)
Change-Id: Ic036e76158198d2d5e3dd244c3c7b9b1e8d62982
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61608
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This code is not LM4-specific, it's x86-specific. So it doesn't
belong in chip/lm4. Put it in its own module rather than leaving it
in switch.c, since some x86 systems may need the power button state
machine but not the backlight-enable passthru.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=Quickly run a magnet over the lid switch; the backlight goes off and then
back on.
Change-Id: I72f7139b73f91539dcfbe6b5cb6d56587ab66fde
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61595
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This moves most of the code into a common module, leaving only the
board-specific GPIOs (now listed in a struct in board.c) and the
chipset-specific state machine with multiple copies.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=boot link; verify suspend and resume work; shut back down and see
it go to G3 after 10 sec.
Change-Id: Iafa8ba55a4870bb0119ff4161a1a9054fcc7955f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60949
Rather than implementing board version only for Link, implement for each
board which has version strapping.
BUG=chrome-os-partner:20295.
TEST=Manual. Run "ver" command on Peppy, verify correct board version is
returned.
BRANCH=None.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I57656a645c6bcd1fdb2e7e4aba91b4ec4b8ad8ec
Reviewed-on: https://gerrit.chromium.org/gerrit/61186
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
This gets rid of mystery files like "ir357x" and "lp5562". All chip
names are now prefixed with their module type (e.g. "chipset_",
"led_driver_", etc.)
No functional changes; renaming files and CONFIG constants only.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms
Change-Id: I3227fb0f6b0243bb08a13577cdb0f6def0e15d54
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60922
It's still unclear why the PL6 pin which is used
for RCIN_L does not behave properly when configured
as open drain. Work around the misbehavior by
configuring the PL6 pin as an input. When it is
required to be driven low the pin is reconfigured to
an output and subsequently made an input again.
This provides the open drain semantics that are
required to eliminate leakage.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20054
BUG=chrome-os-partner:20173
BUG=chrome-os-partner:20175
BRANCH=None
TEST=manual
'apreset warm' causes reset as expected. The pin is
configured as an input by default without open drain
or a pullup resistor:
> rw 0x40062400 (GPIODIR)
read 0x40062400 = 0x00000000
> rw 0x4006250c (GPIOODR)
read 0x4006250c = 0x00000000
> rw 0x40062510 (GPIOPUR)
read 0x40062510 = 0x00000000
Change-Id: Ia3ad6fa7fec06be1cbff6854d9341722d8617408
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60780
Reviewed-by: Sameer Nanda <snanda@chromium.org>
The LPC_CLKRUN_L signal on these boards has an external pull
up to the correct PCH rail. Therefore, configure the pin
controlling LPC_CLKRUN_L as open drain.
BUG=chrome-os-partner:19811
BUG=chrome-os-partner:20331
BRANCH=None
TEST=Built and flashed. Interrogated GPIOODR register for port M:
> rw 0x4006350c
read 0x4006350c = 0x00000004
Change-Id: I50dc90d784bd1d1f318b401e5d7d6e06bf0f1e47
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/59416
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
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 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>
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>
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>
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>
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>
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
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
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>
