On some boards, the boot key combinations do not make a lot of
sense, so we can just not process them and save a little bit
of code space.
BRANCH=none
BUG=b:37422577
TEST=Flash hammer
TEST=make newsizes shows we save 156 bytes in hammer RW.
Change-Id: Ic96d7ed1dbee10f44f8b08568ab70b2f20961842
Reviewed-on: https://chromium-review.googlesource.com/495968
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On some boards, the special alt-volup-r/h combinations do not make
a lot of sense, so we can just not process them and save a little
bit of code space.
BRANCH=none
BUG=b:37422577
TEST=Flash hammer, alt-volup-r/h does not do anything special
TEST=make newsizes shows we save 124 bytes in hammer RW.
Change-Id: I92770fd6b8ff90780162a6b1de428a550bb44e9b
Reviewed-on: https://chromium-review.googlesource.com/495967
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch clears the typematic buffer when disabling keyboard scan.
When the device goes to tablet mode with a key being pressed, this
should prevent keyboard_protocol_task from sending scan codes to the
host.
BUG=b:35585725
BRANCH=none
TEST=make buildall. Tested on Electro.
Change-Id: I73e9d2948b472458814967307412aebeb410ff2e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/425075
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some functions are only defined if CONFIG_HOSTCMD_EVENTS is set,
leading to link-time failures.
In particular, do not call these functions from keyboard_scan,
and do not define PD host event commands if the configuration
option is not set.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
Change-Id: I0da31cdec08f86f148aa883698a44f462de46d8e
Reviewed-on: https://chromium-review.googlesource.com/410923
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds new key combination (Left_Shift+Esc+Refresh+Power) that triggers
recovery mode by setting a new host event
EC_HOST_EVENT_KEYBOARD_RECOVERY_HW_REINIT. This host event can be used
whenever user wants to request entry into recovery mode by
reinitializing all the hardware state (e.g. memory retraining).
BUG=chrome-os-partner:56643,chrome-os-partner:59352
BRANCH=None
TEST=Verified that device retrains memory in recovery mode
with (Left_Shift+Esc+Refresh+Power) on reef.
Change-Id: I2e08997acfd9e22270b8ce7a5b589cd5630645f8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407827
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
For certain board configurations, KSI2 will be stuck asserted for all
scan columns if the power button is held. We must be aware of this case
in order to correctly handle recovery mode key combinations.
BUG=chrome-os-partner:54602
BRANCH=None
TEST=Manual on gru. Do three-key salute, verify EC detects recovery mode.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I03d76e1121107484f79520745858388f6cae096c
Reviewed-on: https://chromium-review.googlesource.com/357590
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If the lid is initially closed, keyboard scan should be disabled.
BUG=chrome-os-partner:53566
BRANCH=none
TEST=Check ESC+Refresh+PwrBtn is detected.
Check keyscan is enabled if lid is open.
Check keyscan is disabled if lid is closed.
Check power button is functional if lid is opened.
Check power button is masked if lid is closed.
Change-Id: I2354a657d8bf0c13207517cc789547a68befd240
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/351534
Reviewed-by: Shawn N <shawnn@chromium.org>
This is keyboard test mechanism request for "multiple key press test",
we can thru the testing to scan out kso ksi pins shortting or keyboard has
multiple key pressing, below was the testing steps:
1. Turn off internal keyboard scan function.
2. Set all scan & sense pins to input and internal push up.
3. Set start one pin to output low.
4. check other pins status if any sense low level.
5. repeat step 3~4 for all keyboard KSO/KSI pins.
6. Turn on internal keyboard scan function.
BUG=chrome-os-partner:49235
BRANCH=ToT
TEST=manual
Short any KSO or KSI pins and excute "ectool kbfactorytest", it shows failed.
if no pins short together, it shows passed.
Change-Id: Id2c4310d45e892aebc6d2c0795db22eba5a30641
Signed-off-by: Devin Lu <Devin.Lu@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/332322
Reviewed-by: Shawn N <shawnn@chromium.org>
After commit 98ab7484d331 ("keyboard: prevent races enabling/disabling
kb scanning") kbpress was totally broken, which wasn't so good for
FAFT. Fix it by making sure we go into polling mode for simulated
keyboard presses.
BUG=chrome-os-partner:48849
TEST=kbpress works
Change-Id: Icd663c2ee7a184e6af4438368595087b35724a4f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/319586
Reviewed-by: Randall Spangler <rspangler@chromium.org>
keyboard_scan_enable() is called from several contexts. From a skim of
the code I found:
* keyboard_lid_change(), which is called from HOOK_LID_CHANGE
* enable_keyboard(), which is called from HOOK_CHIPSET_RESUME
* lidangle_keyscan_update(), which is called from motion_sense_task.
* check_for_power_off_event() which is called from power_handle_state()
which is called from chipset_task.
* power_button_interrupt(), which is an interrupt
* power_button_change_deferred(), which is a deferred function
So, ummm, it's probably not a good idea to do a read-modify-write of a
variable without any locking. ...and then to act on the resultant state
in various different contexts.
It's presumed that's just what happened to poor Julius. Julius found
himself in the unfortunate situation where he resumed his device (with
the power button, I believe) and that everything worked (including
reading the battery state and including the accelerometer) but the
keyboard didn't work. Now, it should be noted that Julius is a little
strange. Well, maybe he's not strange and maybe just the way he uses
his laptop is strange. He uses his veyron_minnie device as a smart
keyboard/trackpad. Said another way: it is in tablet mode but is docked
to an HDMI monitor, the screen is face flat on his table, and he uses
the builtin keyboard and trackpad. Nobody else that I know does this.
It's pretty darn cool, but I just don't think anyone else would think of
it. Anyway, that might have something to do with how he reproduced
this. ...or it might not. He does that a lot and hasn't seen the
problem before now.
Anyway, I managed to reproduce a number of problems similar to what poor
Julius saw by adding a 200ms sleep in keyboard_scan_enable() after we
read disable_scanning_mask but before we did anything to it (I skipped
the sleep if this happened to be one of those people who was calling
from interrupt).
Since there appears to be no spin_lock_irqsave() in the EC, let's just
have the EC use atomic operations to mess with its masks. Then we'll
leave all heavy lifting to the task.
This requires thinking through the task code a bit.
Conflicts:
common/keyboard_scan.c
...due to commit 6112f20679 ("common: keyboard_scan: Add items to
.bss.slow.") in ToT.
BRANCH=ToT
BUG=chrome-os-partner:48470
TEST=Poke a lot with power button and lid; NTF.
Change-Id: I61b906505100186b0ca2c48e7b1a7ffaaa8a7d3e
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/317896
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 98ab7484d331a78fced870b58b4d82e79e2e0f4e)
Reviewed-on: https://chromium-review.googlesource.com/318292
BUG=chrome-os-partner:46056
BUG=chrome-os-partner:46063
BRANCH=None
TEST=Enable CONFIG_REPLACE_LOADER_WITH_BSS_SLOW on GLaDOS. Build,
flash, and verify that AP and EC boot. Perform typing test with no jank
or other oddities.
TEST='sysjump rw' and repeat the typing test.
TEST=Hold down arrow down and issue 'reboot' command.
TEST=make -j buildall tests
CQ-DEPEND=CL:311209
Change-Id: I35911862af2a4e9feb795b2a9a2aafa97687e2f2
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/311411
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change the charge override hot keys to ctrol+search+0|1|2
BUG=none
BRANCH=samus
TEST=use the hot keys and verify that the PD console shows
charge override host command
Change-Id: I5551190743ea064a967164b9d95143cc966662e1
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242832
Reviewed-by: Shawn N <shawnn@chromium.org>
Add hot key detection for alt + volume down + 0|1|2 to set the
charging port by sending the charge override command to PD MCU.
This should be removed once hot-keys (or some other UI) is added
to higher layers.
BUG=chrome-os-partner:34850
BRANCH=samus
TEST=load onto samus and connect to another samus. use hot keys
and see that charge override command gets set appropriately on
PD MCU.
Change-Id: I7e72d597a02b7aca3326911796d20003f6697077
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238226
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Our code base contains a lot of debug messages in this pattern:
CPRINTF("[%T xxx]\n") or ccprintf("[%T xxx]\n")
The strings are taking up spaces in the EC binaries, so let's refactor
this by adding cprints() and ccprints().
cprints() is just like cprintf(), except that it adds the brackets
and the timestamp. ccprints() is equivalent to cprints(CC_CONSOLE, ...)
This saves us hundreds of bytes in EC binaries.
BUG=chromium:374575
TEST=Build and check flash size
BRANCH=None
Change-Id: Ifafe8dc1b80e698b28ed42b70518c7917b49ee51
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200490
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This may not contain all. I filtered out possible code by the
following command:
find . -name "*.h*" -o -name "*.c*" | xargs grep -n CPRINTF | \
grep -v "\[" | grep -v define | less
BUG=none
BRANCH=none
TEST=make buildall tuntests
Change-Id: I674f84f5966b34aeb8d4321d22629b450627a120
Signed-off-by: Louis Yung-Chieh Lo <yjlou@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197997
Refactored keyboard scan enable/disable flag such that it is a mask of
potential disable sources. When all disable sources are off, scanning is
enabled, otherwise scanning is disabled. This fixes a recently introduced
bug in which enabling/disabling keyboard scanning due to lid angle in S3
was interfering with enabling/disabling keyboard scanning due to power
button. This also allows for easy expansion for future causes for disabling
keyboard scanning.
BUG=chrome-os-partner:27851
BRANCH=rambi
TEST=Manual tests with a glimmer. Used the ksstate console command to
check state of keyboard scanning under all permutations of power button
pressed/unpressed, lid switch open/closed, and lid angle in tablet position
vs. laptop positon.
Change-Id: Ied4c5ebb94510b1078cd81d71373c0f1bd0d6678
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/194287
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added ability to disable the keyboard to wake from suspend when the lid
is outside a certain angle range. This has been added to glimmer by
defining CONFIG_LID_ANGLE_KEY_SCAN in its board.h.
Also modified the lid angle calculation to include a reliability
flag which can be used to tell when the hinge aligns too closely
with gravity and the lid angle value is unreliable.
BUG=none
BRANCH=rambi
TEST=Tested on a glimmer:
In S3, verified that when the lid is open past ~180 deg, the keyboard
does not wake the machine. Also verified that if you align hinge with
gravity, the keyboard enabled/disabled status remains the same (since
we can't actually trust the lid angle value).
Change-Id: I45b2c7c3c4bbcae61d3a0f8b5baa461ab8dabfb0
Original-Change-Id: If1a1592d259902d38941936961854b81b3a75b95
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190061
Reviewed-on: https://chromium-review.googlesource.com/191612
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a key is pressed which is not in actual_key_mask, this triggers the
keyboard scan interrupt. But read_matrix() would use the key mask to
decide that no *real* keys were pressed. So it would immediately drop
out of scan mode back to interrupt mode. Which would again be
triggered. Lather, rinse, repeat, watchdog.
The fix is to use the unmasked key matrix to decide whether to stay in
scan mode. This way, the keyboard task sleeps between scans, and the
watchdog isn't triggered.
(Note that the only way you can hit this bug in real life is to have a
keyboard attached which can trigger keys not in actual_key_mask.
Which is hard to do, unless you've got a new prototype keyboard with
extra keys, or you've spilled lemon juice on your Chromebook...)
BUG=chrome-os-partner:25333
BRANCH=rambi
TEST=Zero out actual_key_mask in keyboard_scan.c. Press a key. Should
not trigger a watchdog.
Change-Id: I8c2fbc3e06fa12dfae5c06614814af8f04e24a8a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/184323
Reviewed-by: Dave Parker <dparker@chromium.org>
Tested-by: Dave Parker <dparker@chromium.org>
F13 is used to trigger the lock/password screen
for users logged into Chromium OS. F13 is already
used for this purpose on the USB Chrome keyboard.
BUG=chrome-os-partner:24376
BRANCH=clapper,glimmer
TEST=Run "kbpress 9 3 1" to simulate keypress.
Verify lock screen is entered in Chromium OS.
Set1:
Run evtest. Verify KEY_F13 scan code, value=5d
Set2:
Add kernel parameter "i8042.direct=1" to use RAW mode.
Run evtest. Verify KEY_F13 scan code, value=2f
Change-Id: I71200810681f683c17e30b383e1221784deae0cd
Signed-off-by: Dave Parker <dparker@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182289
The "kbpress" command had a few issues if you wanted to reliably use
it for automation. Specifically it was not possible to guarantee how
much time would pass between the press of a key and the release of a
key. Sometimes you might press and release before the key was
officially "there" and sometimes you might get a press and hold of a
key.
Fix this:
1. Make it so that kbpress with no press/release parameter gives a
press and release (and guarantees that the press / release will
actually take effect).
2. Make it so that kbpress guarantees that when it finishes that the
key has actually been pressed or released.
BRANCH=pit
BUG=chrome-os-partner:24249
TEST=kbtype is (https://chromium-review.googlesource.com/178680) reliable
TEST=make -j32 BOARD=bds tests && make BOARD=bds runtests
TEST=Pick Ibe00a796bde7d06416889b621359671a2f68e162 and test.
Change-Id: Ia213ab2e8d8da273e3ac4876d97d5452df88f47d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178983
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 247650ecc90385417f5dcb2d60bb6ae1e5cfa32f)
Reviewed-on: https://chromium-review.googlesource.com/179325
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove comments if no longer applicable, or assign bug numbers if they
still are. Tidy some debug output. No code changes other than the
debug output.
BUG=chrome-os-partner:18343
BRANCH=none
TEST=build all platforms, pass unit tests
Change-Id: I2277e73fbf8cc93f3b1b35ee115e0f2f52eb8cf9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175215
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When the EC CPU is running at a decreased clock frequency, frequent
keyboard scans can starve other EC tasks of CPU and lead to dropped
data or watchdog timeouts.
Enforce a minimum number of EC clocks between keyboard scans to
prevent this from happening. The default chosen (16000 clocks) is
equal to the shortest post-scan delay (1 ms) of any current board when
the AP is in S0, so this should have no effect when the AP is in S0.
When the AP is in S3 or S5, we don't need to scan the keyboard as
frequently anyway. This can be overridden on a per-board basis for
future boards if needed.
BUG=chrome-os-partner:23247
BRANCH=pit
TEST=apshutdown, then hold down a key for 10 seconds. Should not see a
watchdog reset.
Change-Id: I228f53a32ad4769f6a137a9ab06903111bea115d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172895
Reviewed-by: Vic Yang <victoryang@chromium.org>
If keyboard scanning is active when the lid closes, it will disable
scanning put the scan task to sleep. We need a corresponding task
wake when the lid opens, or scanning will be stuck off (until
something else happens, like poking the power button).
BUG=chrome-os-partner:22190
BRANCH=peppy
TEST=Hold down a key. Use a magnet to trigger the lid switch. Scanning
should stop while the lid is "closed", and restart when the magnet is
moved to "open" the lid again.
Change-Id: I0a900f17f65b75cbdb45950cea7f50190d2bf9b1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170993
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
As our stack for the keyboard scanning task might be small (256 bytes on
STM32), we store the full keyboard state in a global instead of the
stack to avoid consuming 16 bytes there.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:19389
TEST=run on Spring with CONFIG_OVERFLOW_DETECT and see that the KEYSCAN task
is now consuming 248 bytes of stack instead of 264.
Change-Id: I2dd7815f36e6807e7b9e88d59f8fd8a14b1988ab
Reviewed-on: https://gerrit.chromium.org/gerrit/51028
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
By default it's not, but if you #define CONFIG_CUSTOM_KEYSCAN, you can add
your own settings in board.c
BUG=chrome-os-partner:18343
TEST=build link, bds
BRANCH=none
Change-Id: I2a9dd48fd7f4610bc39dcc59e59a3fedec539e28
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48994
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This will allow ARM code to use the same lid switch code (in a subsequent CL).
BUG=chrome-os-partner:18343
BRANCH=none
TEST=open lid; system boots. close lid; system suspends. open lid; resumes.
Change-Id: I83536a3ad24c4446dccf8a6b6e296756659070a8
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/47043
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This way debug commands which previously took only yes/no or on/off or
enable/disable can take any of those options.
BUG=chrome-os-partner:18467
BRANCH=none
TEST=Try "on", "off", "yes", "no", "true", "false", "ena", "disable", for
each of the following commands:
- ilim (spring)
- pll (link)
- power (spring/snow)
- hcdebug (all)
- kblog (link)
- ksscan (all)
- lp5562 (spring)
Change-Id: Ie8e0fae3775b1da711864bcba6682ba5e68a06f1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46900
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Scanning is now performed identically on all platforms. keyboard_scan
talks to chip-specific keyboard_raw on the bottom end, and 8042 or mkbp
keyboard protocol on the top end.
8042 can now take advantage of CONFIG_KEYBOARD_TEST to simulate scan results.
BUG=chrome-os-partner:18360
BRANCH=none
TEST=compile all boards; test keyboard on spring and link
1) Type on keyboard. Should produce keystrokes.
2) At EC console:
kbpress 3 7 1
kbpress 3 7 0
Should produce 'r' keystroke(s); key repeat should kick in if you wait
a while between the commands.
3) Hold power button while typing. Should not produce keystrokes.
4) Reboot with power+refresh+esc. Should go to recovery mode.
5) While the system is up, alt+volup+R should reboot the AP.
Change-Id: I48e0bca15b869162672b5f54ffcb561f6fcf0f45
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46666
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is part one of a series to merge the keyboard scan interface to
be common across all platforms.
This change just moves and renames files and APIs and removes some
read code, and sets up protocol-specific CONFIG options. It makes the
next CL which actually merges keyboard scanning easier to parse.
BUG=chrome-os-partner:18360
BRANCH=none
TEST=compile all boards; test keyboard on spring and link
Change-Id: I815a40aae4e5d5f333b8501aff9656080533d913
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/46549
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
