Alec Berg 242f195771 rambi: glimmer: Disable key scanning in suspend when lid is open
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>
2014-03-27 18:44:14 +00:00
2014-03-23 23:35:23 +00:00
2014-03-22 18:49:09 +00:00
2014-02-06 19:27:18 +00:00
2012-05-11 09:11:52 -07:00
2013-12-19 00:12:24 +00:00

In the most general case, the flash layout looks something like this:

  +---------------------+
  | Reserved for EC use |
  +---------------------+

  +---------------------+
  |     Vblock B        |
  +---------------------+
  |  RW firmware B      |
  +---------------------+

  +---------------------+
  |     Vblock A        |
  +---------------------+
  |  RW firmware A      |
  +---------------------+

  +---------------------+
  |       FMAP          |
  +---------------------+
  |   Public root key   |
  +---------------------+
  |  Read-only firmware |
  +---------------------+


BIOS firmware (and kernel) put the vblock info at the start of each image
where it's easy to find. The Blizzard EC expects the firmware vector table
to come first, so we have to put the vblock at the end. This means we have
to know where to look for it, but that's built into the FMAP and the RO
firmware anyway, so that's not an issue.

The RO firmware doesn't need a vblock of course, but it does need some
reserved space for vboot-related things.

Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public
root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If
we reserve 4K at the top of each FW image, that should give us plenty of
room for vboot-related stuff.
Description
No description provided
Readme 1.4 GiB
Languages
C 64.7%
Lasso 20.7%
ASL 3.6%
JavaScript 3.2%
C# 2.9%
Other 4.6%