Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Openmoko Bug #2296: Cannot disable suspend anymore
(Openmoko Public Trac)
2. Re: Openmoko Bug #2296: Cannot disable suspend anymore
(Openmoko Public Trac)
3. Re: Openmoko Bug #2295: cpufreq: serial ports fail after
suspend/resume: rxerr: port=1 ch=0x24, rxs=0x00000001
(Openmoko Public Trac)
--- Begin Message ---
#2296: Cannot disable suspend anymore
--------------------+-------------------------------------------------------
Reporter: stiell | Owner: Nytowl
Type: defect | Status: new
Priority: normal | Milestone: Om2009
Component: Distro | Version:
Severity: normal | Keywords: Om2009 suspend
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
--------------------+-------------------------------------------------------
In Om2009 Testing 5, setting "suspend-time" to -1 in Paroli, or "Suspend
After Blank" to Off in the E17 settings, no longer disables suspend, but
instead makes the phone suspend immediately after blank. Thus, there is no
way to disable suspend. Other suspend-time values work as expected.
How to reproduce:
* In Paroli, go to ''Settings → phone'' and select ''-1'' under
''suspend-time''.
* Go back to Paroli and wait until the screen has gone completely blank.
* Touch the screen.
Expected results: The screen should light up again. The phone should not
suspend at any point.
Actual results: The phone suspends immediately after screen goes blank. If
you touch it immediately after blank, the screen may light up, but it will
show some console text and then suspend. After that, it will of course not
react to touching.
In Testing 4, this worked as expected and the phone would not suspend.
I am using a clean install of Om2009 Testing 5, dated 16-Jun-2009.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2296>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2296: Cannot disable suspend anymore
--------------------+-------------------------------------------------------
Reporter: stiell | Owner: Nytowl
Type: defect | Status: new
Priority: normal | Milestone: Om2009
Component: Distro | Version:
Severity: normal | Keywords: Om2009 suspend
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
--------------------+-------------------------------------------------------
Comment(by janvlug):
As a workaround commented out the following in
/etc/freesmartphone/oevents/rules.yaml:
# -
# trigger: IdleState()
# filters: HasAttr(status, "suspend")
# actions: Suspend()
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2296#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#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
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
