Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In http://crosreview.com/28402 code was added to power/gaia.c that
disabled keyboard scanning if the power button was pressed. The
purpose, according to that change, was to prevent accidental reboots by
pressing the power button together with another key that wasn't the
"Refresh" key (specifically: LCtrl, Tab, Reload, t, [, ], y, Dim Screen
and Mute).
At the time the original code was added, there was already code in the
power button interrupt handler to accomplish the same purpose: see
commit 29d25d807c ("Keyboard scan must stop driving columns when power
button is pressed."). It's unclear if the code in the interrupt handler
didn't work or if there was some other bug with it. ...or if perhaps
the changes in "gaia/power.c" weren't actually needed and the important
part of the original change was the mutex added to the scanning task.
In any case, current testing indicates that the code in power/gaia.c,
power/rockchip.c, and power/tegra.c isn't needed anymore. I ran through
the test sequence described in the original CL on my veyron_jerry and I
don't see any accidental reboots.
It's also instructive to note that only ARM boards (all presumably
copied from gaia) have this extra code. Presumably if the code was
actually needed then x86 boards would also need it.
In any case, let's remove it. It's suspected that there's some crazy
race where the disable in power/rockchip.c is overriding the enable in
the main power key handling code and leaving the keyboard disabled.
BRANCH=None
BUG=chrome-os-partner:48470
TEST=Same test as CL:28402
Change-Id: I6d21167ce3d773c9616abd4a728247a1934b96d6
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/327843
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit dfae7e7ad45f4ce0e8f820caaa05a8754bba0250)
Reviewed-on: https://chromium-review.googlesource.com/328013
(refer to CL:273620) enable the MKBP event feature to send host event
and wire up the PD specific events.
But, CONFIG_MKBP_EVENT conflicts with CONFIG_KEYBOARD_PROTOCOL_MKBP,
due to the GPIO name of EC interrupt pin. Align the GPIO naming of EC
interrupt pin to EC_INT_L.
BRANCH=none
BUG=chrome-os-partner:44643
TEST=On Oak rev3, plug/unplug USB devices and add kernel trace to see
the PD events happening.
Change-Id: I10de9c6611583bb6165bdc1848e542d4b8bba954
Signed-off-by: Ben Lok <ben.lok@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/296012
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
The debounce timer might be too slow to actually update the state of
debounced_power_pressed by the time we do power_button_is_pressed in the S3->S5
state transition. Solution is to move the power_button_wait_for_release function
here and make sure there are no deferreds active.
BUG=chrome-os-partner:35948
TEST=During dev mode screen, press power button, note the device stays off
TEST=Print debounced_power_pressed in power_button_is_pressed(void), note it's
not 0 when power button is actually pressed
BRANCH=veyron
Change-Id: I8258e9e5524bd65d6ea9c77ea5649304d2195bf0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244590
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Alex did the reset workaround in power_on function.
<https://chromium-review.googlesource.com/#/c/214360/>
Now, the new version RK808 has fixed this issue, so we needn't this
workaround.
BUG=chrome-os-partner:35976
BRANCH=veyron
TEST=The BUCK1_ON_VSEL register default value is 0x18, and coreboot and
kernel will change this register to other value, but never set 0x18 to
it. So we can read this register in coreboot and print out to console to
check whether the RK808 reset to default after cold reboot. With this
patch, the value always reset to 0x18. I have test on jerry, mighty,
speedy.
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Power up system: it should power back up
TEST=Use "i2cset -f -y 0 0x1b 0x21 0x0f"
Press refresh-power: system should reboot
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Shut down and power back up.
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
TEST=Use "i2cset -f -y 0 0x1b 0x2a 0x00"
Press refresh-power: system should reboot
Use "i2cget -f -y 0 0x1b 0x2a". Confirm back to 0xff.
Change-Id: Icfdd3a7eeadce2c597bf286b36bea0aa58cfe4c4
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243202
Reviewed-by: Douglas Anderson <dianders@chromium.org>
If we don't do this, some code later on (like the S3 hook) might check the
POWER_GOOD too early, note that it's on and move to the wrong state:
[8.457344 power button not released in time]
[8.457541 long-press button, shutdown]
// power_off() happens:
[8.459853 power shutdown complete]
[8.593443 power state 7 = S0->S3, in 0x0001]
[8.593653 power state 2 = S3, in 0x0001]
// power_get_signals check happens here ^^^, but POWER_GOOD did not have enough
// time to fall and cause the power_update_signals interrupt
[8.593863 power state 6 = S3->S0, in 0x0001]
[8.594132 power state 3 = S0, in 0x0000]
// system is actually off here
BUG=chrome-os-partner:34816
TEST=Hold Power+Refresh, release after about 10 seconds, the ec should not
have an assertion error and reboot
BRANCH=veyron
Change-Id: Ic7a06a5d255f2b8d056b0b454fc32a4c05c998b4
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242620
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 5f954620fa3d36e8e1a88bf7d3963dc7996ec445)
Reviewed-on: https://chromium-review.googlesource.com/242711
if power good is lost and the power button still press, we need cancel the long
press timer, otherwise EC will crash.
BUG=chrome-os-partner:34816
TEST=press power button during coreboot, and it can shutdown normally
BRANCH=None
Change-Id: Ia27c83137451abacce9d544741bbbe5787983215
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/237294
Reviewed-by: Jiazi Yang <Tomato_Yang@asus.com>
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Commit-Queue: Eddie Cai <eddie.cai8848@gmail.com>
Added hibernate wakeup pin(EC_WAKE) that covers both AC_PRESENT and LID_OPEN. It pulses a
rising edge when either of them have a rising edge.
The power button was also inverted to handle hibernation better, now it's low
except when pressed it temporarly goes high.
BRANCH=None
BUG=chrome-os-partner:33269 chrome-os-partner:32782
TEST=make BOARD=jerry
Try hibernating, all wakeup sources should work, it shouldn't stay hibernated.
All signals(AC, lid, power button) should work equally well as in pinky.
Change-Id: I894135bdfd5600919296f7510dc9cd1acd567ddc
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/228763
This is the first step to fix a leak when powering up the system.
Some stuff should wait till after the rails are up.
The SPI timeout was removed because there's a simpler way to determine this:
SPI is only ready when the AP goes from S3->S0
BUG=chrome-os-partner:32824
BRANCH=None
TEST=Pinky powers on
Change-Id: Ia4281f54f7735d4efe2bc3e8ba1e462fccc51fd0
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222632
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The PWRON signal is actually a pulse that's only supposed to happen at the S0->S5
transition. We can release it when we see POWER_ON.
BUG=None
TEST=Power on and power off normally. "halt" makes the system go to S5 instead
of rebooting.
BRANCH=None
Change-Id: I14f1cc83c8a4a89226574cf605823d247ce9508a
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There was a way to brick the PMIC by programming its registers with a bad
configuration, this could prevent the AP from powering up properly (thus not
being able to unbrick it). The PMIC retains register state through S5 (presumably
due to RTC business) and they do not get reset at bootup unless the OTP reset is
asserted.
The OTP reset actually has to be asserted in a special(rather long as well)
sequence.
A bug was discovered while making this change(crosbug.com/p/31635): usleep does
not work for long delays. Since I needed at least 300ms on one of the delays I
used a workaround with a loop.
I also cleaned up some old tegra stuff and renamed things to be more semantic.
BUG=None
BRANCH=None
TEST=From the AP set a PMIC register from the default value of 0x7d to 0xfd:
user@ap~$ modprobe i2c-dev
user@ap~$ i2cget -f -y 0 0x1b 0x24
Check what the default state is, mine was 0x7d
user@ap~$ i2cset -f -y 0 0x1b 0x24 0xfd #or change 0xfd to something!=default
Cold reboot the dut("apreset" or "power on\npower off" will work) then check if
the PMIC registers got reset:
user@ap~$ modprobe i2c-dev
user@ap~$ i2cget -f -y 0 0x1b 0x24
0x7d(or whatever your default state was) #good
0xfd #bad, did not reset properly
Using "user@ap~$ i2cset -f -y 0 0x1b 0x24 0x00" instead will prove the bricking
of the PMIC/AP.
Change-Id: Iad96781ffde085befe6dea20edd255ca3e7e1357
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214360
Reviewed-by: Doug Anderson <dianders@chromium.org>
I readded the code that armed the power_off_deadline. The force power-off should
be controlled fully from the EC now.
BUG=None
TEST=When in S3/S0, hold the power button for 8 seconds; the system should shutdown.
BRANCH=None
Change-Id: I848ce6757e497c15296aa4eae9c05133950b4e45
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213249
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Seems that we were driving GPIO_PMIC_PWRON_H backwards. The only reason it
worked before is because of a stale feature from tegra which pretty much kept it
always disabled(enabled in our case due to _L).
Also removed old power signals and renamed signals so they're more semantic and
respect convention(no _H).
BUG=None
TEST=AP should boot as normal, gpioget will show both PMIC_*PWR* pins 0 when
system off and 1 when system is on. The system will also use 8mA less now
(no more current leak into the PMIC).
BRANCH=None
Change-Id: I81b7596cb39a5c2b45d53e05478396b91040cacf
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213246
Reviewed-by: Yung-chieh Lo <yjlou@chromium.org>
Pulled down line so it's not so erratic.
Fixes the issue where the EC doesn't know what state the AP is in.
BUG=None
TEST=EC should report S0 correctly(not S3 all the time). `power on` and
`power off` will also work correctly(instead of doing absolutelly nothing).
BRANCH=None
Change-Id: I69bd17b39d2bd8f7f0456c4babc4ad9f8f34c8bd
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209668
Reviewed-by: Chris Zhong <zyw@rock-chips.com>
This patch is base on new hardware board, veyron has not some stuff,
such as power led, charge en
BUG=None
TEST=Read log with servo board, it has reponse when type some commends
BRANCH=None
Change-Id: I45502fd1278f69db5e46fc9ab1deaee02fc8708f
Signed-off-by: zyw <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/209231
Reviewed-by: Alexandru Stan <amstan@google.com>
Commit-Queue: Alexandru Stan <amstan@google.com>
Tested-by: Alexandru Stan <amstan@google.com>
