Before entering STOP mode, we need to ensure UART Tx has completed.
Otherwise, we may lose some characters or some bits within a character.
For Tx DMA mode, this is already done as we wait until TC (Tx complete)
is set before disabling Tx. However, when not using DMA, we enable sleep
when TXE is set. At this moment, the last character is still in the
shift register and going into sleep causes loss of the whole or part of
the last character.
To avoid this, let's enable TC interrupt and enable sleep only if we
have no more characters to send and TC is set.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Enable low power mode on Ryu P2. Type when the EC is in STOP mode
and check there is no broken character.
Change-Id: Ife42671882b7f1d1d17734d7d20fb4ba7dffb371
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225283
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds the option to use one 16-bit timer for watchdog helper when
using 32-bit hwtimer. With this, a debug message is dumped before
watchdog fires and we can easily see the task hogging the processor.
BRANCH=None
BUG=None
TEST=On Ryu P2, 'waitms 3000' and see debug message before the EC
reboots.
Change-Id: I498f63a105a0ba1ab7ec7d274dc8b1f16a44140f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225253
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This modifies the stray hard-coded DMA channel for UART Rx to the
correct config flag.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=On Ryu, enable UART Rx DMA and check console is still responsive
Change-Id: Icec2de6ad4d34c6e0f8df2a1d51d9fefd982c9f4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/225239
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On STM32F0, a single IRQ is used for all RTC events, including RTC_ALARM
and RTC_WAKEUP, and this IRQ is named RTC_WAKEUP. We use RTC_WAKEUP IRQ
in our code while we actually meant to capture RTC alarm event. On
STM32F3, RTC_WAKEUP and RTC_ALARM are separate IRQs and thus we're
having problem. Let's make it explicit which RTC IRQ we want to use and
fix our code to use RTC_ALARM.
BRANCH=None
BUG=chrome-os-partner:33219
TEST=Run 'rtc_alarm' on Ryu and verify the EC gets interrupted after a
second.
Change-Id: Ib1a14a5da49d709a4d071d44fbfa46544cc5929b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224998
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Simple control of SPI for flashing over USB.
This driver is working, and using the discovery board
with a W25Q16 flash chip attached flashrom can read,
erase, write, and verify the whole chip in 45 seconds.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I224f1f87cd6adc8b64c17de1df98dae0a9cfa6a5
Reviewed-on: https://chromium-review.googlesource.com/218740
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Updating the fan speeds according to the manufacturer's specs.
The fan vendor recommends that the minimum fan speed be a 20%
duty cycle. Since the built-in fan controller has a tach-based
feedback loop, I'm using the RPM value instead of the duty cycle
(20% is 2286 RPM, according to the vendor).
The vendor also wants a 30% duty cycle to start turning, but the
built-in fan controller provides support for fast-start too. The
controller's minimum fast-start duty cycle is 50%, but it also
has a programmable number of revolutions that it will wait before
backing off.
Holding my ear down close to the fans while they start and stop,
it seems that the minimum 2 revolution start period is sufficient
and provides the least noise. Of course, since I've never had any
problems starting the fans directly at 1000 RPM this noise is a
little more noticeable than that. It's quite possible that the
built-in controller is smart enough to make 1000 RPM work by
bumping the duty cycle up until the fans turn even if the fans
don't like it.
BUG=chrome-os-partner:32892
BRANCH=ToT,samus
TEST=manual
Listen closely and run the EC console "faninfo" command to see
the fans start and stop as the system boots and idles.
Change-Id: I47c9e7cef3f9f4bd815a13032fe10234decd62ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224830
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Unlike STM32F0, we need to configure alternate function for USB module
on STM32F373. Adds the pin configuration for ryu_p2 and also adds the
proper configuration step in USB module.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With changes to enable USB on ryu_p2, see the device enumerated
Change-Id: I5e2cb7cfc44a1bb88bae69804021c783c8d17968
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224789
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new build target ryu_p2 is mostly based on ryu. On ryu_p2, we have a
new EC chip with bigger flash, so make the corresponding changes:
- Pinout changes
- HW Timer: TIM5
- USB PD Tx Timer: TIM3_CH4
- USB PD Rx Timer: TIM2_CH4
- Use UART2 for EC console
- Disable UART Tx DMA as it conflicts with USB PD Tx DMA
- Use 24MHz HSE x2 = 48MHz for SYSCLK
BRANCH=None
BUG=chrome-os-partner:32660
TEST=Sanity check on a new board:
- i2cscan
- PD negotiation
- UART console
- gettime
Change-Id: I4ef6b53a928a2777721e3874032aeb0e6b2b4c92
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221404
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This adds the DMA channel definition for UART2 and allows selection of
DMA channel for UART.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=With the CLs to enable the new Ryu boards, check the console is
working.
Change-Id: I964c284899777dda67c264e622aea6aba752ea76
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224176
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Seems like we were setting outputs too early during boot, sometimes causing a
power leak. SPI should only turn on power levels more active than S3, not on the
S5->S3 transition.
BUG=chrome-os-partner:32824
BRANCH=None
TEST=Pinky powers on, Scope VCC33_PMUIO and VCC33_IO, note that they're smooth
Change-Id: I05c3622d124c2539222b883b895bc9092c5f0b12
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224508
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We already have interrupt handlers for channel 4 to 7. We need channel 3
for the new Ryu boards. Add the handlers for channel 1 to 3. Also,
instead of copy-pasting interrupt handlers, define a macro and declare
interrupt handlers with it.
BRANCH=None
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Check PD communication on the new Ryu board (with other CLs to
enable the new boards.)
Change-Id: I51d6bd16739f31a7efbeb4ec19bb91a1546fe21d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224175
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
So far, we always use channel 1 of the Tx timer and the configuration
code is hard coded. We need to support other channels for new Ryu
boards. Let's make this a configurable bit.
BRANCH=samus
BUG=chrome-os-partner:32660
TEST=make buildall
TEST=Plug in Zinger to Ryu and see 20V come up.
Change-Id: Id08d4eb0d6a5721d8a03672484d0892a0714383b
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/223836
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The valid and writable flags the EC sends back to the AP are incorrect.
They are a little bit different on differnt chips, so let's move it to
flash physical layer. This is not any causing problem, but we should fix
this.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222661
Reviewed-by: Randall Spangler <rspangler@chromium.org>
On STM32F0, we cannot work around the hard fault triggered when trying
to protect the whole flash. Therefore, we need to go with the
ALL_AT_BOOT approach. When write protect is enabled, instead of setting
ALL_NOW flag to immediately lock down the entire flash, we need to set
ALL_AT_BOOT and then reboot to have the protection take effect.
BUG=chrome-os-partner:32745
TEST=Along with the next CL. On Ryu:
1. Enable HW WP. Check the output of 'ectool flashprotect' and see
correct flags.
2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set.
3. Reboot EC and check RO_NOW is enabled.
4. Boot the system and check ALL_NOW is set.
5. Update BIOS and reboot. Check software sync updates EC-RW.
6. 'flashrom -p ec --wp-disable' and check it fails.
7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared.
8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared.
TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set
properly.
BRANCH=samus
Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222622
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a preparatory work for the following change for write protection
support on STM32F0.
BUG=chrome-os-partner:32745
TEST=make buildall
BRANCH=samus
Change-Id: Ic4deea06e26c4a6ac024a5388e1a5783b40e9876
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/222660
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove the meaningless version string in iSerialNumber, which was incorrect
since this string should be unique to a device if it exists.
Export the firmware version string as the configuration string, so it's
traceable to a given firmware build/sources.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=none
TEST=make buildall
from a workstation, do "sudo lsusb -v" and see the full version string
exported as the configuration name.
Change-Id: I557df2936421e2926ac0fc0003888370cec3e201
Reviewed-on: https://chromium-review.googlesource.com/222877
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
The BOS (Binary Device Object Store) descriptor was added to the USB
specification (3.0) to allow a richer set of device capability
specific descriptors.
The Billboard class is meant to expose (read-only) the status of USB
devices capable of alternate mode functions. It's required to use the
BOS descriptor type and at a high level looks like:
- BOS Device Descriptor (5bytes)
- Container ID Device Capability Descriptor (20bytes)
- Billboard Device Capability Descriptor (44byte + 4 * numSVIDs)
This CL adds:
1. Ability for Get Descriptor on BOS descriptors. Note hidden behind
CONFIG_USB_BOS as these descriptors change USB device requirements
to:
- bcdUSB >= 0201
- no interface descriptors
2. structures for all BOS, Container & Billboard descriptor elements
complete w/ CamelCase.
BRANCH=none
BUG=chrome-os-partner:32652
TEST=compiles with CONFIG_USB & CONFIG_USB_BOS enabled.
Change-Id: I1b24bc728f2ebba7d91840801d2ebe576e240e7c
Signed-off-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221570
When a control transfer requests a descriptor larger than 64 bytes, we
need to do several IN transfers to get the proper packet sequence :
SETUP IN IN IN .. IN OUT(null)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32652
TEST=set USB_STR_VERSION to "012345678901234567890123456789ABCDEF",
then do "lsusb -v" on the host and check the USB transfers
with the protocol analyzer.
Change-Id: I6940095008cb2a34c6896b337c5eda4fa267adc1
Reviewed-on: https://chromium-review.googlesource.com/222700
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Fix bug that can cause ADC initialization to hang and eventually
watchdog. Problem was that you need at least 4 ADC clock cycles
between end of ADC calibration and enabling ADC (setting ADEN).
Fix is to (1) move some ADC configuration to between end of cal
and setting ADEN, and then just to be safe, (2) continually set
ADEN until we see ADRDY (ADC ready).
See bug report for more information.
BUG=chrome-os-partner:32561
BRANCH=samus
TEST=load onto a samus that regularly has ADC problems on boot.
Using power+refresh verify that without this change PD hangs
some of the time, and with this change it never hangs.
Change-Id: Ifa4c3240ad7e1612647cc74e2105e6545ed19db4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221984
Reviewed-by: Vic Yang <victoryang@chromium.org>
This mostly reuses chip drivers for STM32F and STM32F0. Since this chip
doesn't fit either STM32F or STM32F0, let's use symlink to specify which
drivers to use for STM32F3.
This is just the preparatory work and it's not verified on a chip yet.
BUG=chrome-os-partner:32660
TEST=make buildall to make sure this doesn't break anything
BRANCH=None
Change-Id: I709ed49265e8f84552251a97d03b9b98496de99e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221412
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Correct frequency + duty cycle register calculations according to
datasheet.
BUG=chrome-os-partner:32089
TEST=Manual on Samus. Set 50% duty cycle and probe on scope, verify that
duty cycle is actually 50% and frequency is exactly 100 Hz.
BRANCH=samus.
Change-Id: I1e2c0bb7e53110367c38987b369fbef44af90a7d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221790
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This is mostly the same as previous commits, but with increased delay.
Previously, we have short delays (e.g. 3ms) which is too short and may
cause instability.
Now that we have slowed down the time when running unit tests and
increased the delay, this shouldn't cause problems anymore.
BUG=chrome-os-partner:31200
TEST=Repeatedly run multiple unit tests in parallel.
BRANCH=Samus
Change-Id: Ib55e3adc5fd27a8e233996b4799dab3cefd62318
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220734
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Minimuffin is identical to zinger, same MCU, same gpio, same
circuitry aroundt the MCU with two differences:
- Rated current is 2.25A instead of 3A
- USB PD hardware device ID needs to be different so that host
can differentiate between the two.
Due to the similarity between the two, minimuffin is defined
as a symlink to the zinger board.
BUG=none
BRANCH=samus
TEST=make BOARD=minimuffin
load onto a zinger and verify that samus reads device ID correctly
and limits input current limit to 2.25mA.
Change-Id: Ie39ec43262c7d14663eb68abff073bfeec451a24
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220689
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Silego variant in pinky rev2 require the signal to be inverted.
BUG=None
TEST=on pinky-rev2: all keys from col2 work correctly
BRANCH=None
Change-Id: I83a029b4e9c6b4770e83f30b170595d45ea40cca
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220314
Enabled deep sleeping during S0. This was previously inhibited by
SLEEP_MASK_AP_RUN but the new config option (CONFIG_LOW_POWER_S0) will ignore it.
SPI needed a sleep mask, it essentially gets enabled and disabled whenever the
CS changes. Warning: waking up when the CS falls takes a little time, if the AP
sends fast data before the 48MHz clock is enabled characters will get corrupted;
leave about 30uS time for the clock to start.
CQ-DEPEND=CL:219997
CQ-DEPEND=CL:220243
CQ-DEPEND=CL:220461
BUG=chrome-os-partner:32223
BRANCH=none
TEST=load onto pinky, boot the AP(S0), use idlestats command to verify
that we are going into deep sleep (STOP mode). Verify that everything works
normally during S0(SPI, keyboard, anything that requires the EC to wakeup).
Change-Id: I81c4fa472332f1ad8ad93301089a99dcdb108948
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219555
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add low power mode for zinger. This uses stop mode in task_wait_event(),
the non-runtime equivalent of the idle task.
BUG=chrome-os-partner:28335
BRANCH=samus
TEST=load onto zinger and plug and unplug into samus a bunch of times
to make sure it negotiates to 20V every time. also send custom vdm's
from samus_pd and make sure those always succeed.
Change-Id: I626365e7d22e030792d28dbf7eafaeb8f54f8a74
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219933
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
i2cdetect -q was broken on the AP. The way it works is by sending a 0 length
write request and checking for NACK. The stm32f0 driver had to be fixed to
actually return non-success if there was a NACK. i2cdetect -r worked so far
because it relied on a 1-length read and we indirectly detected NACKs by the
lack of data.
The error catching also had to be moved(in both drivers) before the success
returns, because it is possible to transmit something successfully(buffer got
emptied) without getting an ACK. We want this to be an error.
BUG=None
BRANCH=None
TEST=veyron: i2cdetect -y -r 20 0x09 0x0b should display -- on the 0x0a spot
since there's no device there. i2cdetect -y -{r,q} 20 should display the same
thing.
Change-Id: Id6cadb798e4d972dea089f15742e5b30888a038b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220185
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Remove 4kB reserved flash for pstate since we don't use persistent
state flash on zinger and flash space is limited.
BUG=none
BRANCH=none
TEST=make -j buildall. load and run zinger.
Change-Id: Id0020932ed47873d22e81516abf97b4279a7deae
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219932
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Enable flash prefetch buffer for stm32f0 chips to make for
faster CPU execution.
BUG=none
BRANCH=none
TEST=load onto samus_pd and zinger. let run for a while.
connect/disconnect AC a few times. boot samus.
Change-Id: I88c0ae67a3205987344552f5b44952f9890c8177
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219921
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Fix potential bug in ADC initialization. After setting ADEN bit to
enable ADC module, we must wait for ADRDY (ADC ready) bit before
continuing. This bug only affects a few chips, and only some of
the time.
BUG=chrome-os-partner:31978
BRANCH=none
TEST=Used a samus board where the PD MCU fails ADC initialization
quite often. Without this fix, if you reboot the PD MCU, it will
sometimes come up with all ADC's reading 0 and ADEN reading 0.
With this fix, it always boots with the ADC's working
Change-Id: Iba1d0e56006ba1ad6d9f0eee964a70ef2d0f8dcf
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219522
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vic Yang <victoryang@chromium.org>
RX DMA seems to get misaligned sometimes yielding to extra bytes before the
first byte on the wire.
in_msg=[00 00 00 03 f4 09 00 00 ...]
^ real first byte
To fix this we want to reset and reinit the SPI peripheral after every packet,
in the same place where setup_for_transaction() is called.
This bug applies to the STM32F0 line but resetting the peripheral on other STM32
ECs should not break anything.
BUG=chrome-os-partner:31390
TEST=On STM32F0:
ap# cd /sys/class/power_supply/sbs-20-000b/; while true; do grep "" * >/dev/null 2>&1; done
You should not see "SPI rx bad data" with in_msg packets that have extra bytes
in the beggining. Wait though, it might take up to a few minutes for stuff to
break.
BRANCH=None
Change-Id: If9ab93c5c9040a2c7bda33d7cc990603f1121f3f
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/217527
Reviewed-by: Randall Spangler <rspangler@chromium.org>
STM32F and STM32F0 series require an MOE bit to be set to enable PWM
output. In addition, require that the PWM alternate function # be
manually specified for STM32F0 -- there seems to be no logical mapping
here, unlike other STM32* parts.
BUG=chrome-os-partner:32089
TEST=Manual on samus-pd. Set ILIM PWM output to 50% duty cycle with pwm
driver functions, probe and verify avg. 1.62V on pin.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Icb13a153fa3eee52be938d76a6c980fe6fd2bb3e
Reviewed-on: https://chromium-review.googlesource.com/219570
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Tested-by: Alexandru Stan <amstan@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
The warning should only warn if there's an actual danger(in order to give a
clue to developers that something might be amiss). Messages like "Overriding
SPI1_NSS with SPI1_NSS on EXTI4" are just spammy. This patch makes it so it only
warns if the interrupt is different.
BUG=chrome-os-partner:31390
TEST=spam gpio_enable_interrupt(GPIO_SPI1_NSS); in a bunch of places (like
spi_event), it should not complain about the interrupt being set to the same
thing before. Whereas before it was so spammy it did not even have time to reply
to SPI.
BRANCH=None
Change-Id: I786a821eb8167e3568d0be371c4de26bb124431a
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218563
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Just after a bad data error the EC will print the packet(pretty much the whole thing):
in_msg=[02 00 0f 03 f4 09 00 00 ]
I found it very helpful when debugging SPI TX/RX to know what the EC sees.
BUG=chrome-os-partner:31390
TEST=Load spidev and send the EC bytes manually(malformed packets)
BRANCH=None
Change-Id: I037ab909076dc454379040e2e927dc6a0b5c5ea9
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218442
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Enable low power idle for samus_pd. Low power idle is only
entered when no USB PD device is connected.
BUG=chrome-os-partner:31226
BRANCH=none
TEST=load onto samus_pd, use idlestats command to verify
that we are going into deep sleep (STOP mode). Run 30 min.
and verify no watchdog reboots or anything out of ordinary.
Also, verify that host commands from EC work when going into
deep sleep by sending host commands on the EC console with
pdcmd 0 0.
Change-Id: I3e2e04e6c4c0a84e291286dbed90945847e0dfdd
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218957
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This driver can be used to access multiple usarts using an abstract
stream interface. The stream interface can also be used in drivers
for the host interface and USB console interface, providing a
consistent API across all character stream style IO.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: Icf567f0b0fa4eb0e9ad4cdb0be8edc31c937a7de
Reviewed-on: https://chromium-review.googlesource.com/209671
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Add low power idle task to stm32f0. This can be enabled
by defining CONFIG_LOW_POWER_IDLE. This low power idle
uses STOP mode to conserve power.
BUG=chrome-os-partner:31226, chrome-os-partner:28335
BRANCH=none
TEST=add #define CONFIG_LOW_POWER_IDLE to samus and use
idlestats console command to verify using deep sleep.
also #define CONFIG_FORCE_CONSOLE_RESUME and make sure
serial console works without problems when going into
deep sleep.
Change-Id: I76b0ceb8587a139faa74353d3d8efb4f689fc669
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218956
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Bug fix. Recently changed to use HSI 8MHz clock as clock source
for console UART, but the clock register was set incorrectly
for the case that the console UART is UART2.
BUG=chrome-os-partner:32170
BRANCH=none
TEST=Tested on fruitpie which is using UART2 for console.
Verified that console works.
Change-Id: Ied629eb3828e5fab911acb6a8e5f4087563ddb32
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219312
Reviewed-by: Vic Yang <victoryang@chromium.org>
When waking up from sleep, the real CPU_CLOCK is a lie for a moment(since we
cannot switch to the real clock during the first character) so the first
character will be corrupted.
The UART clock is now sourced from HSI(8MHz) which is available from the first
moment after the cpu wakes up from sleep.
BUG=None
TEST=Console should work.
When waking up(not implemented yet) it will also not lose a character
BRANCH=None
Change-Id: Ia12ed0634290f3edadfe3471b311759c3176260e
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218728
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Tested-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
Implement RTC alarm, with resolution 50us, for stm32f0. This
is useful for using low power modes and waking up after set
period of time.
BUG=chrome-os-partner:31226, chrome-os-partner:28335
BRANCH=none
TEST=tested on samus_pd with CONFIG_CMD_RTC_ALARM defined and
used rtc_alarm console command to test various timeout periods.
Change-Id: Ibabd8662cfbea654c7de387669f7be83af4fd79d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218322
Reviewed-by: Todd Broch <tbroch@chromium.org>
