summaryrefslogtreecommitdiff
path: root/power/rockchip.c
Commit message (Collapse)AuthorAgeFilesLines
* power: Rename rockchip to rk3288Nicolas Boichat2018-06-071-570/+0
| | | | | | | | | | | | | Get rid of a TODO. BRANCH=none BUG=b:35569119 TEST=make buildall -j Change-Id: Ia918c90519220a348f8c65b6b6f14b6d3129a63a Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1090523 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Code cleanup: Remove cold reset logicVijay Hiremath2018-04-031-17/+8
| | | | | | | | | | | | | | | | | | | | | Majority of the chipsets do not have a dedicated GPIO to trigger AP cold reset. Current code either ignores cold reset or does a warm reset instead or have a work around to put AP in S5 and then bring back to S0. In order to avoid the confusion, removed the cold reset logic and only apreset is used hence forth. BUG=b:72426192 BRANCH=none TEST=make buildall -j Manually tested on GLKRVP, apreset EC command can reset AP. Change-Id: Ie32d34f2f327ff1b61b32a4d874250dce024cf35 Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com> Reviewed-on: https://chromium-review.googlesource.com/991052 Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com> Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cleanup: DECLARE_CONSOLE_COMMAND only needs 4 argsBill Richardson2016-08-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gaia, mediatek, rockchip, tegra: No more disabling key scanning in power filesDouglas Anderson2016-02-181-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 29d25d807c18 ("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
* oak: enable MBKP events for PD eventsBen Lok2015-08-311-2/+2
| | | | | | | | | | | | | | | | | | | (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>
* Power Button: Wait for power button to be stable when waiting for releaseAlexandru M Stan2015-02-101-33/+4
| | | | | | | | | | | | | | | | | | 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>
* Veyron: remove the pmic reset in power_onChris Zhong2015-01-301-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Rockchip: Wait till we actually power down in power_off()Alexandru M Stan2015-01-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Veyron: cancel the long press timer when lost power_goodChris Zhong2014-12-291-5/+9
| | | | | | | | | | | | | | | | 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>
* Jerry: modify gpio config, hibernateChris Zhong2014-11-131-14/+0
| | | | | | | | | | | | | | | | | | | 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
* Pinky: Reoganize power on sequencingAlexandru M Stan2014-10-211-28/+18
| | | | | | | | | | | | | | | | | | 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>
* Veyron: power on 5v drv for pinky-rev2Chris Zhong2014-10-021-0/+13
| | | | | | | | | | | | | | | EC need to enable 5v_drv when power on AP, disable it when power off AP. BUG=None TEST=USB host works well BRANCH=None Change-Id: Ie18679a5a2d3c676daf0af4da599fa010d98161d Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/220162 Reviewed-by: Alexandru Stan <amstan@chromium.org> Tested-by: Alexandru Stan <amstan@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org>
* Veyron: Fix warm-reset commentAlexandru M Stan2014-09-131-1/+1
| | | | | | | | | | BUG=None TEST=None, no code changes BRANCH=None Change-Id: Ie5675938c918d0f79779bf46557aff1074f49512 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/217882
* Veyron: Fix leakage power before AP runningChris Zhong2014-09-131-3/+0
| | | | | | | | | | | | | | | | | EC needs to ensure EC_INT & SPI_CS are in input state or output low, Before AP on. Otherwise it will cause leakage to AP, and power_on timing is incorrect. BUG=None TEST=power_on timing is correct. BRANCH=None Change-Id: I2dc9c35b4782e4f5c138b31944af21d8248215cd Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/217691 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Alexandru Stan <amstan@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org> Tested-by: Alexandru Stan <amstan@chromium.org>
* Veyron: Change PWREN to PWRONChris Zhong2014-09-131-10/+8
| | | | | | | | | | | | | | | | 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>
* Veyron: Reset the PMIC properly at power onAlexandru M Stan2014-09-041-35/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Veyron: Add a time_cancel in power button releasezyw2014-08-291-0/+1
| | | | | | | | | | | | | | | | | A cancel is needed when power button is release before timeout BUG=None TEST=When in S3/S0, hold the power button for 8 seconds; the system should shutdown. And release button before that, It's normal. BRANCH=None Change-Id: I1baf3a80d7b6349d2e10eb1f7ea9795ee73fb487 Signed-off-by: zyw <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/214750 Reviewed-by: Alexandru Stan <amstan@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Alexandru Stan <amstan@chromium.org> Tested-by: Alexandru Stan <amstan@chromium.org>
* Veyron: Removing some stale tegra codeAlexandru M Stan2014-08-211-20/+2
| | | | | | | | | | | | | | There's no point in having these delays, they're not applicable to Veyron. BUG=None TEST=Everything should work the same. BRANCH=None Change-Id: Icc2aebae1a497dd4f46579c23e36750feca6d67a Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/213248 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Veyron: Fix force power-offAlexandru M Stan2014-08-201-2/+4
| | | | | | | | | | | | | | 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>
* Veyron: Fix power signalsAlexandru M Stan2014-08-201-25/+14
| | | | | | | | | | | | | | | | | | | | 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>
* veyron: Change EC_INT pin to high-Z in S5Chris Zhong2014-08-061-1/+4
| | | | | | | | | | | | | | | | Change EC_INT pin to high-Z to reduce power draw in S5, and reset it to output High in S5S3. BUG=None TEST=Leakage did not happen, other functions also work correctly. BRANCH=None Change-Id: Id77bb9f34f25336cd097344be349f5aa43a75b52 Signed-off-by: Chris Zhong <zyw@rock-chips.com> Reviewed-on: https://chromium-review.googlesource.com/210545 Reviewed-by: Alexandru Stan <amstan@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* veyron: fixed SUSPEND_L lineAlexandru M Stan2014-07-261-1/+2
| | | | | | | | | | | | | | | 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>
* veyron: renamed PMIC_THERM_H -> PMIC_SOURCE_PWR_HAlexandru M Stan2014-07-251-1/+1
| | | | | | | | | | | | | | It is now the proper name. BUG=None TEST=None, only name changed. EC should work as expected still. BRANCH=None Change-Id: Ia63db6fa0dc41750ebf31423c9870f8a463bf392 Signed-off-by: Alexandru M Stan <amstan@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/209814 Reviewed-by: Chris Zhong <zyw@rock-chips.com> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* veyron: Modify board configzyw2014-07-231-0/+635
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>
View Lorry Controller Status