#2295: cpufreq: serial ports fail after suspend/resume: rxerr: port=1 ch=0x24,
rxs=0x00000001
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords: kernel cpufreq serial gps
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------------+----------------------------------------------
Comment(by budfive):
I did some sleuthing by peeking into /dev/mem. Here's the analysis:
Before and after the suspend, all of the UART registers seem to be set
identically. This indicates that the UART module itself is likely not the
culprit. The other likely caus is the baud clock. It is likely running at
the wrong speed, causing the UART to read garbage and to report reception
errors. Further, since cpufreq is involved, it makes this possibility all
the more likely.
Looking at the clock registers, there are 2 discrepancies:
{{{
| Address | Meaning | Value before suspend | Value after suspend |
|------------+---------+----------------------+---------------------|
| 0x4C000004 | MPLLCON | 0x0002a010 | 0x0008e071 |
| 0x4C000014 | CLKDIVN | 0x00000005 | 0x00000007 |
}}}
This means that the MPLL configuration and the HCLK divider were changed.
The UART clock sources are configured with the UCONx register at
0x50000004
for UART0. The value of these registers was always 0x000003C5, indicating
a
PCLK source for the baud. PCLK is configured by the CLKDIVN register, and
in
our case is set to run at HCLK/2. So our modified HCLK affected our PCLK,
which made the baud clock in our UART run at the wrong speed. This is the
cause of the bug.
The changed MPLL configuration probably isn't good either, but it's not
causing this particular breakage at least.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2295#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac