Our existing GPIO macros use port# / gpio#, but the concept of different
GPIO ports does not exist on the mec1322. Therefore, add new GPIO macros
for chips which do not have distinct GPIO ports.
BUG=None
BRANCH=None
TEST=make buildall -j
Change-Id: Ibda97c6563ad447d16dab39ecadab43ccb25174b
Signed-off-by: Steven Jian <steven.jian@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/262841
Reviewed-by: Anton Staaf <robotboy@chromium.org>
The same code exists in four (soon to be five!) different power
sequencing drivers, so move it up to common.
BUG=None
TEST=Manual on Samus. Run "pause_in_s5 on" on EC console, verify that
system stops in S5 on shutdown. Run "pause_in_s5 off" on EC console,
verify that system again goes to G3 on shutdown.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaf05ef7ce017be4f9d173e83e985a7a879ba278c
Reviewed-on: https://chromium-review.googlesource.com/269566
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In the gpio_info struct, we had a irq_handler pointer defined even
though a majority of the GPIOs did not have irq handlers associated. By
removing the irq_handler pointer out of the struct, we can save some
space with some targets saving more than others. (For example, ~260
bytes for samus_pd).
This change also brings about a new define:
GPIO_INT(name, port, pin, flags, signal)
And the existing GPIO macro has had the signal parameter removed since
they were just NULL.
GPIO(name, port, pin, flags)
In each of the gpio.inc files, all the GPIOs with irq handlers must be
defined at the top of the file. This is because their enum values from
gpio_signal are used as the index to the gpio_irq_handlers table.
BUG=chromium:471331
BRANCH=none
TEST=Flashed ec to samus and samus_pd, verified lightbar tap, lid, power
button, keyboard, charging, all still working.
TEST=Moved a GPIO_INT declaration after a GPIO declaration and watched the build
fail.
TEST=make -j BOARD=peppy tests
TEST=make -j BOARD=auron tests
TEST=make -j BOARD=link tests
Change-Id: Id6e261b0a3cd63223ca92f2e96a80c95e85cdefb
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263973
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Trybot-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The fans on samus have a recommended minimum duty cycle of 20%
while running, but 30% in order to start. We've been using the
EC's built-in fan controller for the start requirement, but it
has a minimum fast-start duty cycle of 50%. It turns out that
that speed is noticeably noisy.
This change handles the startup with logic in the EC instead, so
that the fan only tries to spin at 30% initially (or if it drops
too much below the minimum turning speed).
BUG=chrome-os-partner:33429
BRANCH=ToT,samus
TEST=make buildall -j
Boot the system, let it idle with the browser windows closed, the
browse a bit, then idle. Listen for changes to the fans.
Before, I could hear the fans kick in and out as the AP load
changed. Now it's much quieter.
Change-Id: Id35215520c064eb6843686ec8bb5f3618dac6cf6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
