OESF | ELSI | pdaXrom | OpenZaurus | Zaurus Themes | Community Links | Ibiblio

IPB

Welcome Guest ( Log In | Register )

> Help New Kernel For Pdaxrom, zaurushw fixed but more problems ahead
louigi600
post Aug 31 2007, 12:19 AM
Post #1





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



I've been away for a month or so ... I see 2.6.22.6 is out on kernel.org ... any news for Z ?
Go to the top of the page
 
+Quote Post
 
Start new topic
Replies
louigi600
post Oct 13 2007, 09:20 AM
Post #2





Group: Members
Posts: 474
Joined: 21-May 06
Member No.: 9,928



I had a close look at the changelog and things like this have been happening (this is just the first one of intrest to the type of problem that Civil was hitting):
commit b750a09385d7c464113ae8915e63541a163fbac8
Author: Eric Miao <eric.y.miao@gmail.com>
Date: Wed Jul 18 11:40:13 2007 +0100

[ARM] 4489/1: pxa: split pxa_cpu_suspend to processor specific ones

1. split pxa_cpu_suspend to pxa25x_cpu_suspend and pxa27x_cpu_suspend
and make pxa25x_cpu_pm_enter() and pxa27x_cpu_pm_enter() to invoke
the corresponding _suspend functions, thus remove all those ugly
#ifdef .. #endif out of sleep.S

2. move the declarations of those suspend functions to pm.h

note: this is not a clean enough solution until all the pxa25x and
pxa27x specific part is further removed out of sleep.S, sleep.S is
supposed to contain generic code only

As I remember there was also cleanup on PM so the old patches need to be carefully adjusted by also looking at the functions used and even may require targeting different files if pxa specific code was moved out of the generic code.

Here is a specific chunk of the changelog concerning PM:
[ARM] 4488/1: pxa: move pxa25x/pxa27x specific code out of pm.c

1. introduce a structure pxa_cpu_pm_fns for pxa25x/pxa27x specific
operations as follows:

struct pxa_cpu_pm_fns {
int save_size;
void (*save)(unsigned long *);
void (*restore)(unsigned long *);
int (*valid)(suspend_state_t state);
void (*enter)(suspend_state_t state);
}

2. processor specific registers saving and restoring are performed
by calling the corresponding (*save) and (*restore)

3. pxa_cpu_pm_fns->save_size should be initialized to the required
size for processor specific registers saving, the allocated
memory address will be passed to (*save) and (*restore)

memory allocation happens early in pxa_pm_init(), and save_size
should be assigned prior to this (which is usually true, since
pxa_pm_init() happens in device_initcall()

4. there're some redundancies for those SLEEP_SAVE_XXX and related
macros, will be fixed later, one way possible is for the system
devices to handle the specific registers saving and restoring

BTW: 2.6.23.1 is out too but the changelog has nothing intresting for ARM.
Go to the top of the page
 
+Quote Post

Posts in this topic


Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 21st December 2014 - 12:28 AM