Openmoko Bug #2295: cpufreq: serial ports fail after suspend/resume: rxerr: port=1 ch=0x24, rxs=0x00000001

Openmoko Public Trac bugs at
Thu Jun 18 09:20:48 CEST 2009

#2295: cpufreq: serial ports fail after suspend/resume: rxerr: port=1 ch=0x24,
 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
 for UART0. The value of these registers was always 0x000003C5, indicating
 PCLK source for the baud. PCLK is configured by the CLKDIVN register, and
 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: <> <>
openmoko trac

More information about the buglog mailing list