This enables the Cr50 to accept RW firmware updates over USB.
BUG=chrome-os-partner:50707, chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50
Build and run the extra/usb_updater utility. Watch the console,
and observe that the Cr50 updates and reboots into the new image
correctly.
Note that you'll have to rebuild the ec.bin image in order for
the update to take effect. Just reflashing the same image doesn't
cause the bootloader to change its selection.
All the previously existing endpoints continue to function normally.
Change-Id: I7bd22eae803c2ceeb14a767c06d3d5c9f1ac7c7a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338089
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
This adds a standalone linux utility to deliver RW firmware
updates to the Cr50 over USB.
It prepares update blocks required by the firmware upgrader, and then
fragments and transfers the blocks though the USB channel. The blocks
are reassembled on the target and passed to the upgrade module for
integrity verification and programming.
BUG=chrome-os-partner:50712
BRANCH=none
TEST=make buildall; test on Cr50 as follows:
sudo extra/usb_updater/usb_updater build/cr50/ec.bin
The Cr50 doesn't yet accept firmware updates that way,
so there's no functionality to test just yet.
Change-Id: I1c698fd0c553c936d58ff16a2acaa05ae05bc857
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338088
This re-factors the existing firmware upgrade facility, which worked as
a TPM command extension.
The same code processing upgrade blocks prepended by the truncated
SHA1 and the load address is now used by both extended TPM command and
the USB upgrader.
To accommodate USB communications using a smaller message payloads a
reassembly layer is introduced which accumulates short USB payloads
into a single block which can be passed to the firmware upgrade
routine. USB encapsulation adds one 4 byte header at the beginning of
the block to hold the total block size. The reassembly layer keeps
receiving USB messages, concatenating their payloads until the full
block is received.
A config option is added to make sure the module is not compiled when
not needed.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50 - with the rest of the patches
applied it is possible to upgrade firmware using the USB utility
on the host..
Change-Id: Ib30b381c4ab196ea9d352f3c6b8f46dc23ddd599
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338087
Various voltage rails will be enabled / disabled by the PMIC when
GPIO_PMIC_SLP_SUS_L changes. We need to delay the disable of V0.85A
by approximately 25ms in order to allow V1.00A to sufficiently discharge
first.
BUG=chrome-os-partner:52047
TEST=Probe V1.00A and V0.85A during power-down, verify V1.00A discharges
faster than V0.85A.
BRANCH=glados
Change-Id: Ibbf4f989e1814e131dc373d2b5da9b6fa1ac9cce
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337325
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It's handy to use the usb-stream interfaces to avoid a lot of
typing. But not all the endpoints are traditional serial ports.
This just adds a new macro that lets us specify additional
parameters.
BUG=chrome-os-partner:50707
BRANCH=none
TEST=make buildall; test on Cr50
Verified that all the previous endpoints still work as before.
There are no endpoints that use the new macro yet.
Change-Id: Ia37901cbe3adc4a4650ab91db3596efa15a110de
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/338086
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The scheme to disable PD communication in locked RO needs to be
implemented on other platforms, so move it to common code, behind
CONFIG_USB_PD_COMM_LOCKED.
BUG=chrome-os-partner:52157
BRANCH=glados
TEST=Manual on chell. Lock system and boot to recovery, then verify PD
communication is functional. Enable CONFIG_USB_PD_COMM_LOCKED and verify
PD communication isn't functional under the same test conditions.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8d1f24c0b60cf1c54e329af003b7083ee55ffc40
Reviewed-on: https://chromium-review.googlesource.com/338064
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Use LARGER_TASK_STACK_SIZE to increase stack size to 640 bytes.
Check HOSTCMD stack usage with "taskinfo" command while running
the suspend/resume stress test.
8 R HOSTCMD 00000001 21.133553 496/640
It exceeds 488 bytes of TASK_STACK_SIZE.
BUG=chrome-os-partner:51773
BRANCH=none
TEST=enter "suspend_stress_test -i spi32766.0" in AP to do
suspend test. System won't do cold reboot which is cause by
"Stack overflow in HOSTCMD task!".
Change-Id: Ic5edebc6b77637ca2c648798398e3f24bc87ca27
Signed-off-by: YH Huang <yh.huang@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/336593
Reviewed-by: Rong Chang <rongchang@chromium.org>
If we #define CONFIG_RW_B, the firmware image can have two RW
components. This CL expands the "sysinfo" command so that we can
see which image we're running from when RW_B is also a
possibility.
BUG=chrome-os-partner:50701
BRANCH=none
TEST=make buildall; test RW update on Cr50
Using test/tpm_test/tpmtest.py, update the RW firmware and reboot
several times to switch between RW_A and RW_B. Note that the
"sysjump" command reports the correct image each time.
Change-Id: Iba3778579587f6df198728d3783cb848b4fd199d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337664
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds a command to connect or disconnect, and to switch the
PHY between A or B.
BUG=chrome-os-partner:52055
BRANCH=none
TEST=make buildall; test on Cr50
Using a test board with both PHYs plugged in, try the various
commands:
usb off
usb on
usb a
usb b
The on/off option connects and disconnects, the a/b option
switches between PHYs. You can see the state change on the
console, or by running dmesg on the host.
Change-Id: I4c77e9c586ce197dc99b0b50af7396c253a1a377
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337706
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change adds support for forwarding the EC console through USB.
BUG=chrome-os-partner:49960
BRANCH=none
TEST=load the google-serial udev rules in extra/usb_serial/, build the
raiden.ko module, and then check that the console can be accessed from
/dev/google/Cr50/serial/Shell
Change-Id: I35e0bb39fdc8f9485a14c03eb3a4d2f024884e17
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/334132
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cr50 will be used to debug the EC and AP through USB. This change
enables exporting the EC and AP UART through USB by adding the endpoints
and enabling the UART and USB streams.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=Load the serial driver in ec/extras and verify that the EC and AP
UARTs can be accessed through /dev/google/Cr50*/serial/AP and EC.
Change-Id: I3249b250d0ecc41a206c45c5ca66b5a6a5622e62
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337294
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
CR50 will need three serial endpoints for the streaming AP and EC UART
and exporting its own console through USB. This change adds a macro to
create endpoints that can be recognized by the usb_serial driver.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=Verify "/dev/google/Cr50*/serial/Blob" prints capital letters when
lower case letters are input.
Change-Id: Iddf2c957a00dc3cd5448a6a00de2cf61ef5dd84c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336441
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If the charge current or charge voltage registers are set to zero then the
charger cuts the power to board. BD99955 does not support 0mA charge current
& 0mV charge voltage values hence set the charge current & charge voltage
to charger's minimum values.
BUG=chrome-os-partner:52050
BRANCH=none
TEST=Manually tested on Amenia. Board can boot without the battery.
Battery does not discharge when the charger current or charger
voltage is sent to 0 from the charger manager.
Change-Id: I8049525594d107d7ad1ff2f17e8df757ee86458c
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/337404
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If the Cr50 is in deep sleep, it does a full warm boot when it
sees the SPS_CS_L assert. The master doesn't wait for it to
boot (because it doesn't know it has to) and starts clocking in
data bits right away. The Cr50 can't set up the SPS controller
quickly enough to capture those bits, so the first N bits/bytes
are lost and the master keeps clocking, waiting for the SPI
response which it will never get.
To be certain that the Cr50 is awake, this CL causes the
test (master) to assert SPS_CS_L briefly, then wait a little bit
for the Cr50 to wake up from deep sleep (50ms should be plenty),
and THEN it can send the rest of the SPI traffic.
The Cr50 won't enter deep sleep until it's been at least a second
since the last SPI activity, so we don't have to worry about it
going to sleep between SPI commands as long as they're not
terribly far apart.
The kernel driver will have to implement this same hack too,
since the SPI bus doesn't have a suspend/resume protocol like the
USB does. We've known this for some time. It would be nice if
this weren't needed, but it's a hardware constraint.
BUG=chrome-os-partner:49955, chrome-os-partner:52019, b:28018682
BRANCH=none
TEST=make buildall; test on Cr50
Ensure that the Cr50 invokes sleep or deep sleep when idle (refer
to previous commit messages for the setup required), then
cd test/tpm_test
make
./tpmtest.py
Before this CL, the test hung or failed because it couldn't get a
quick response from the Cr50. With this CL, the Cr50 wakes up and
the test passes.
Change-Id: I581475726313981a780beaaa37638e9c3b9ebec5
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336837
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When compiling the EC firmware outside of the chroot, some
optional packages may not be installed. Let's be sure the tools
exist before we try to use them.
BUG=none
BRANCH=none
TEST=make buildall, both inside and outside of the chroot
Note that to build outside the chroot, we need to
1. Use GNU make verion 4.1 or later
2. Install the gcc-arm-none-eabi package
Change-Id: I78c75cb4ad658c003ded71b244b0458ae5532e0b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/337341
Reviewed-by: Shawn N <shawnn@chromium.org>
bd99955 enables BC1.2 detection by default and auto-sets current limit
based upon the detection results. This is undesirable because it races
against our external current limit settings (eg. USB-C / PD detection).
BUG=chrome-os-partner:51766
BRANCH=None
TEST=Manual on kevin. Plug zinger 10 times, verify that battery charges
at ~1500mA on each plug, except for cases where Zinger falls into reset
/ OC loop (a separate issue).
Change-Id: I787b2434c30b89fe78bbe50666075c694bf64503
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336970
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This adds (and uses) some additional flags for gpio.inc's
PINMUX() macro, to configure specific pads as wake sources when
the SoC is sleeping.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
The sleep/deep sleep behavior is unchanged. This just replaces
hard-coded wake sources with pads configured in gpio.inc and the
chip/g/sps.c module. Tests from previous CLs still pass.
Change-Id: I6608dc959524f42fd589feb804fa06f29cfd9b9c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336838
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This adds support for the "sleep" low-power mode. It consumes
less power than simply waiting, but doesn't require a full warm
boot to resume.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Configure the Cr50 to sleep when idle (refer to previous commit
messages for the setup required).
On the console, use the "idle" command to test the three
different modes:
idle w - wfi, wakes instantly
idle s - sleep, wakes slowly but without rebooting
idle d - deep sleep, wakes via warm boot
You can tell the difference between wfi and sleep by observing
that the first character is lost when typing on the serial
console while in sleep (remember that it will wait at least 10
seconds after the last console input before sleeping).
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ib2584aa44ab885f0c8369ec938ee17b935aa0898
Reviewed-on: https://chromium-review.googlesource.com/336836
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Wait at least 10 seconds after the last console input before
invoking sleep or deep sleep.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to sleep
quickly when woken via USB, but should take much longer when
awakened by typing on the serial console.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7a2b840565f5d82e0dbdf8a3e75061a69cb9e405
Reviewed-on: https://chromium-review.googlesource.com/336835
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
This preserves the selected idle action (wfi, sleep, deep sleep)
across soft reboots, which includes deep sleep. Hard reboots will
restore the default which is to not sleep at all.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; test on Cr50
Use the "idle d" console command to put the Cr50 into deep sleep
when idle (refer to previous commit messages for the setup
required).
Wake it up, then let it sleep again. It should go back to the
deep sleep state.
Change-Id: Iaad82b725d2b32a19205fa403dbaab9a31c35630
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336834
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
modify g781.c/.h to g78x.c/.h to suppor both G781/G782 temp sensor
based on CONFIG_TEMP_SENSOR_G781 or CONFIG_TEMP_SENSOR_G782
BUG=none
BRANCH=none
TEST=make buildall; able to get temperature data on board with G782
Change-Id: Ia32c85e9964bfd7c0c5263f04368bc001a27fe10
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/334228
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds the SPI slave bus and TPM task to the things that
can prevent deep sleep. Even when things are quiet, we wait at
least a second
With this CL, it will wait at least one second after the last SPS
transaction before sleeping. Since most TPM-protocol commands are
built up of a number of back-to-back SPS messages, if we don't
wait we'll keep trying to sleep in the middle of active commands.
Even if everything is quiet, we wait 0.2 seconds anyway to give
the UART buffers time to drain.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
In addition to ALL the steps listed in commit
d917d3f1867e96369ff25bf6906043a5f488a6fb, loading the firmware
with the spiflash tool leaves SPS_CS_L low, so you have to drive
it high manually. The easiest way is to build and run
test/tpm_test/tpmtest.py for a few seconds then interrupt it with
Ctrl-C.
Note that because the system wakes from deep sleep when it sees
SPS_CS_L go low but it can't get ready fast enough to capture the
incoming bits, that first SPI transaction will be garbled or
lost. You'll have to either retry it, or wake the system another
way first.
Change-Id: Iae2fe5ef33869c48e98a3afecd6b98991a51a488
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336690
Reviewed-by: Randall Spangler <rspangler@chromium.org>
After a charger is attached, we may set a charge limit based upon BC1.2
or USB-C Rp before PD negotiation completes. Therefore, allow 2 seconds
for all negotiation to complete. Previously this behavior was implicit
when using SW charge ramp.
BUG=chrome-os-partner:51280
BRANCH=glados
TEST=Manual on chell. Insert stock charger, verify that it is detected
as TYPE_UNKNOWN until timeout.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I52f02de46fa92b66a9fbaddb94a062310688f028
Reviewed-on: https://chromium-review.googlesource.com/334312
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
cr50 has three UARTs that it will be using. This change modifies the
uart api to specify which uart to use.
BUG=chrome-os-partner:50702
BRANCH=none
TEST=change the interrupts and CONFIG_UART_CONSOLE to see that the
different UARTs can be used.
Change-Id: I754a69159103b48bc3f2f8ab1b9c8b86cea6bea5
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/333402
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is still in testing mode, so you have to take special steps
to enable it (keep reading). But if you do the right dance, it
does go into deep sleep for USB suspend, and resumes correctly.
However, it doesn't yet wake for any other reason. That's coming next.
Normal sleep is not yet supported, either.
BUG=chrome-os-partner:49955, chrome-os-partner:50721
BRANCH=none
TEST=make buildall; extensive tests on Cr50
Testing is a pain.
First, you can't print anything in the idle task, because that
just makes it stop being idle, so the only way to detect when
it's triggered is by wiring up a GPIO and instrumenting things.
Second, you have to manually reenable USB suspend on the host
every time the Cr50 boots with
echo auto > /sys/bus/usb/devices/<BLEH>/power/control
where <BLEH> is the correct device.
Third, for reasons probably related to the mysteries of HID
devices combined with crbug.com/431886, you have to build the
firmware without CONFIG_USB_HID (and the related items in
board.h)
Finally, because it's still a work in progress, you have to type
idle d
at the serial console after every boot (or resume) to reenable
deep sleep in the idle task.
If you do all that, then you'll see that it does go into deep
sleep. Ping it again with "lsusb -v -d 18d1:5014" or
./test/usb_test/device_configuration, and it wakes up and
responds!
If you disconnect the USB while it's in deep sleep, it stays
asleep. When you plug it in again, it wakes up, but it correctly
recognizes that it shouldn't resume and does a normal reset
instead.
Change-Id: I3cc66e48ce671142a4d12edbe0eb9fdacecea0d9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336279
Reviewed-by: Dominic Rizzo <domrizzo@google.com>
Add support for charge port switching and extpower detection, which are
not part of the standard charger API.
In addition, add a console command for dumping all regs, which is
helpful for debug.
BUG=chrome-os-partner:51722
TEST=Manual with subsequent commit. Verify kevin charges at 3A input current
when zinger is inserted, and verify battery actually charges.
BRANCH=None
Change-Id: I98a0c0142d26facc0e0b9ef7f1dcd003ebffd9c1
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335537
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
NULL padding (aka vanilla RSA) support is required by
the TPM2 test suite (referred to as TPM_ALG_NULL in the
tpm2 source).
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tests under test/tpm2 pass
Change-Id: I9848fad3b44add05a04810ecd178fbad20ae92cc
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/328830
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Some of the reset causes are found in another register when
resuming from a low-power state. We know we'll need to
distinguish among them eventually, so we might as well decode
them now.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
I forced the system into deep sleep and observed that the reset
cause is accurately recorded on resume. Doing that requires a
fair amount of hacks and manual effort, and can't happen by
accident. Future CLs will make use of this.
The current, normal behavior is completely unaffected.
Change-Id: I5a7b19dee8bff1ff1703fbbcc84cff4e374cf872
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336314
Reviewed-by: Randall Spangler <rspangler@chromium.org>
A resume from deep sleep looks a lot like a cold boot, but there
are some registers that need updating quickly. We need to disable
the settings that triggered deep sleep so that it isn't
accidentally invoked again, and we need to unfreeze any modules
or pins that were frozen during the deep sleep.
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Since we aren't yet triggering deep sleep, this doesn't do
anything noticeable, which is the point. It shouldn't have any
effect unless we are entering deep sleep and DON'T do this when
it resumes. FWIW, I have tested that too, but it's coming in a
later CL.
Change-Id: I4b32fd2e24fe089d3f659154df26d275b41b4c1b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336450
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This just adds the framework to use for implementing sleep and
deep-sleep. This provides a custom idle task, and a new "idle"
console command to control what that task should do (nothing,
yet).
BUG=chrome-os-partner:49955
BRANCH=none
TEST=make buildall; test on Cr50
Other than the new idle command which does nothing, there is no
visible change. This is just a stub.
Change-Id: I8a9b82ca68dd6d1e3e7275f4f6753a23a7448f1d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/336420
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds USB support to Set and Get the Device Configuration.
These control transfers are standard device requests that need to
be added in order to behave properly for USB suspend/resume (and
in general). Before this CL, the Get command always failed and
the Set command had no effect internally. With this CL it works.
Note that this particular change only supports ONE configuration
for the Cr50. If/when we add additional configuration
descriptors, we'll need to update it again.
BUG=chrome-os-partner:50721
BRANCH=none
TEST=make buildall; manual tests on Cr50
This CL includes a test program. Connect the Cr50 to the build
host, and use that program to read and change the configuration.
cd test/usb_test
make
./device_configuration
./device_configuration 0
./device_configuration 1
./device_configuration 2
You may need to use sudo if your device permissions aren't sufficient.
Change-Id: Id65e70265f0760b1b374005dfcddc88e66a933f6
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335878
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Fan will disable when S3 and S5 by pwm_fan_s3_s5,
which call set_enabled(fan, 0) to disable it.
But the pwn_fan_resume called fan_set_enabled() which not setting
GPIO_FAN_PWR_DIF_L to 1, we should use set_enabled() instead.
BUG=chrome-os-partner:50372
BRANCH=master
TEST=check fan enable after system resume
Signed-off-by: Keith Tzeng <Keith.Tzeng@quantatw.com>
Change-Id: Id0bd4dd0afc7e02bcfa6e20401d6e9dfe8a81423
Reviewed-on: https://chromium-review.googlesource.com/335693
Commit-Ready: Keith Tzeng <keith.tzeng@quantatw.com>
Tested-by: Keith Tzeng <keith.tzeng@quantatw.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Update the GPIO mapping based on the Kevin P0 schematic and drive the EC
and AP select signals low.
BUG=chrome-os-partner:50728
BRANCH=none
TEST=test that DIOB2 and B3 default to low, but can be set high or low.
Change-Id: If574436913ad0271540bcce2939fe1f4574dae97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/335381
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When a pin power-on default is input, it is necessary to configure output
level, pull up, etc. before setting the pin to output. Otherwise, the
pin may be set to an undesired logic level for a short time.
BUG=chrome-os-partner:51722
TEST=Power-up kevin, verify that CR50_RESET_L (default input, configured
as high + open drain output by default) does not go low for a short
period at boot.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ieaa08e14e6ea15a908f3ff4ee9188e14b17583cf
Reviewed-on: https://chromium-review.googlesource.com/335344
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
