summaryrefslogtreecommitdiff
path: root/common/lb_common.c
Commit message (Collapse)AuthorAgeFilesLines
* i2c: Split i2c_xfer into locked/unlocked versions.Jonathan Brandmeyer2018-08-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename i2c_xfer to i2c_xfer_unlocked. Audit all users of i2c_xfer to see if they can use simple locking semantics or require their own locking. Since locked accesses are only safe for I2C_XFER_SINGLE transactions, remove the flags parameter from i2c_xfer. This also makes the audit a bit easier. Some remaining applications hold the bus locked across several transactions that would otherwise be atomic, and a few others implement complex I2C transactions in multiple commands. Add a (nondeterministic) verification on the I2C port locking correctness. This will catch all statically incorrect locking patterns, although dynamically incorrect locking patterns may not be caught. Related: Revise the i2c_port_active_count to be a bitmap of the active ports instead of a count of the active ports. The EC's mutex does not provide an is_locked() primitive, and we would prefer not to have one. - board/glados: Custom locking for battery reset - board/mchpevb1: Custom locking for battery reset - board/oak: Custom locking for battery reset - board/samus: Custom locking for lightbar reset - board/sweetberry: simple locking - board/servo_micro: Custom locking for funky i2c transfers - capsense: simple locking - host_command_master: multi-command transactions - lb_common: manual locking to support samus power sequence - smbus: multi-command transactions - usb_i2c: simple locking - driver/tcpm/fusb302: simple locking and multi-command transactions - driver/tcpm/tcpi: Forward _unlocked and implicitly locked interface to fusb302 - driver/touchpad_elan: simple locking BUG=chromium:871851 BRANCH=none TEST=buildall; very careful audit TEST=grunt clamshell and Coral clamshell, test boot, battery charging, PD communication, and TCPC port low-power mode. Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Change-Id: Ieabf22bcab42780bdb994fca3ced5d8c62519d56 Reviewed-on: https://chromium-review.googlesource.com/1169913 Commit-Ready: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Tested-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Jett Rink <jettrink@chromium.org>
* cleanup: Remove 'ryu' boardShawn Nematbakhsh2017-09-111-4/+1
| | | | | | | | | | | | | | | Remove 'ryu' and related ryu-only code. BUG=None TEST=`make buildall -j` BRANCH=None Change-Id: I19b966ea6964a7ed083724f7de80ae192235a406 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/656314 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* ryu: fix max lightbar brightnessAlec Berg2015-09-251-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix max brightness for Ryu. The max brightness must be less than 0x80 because the top bit in the lightbar current registers is reserved. Writing the top bit seems to have undefined behavior. This fixes the hiccups in the tap for battery sequence which was ramping brightness to above 0x80 and producing weird results. BUG=chrome-os-partner:45835, chrome-os-partner:44029 BRANCH=smaug TEST=test tap for battery looks smooth. test that the google colors match the desired current levels: > lightbar ... 15 0f 06 16 0f 20 17 16 08 18 06 21 19 26 11 1a 1d 0b Change-Id: Iecf1c770f986064b9b4d2d3d54fab0ea1242af01 Signed-off-by: Alec Berg <alecaberg@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302146 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 133dab0c36160d0e54820cce9e97071df34340f8) Reviewed-on: https://chromium-review.googlesource.com/302446
* common: lightbar: put multiple commands under i2c_lockGwendal Grignou2015-09-191-16/+37
| | | | | | | | | | | | | | | | | | If other i2c traffic happens around the time the light bar is initialized, the i2c bus is wedged. Instead of waiting 500ms in the motion task loop for the tap sequence to complete, set under i2c lock the lp power and init sequence. BRANCH=smaug, samus BUG=chrome-os-partner:45223 TEST=With msleep(500) removed and With lb_power + lb_init + 100ms, I don't see the wedge at TAP sequence. Change-Id: I931eb25bcc5e3237b6c569f2330f72f9fc415964 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/299543 Reviewed-by: Bill Richardson <wfrichar@google.com>
* ryu: re-calibrate lightbar colors for device.Todd Broch2015-08-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Todd Broch <tbroch@chromium.org> BRANCH=smaug BUG=chrome-os-partner:44029 TEST=manual, 1. Boot device into S0 2. From EC console lightbar ... 15 0f 06 16 0f 20 17 16 08 18 06 21 19 26 11 1a 1d 0b These values match requested values. Change-Id: Ib65044510ac24bd41d63586534685f995fcb131d Reviewed-on: https://chromium-review.googlesource.com/294840 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Todd Broch <tbroch@chromium.org>
* lightbar: document how it all worksBill Richardson2015-08-201-0/+87
| | | | | | | | | | | | | Add a huge comment so people can figure this out easier. BUG=none BRANCH=none TEST=make buildall Change-Id: I042a209c06023210b8ad53d138971ffee4b89ab7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/294179 Reviewed-by: Todd Broch <tbroch@chromium.org>
* ryu: remove P4/P5 code leftoverVincent Palatin2015-07-211-2/+2
| | | | | | | | | | | | | | | | | Remove remaining conditional code for ryu_p4p5 board which is gone. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=chrome-os-partner:38333 TEST=make buildall Change-Id: I1630fab5355d10018dab7f0fed7e35f240422ddd Reviewed-on: https://chromium-review.googlesource.com/287142 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* Remove obsolete board-specific codeRandall Spangler2015-06-101-9/+0
| | | | | | | | | | | | | | | | | Now that we've removed boards from ToT, also delete board-specific code used only by the removed boards. There are still more things to remove (unused charging chips, LED drivers, COMx support). More CLs coming. BUG=chromium:493866 BRANCH=none TEST=make buildall -j Change-Id: Ie6bdeaf96e61cadd77e3f6336c73b9b54ff4eabb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/276524 Reviewed-by: Alec Berg <alecaberg@chromium.org>
* ryu: fork P4/P5 supportVincent Palatin2015-05-021-2/+2
| | | | | | | | | | | | | | | | | | | In preparation for Proto 6 board support which won't be backward compatible, fork the EC for Proto 4 and Proto 5 for people who need to support older boards. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=none BUG=chrome-os-partner:39202 TEST=make buildall Change-Id: I520bbf146cc1c1dc04e55283be57807ec19ebaa1 Reviewed-on: https://chromium-review.googlesource.com/266064 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
* ryu: switch default firmware to use STM32F373Vic Yang2014-11-121-2/+2
| | | | | | | | | | | | | | | | This simply renames ryu to ryu_p1, and ryu_p2 to ryu. 'ryu_p1' will be kept for a while and will be decommisioned when most developers make switch to the new boards. BRANCH=None BUG=chrome-os-partner:33583 TEST=Build ryu and boot on P2 board. Change-Id: Ief61c64c6aefdaeae76ac7b86e0ea28131810aa1 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/229291 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Re-Calibrated lightbar values for Samus & RyuBill Richardson2014-11-061-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | New values from lab testing with slightly higher intensity. BUG=chrome-os-partner:33017 BRANCH=ToT,samus,ryu TEST=manual ectool lightbar brightness ff ectool lightbar seq s3s0 ectool lightbar Resulting current levels: 15 00 2d 16 2a 0a 17 26 13 18 10 0b 19 10 26 1a 1b 0d Change-Id: I118bf2fda3dee67b27c5d6a5825b7a9a96dc66dd Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/227515 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Calibrated lightbar values for Samus & RyuBill Richardson2014-10-221-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | This updates the lightbar params with the values determined in the optic lab. The full-on primary colors are of uniform intensity at the brightness level used by Link. The Google colors provide the closest match to the official color palette (at full brightness) described at https://sites.google.com/a/google.com/brandsite/the-colours BUG=chrome-os-partner:33017 BRANCH=ToT,samus,ryu TEST=manual The calibration and testing was done in the optic lab. You can see the result just by looking at the lightbar. For best results, set the brightness to the max with ectool lightbar brightness ff Change-Id: I1cb64e3c547844adf733cd46bff1256319b4f612 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224992
* ryu: enable lightbar on P2 boardsVic Yang2014-10-221-1/+4
| | | | | | | | | | | | | | | Ryu uses the same LEDs as Samus, so let's use the same brightness values for them. Also, increase the stack size for console task so that 'lightbar' command doesn't cause stack overflow. BRANCH=None BUG=chrome-os-partner:32203 TEST=See lightbar in action on Ryu. Change-Id: I89b61f6df2751c9dd6b40f9e374f01e1b0dfd504 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/224426 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Remove PULSE and TEST sequences from lightbar moduleVic Yang2014-10-081-26/+0
| | | | | | | | | | | | | | | PULSE and TEST sequences are not used anywhere. Remove them to save flash space. Also, fix msleep(MSEC) calls in the unit test; it's essentially usleep(SECOND) written in an incorrect way. BUG=chrome-os-partner:32203 TEST=make buildall BRANCH=None Change-Id: I61ba897df632538eb89364a4c913d5fee87f3864 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/220711 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* lightbar: correctly revert to the S0/S3/S5 patternsBill Richardson2014-08-201-0/+10
| | | | | | | | | | | | | | | | | | This CL ensures that temporary "one-shot" sequences such as KONAMI, TEST, TAP, etc. will revert to the previous "normal" sequences even when interrupted by other one-shot sequences. This also adds a test for those cases. BUG=chrome-os-partner:29873 BRANCH=ToT TEST=manual make runtests Change-Id: Ie83908731acdf2f7c9108568a1ba047943175d26 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/213230
* Add cprints() and ccprints()Vic Yang2014-05-211-5/+5
| | | | | | | | | | | | | | | | | | | | | 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>
* Put the lightbar IC controls and pattern logic into separate filesBill Richardson2014-05-151-0/+270
This puts the code that talks to the lightbar hardware in one file, and the code that implements the pretty patterns and behavior into another. This will let us make improvements or changes to the patterns without requiring detailed knowledge of the controller chips. BUG=chrome-os-partner:28596 BRANCH=ToT TEST=make buildall -j Refactoring only. There is no new functionality. Change-Id: I4e5fe8943385ddeab26bbd7e66c20e2dccd3dc43 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/199882 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status