[PATCH] powerpc: fix giveup_vsx to save registers correctly
giveup_vsx didn't save the FPU and VMX regsiters. Change it to be
like giveup_fpr/altivec which save these registers.
Also update call sites where FPU and VMX are already saved to use the
original giveup_vsx (renamed to __giveup_vsx).
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
benh: for your 2.6.27 tree.
arch/powerpc/kernel/misc_64.S |8
arch/powerpc/kernel/process.c | 10 +-
arch/powerpc/kernel/signal_32.c |2 +-
arch/powerpc/kernel/signal_64.c |2 +-
include/asm-powerpc/system.h|1 +
5 files changed, 16 insertions(+), 7 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
@@ -508,12 +508,12 @@ _GLOBAL(giveup_altivec)
#ifdef CONFIG_VSX
/*
- * giveup_vsx(tsk)
- * Disable VSX for the task given as the argument,
- * and save the vector registers in its thread_struct.
+ * __giveup_vsx(tsk)
+ * Disable VSX for the task given as the argument.
+ * Does NOT save vsx registers.
* Enables the VSX for use in the kernel on return.
*/
-_GLOBAL(giveup_vsx)
+_GLOBAL(__giveup_vsx)
mfmsr r5
orisr5,r5,[EMAIL PROTECTED]
mtmsrd r5 /* enable use of VSX now */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c
@@ -159,6 +159,13 @@ void enable_kernel_vsx(void)
EXPORT_SYMBOL(enable_kernel_vsx);
#endif
+void giveup_vsx(struct task_struct *tsk)
+{
+ giveup_fpu(tsk);
+ giveup_altivec(tsk);
+ __giveup_vsx(tsk);
+}
+
void flush_vsx_to_thread(struct task_struct *tsk)
{
if (tsk-thread.regs) {
@@ -290,7 +297,8 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
if (prev-thread.regs (prev-thread.regs-msr MSR_VSX))
- giveup_vsx(prev);
+ /* VMX and FPU registers are already save here */
+ __giveup_vsx(prev);
#endif /* CONFIG_VSX */
#ifdef CONFIG_SPE
/*
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_32.c
@@ -452,7 +452,7 @@ static int save_user_regs(struct pt_regs
* contains valid data
*/
if (current-thread.used_vsr) {
- flush_vsx_to_thread(current);
+ __giveup_vsx(current);
if (copy_vsx_to_user(frame-mc_vsregs, current))
return 1;
msr |= MSR_VSX;
Index: linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/signal_64.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/signal_64.c
@@ -122,7 +122,7 @@ static long setup_sigcontext(struct sigc
* VMX data.
*/
if (current-thread.used_vsr) {
- flush_vsx_to_thread(current);
+ __giveup_vsx(current);
v_regs += ELF_NVRREG;
err |= copy_vsx_to_user(v_regs, current);
/* set MSR_VSX in the MSR value in the frame to
Index: linux-2.6-ozlabs/include/asm-powerpc/system.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/system.h
+++ linux-2.6-ozlabs/include/asm-powerpc/system.h
@@ -139,6 +139,7 @@ extern void enable_kernel_altivec(void);
extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
+extern void __giveup_vsx(struct task_struct *);
extern void giveup_vsx(struct task_struct *);
extern void enable_kernel_spe(void);
extern void giveup_spe(struct task_struct *);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
On Friday 11 July 2008, prodyut hazarika wrote: I have a version which just keeps a count of bytes copied till any fault happened. Then for any exception, I just substract this value from the total number of bytes to be copied, and store in r3 and return back. This is the common fixup code for all paths. It makes the fixup code much more readable like other architectures (eg. x86). In some cases, you need to make sure that the return value is exactly the maximum you could copy, not a little less. The current code tries to copy one byte at a time after read fault. I don't understand why that is necessary. It then clears out the destination. All these logic has made the code very unfriendly to read. I'm not sure if the code is also avoiding unaligned accesses here, which is not a problem on x86. If you access uncached memory with unaligned pointers, you get an exception and the fixup code will copy it just fine with byte accesses. 2) For read failure, why do we clear out the destination (lines 509 to 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that. All architectures should do that for copy_from_user, to avoid potential data leaks from the kernel when the data is copied back. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
Jean Delvare wrote: Hi Hans, hi Milton, snip One could make a superio driver, and create sub-devices for the IR, I2C, floppy, parallel, etc nodes. There have been proposals to do this, and this would indeed be a very good idea, but unfortunately nobody took the time to implement this properly, push it upstream and volunteer to maintain it. The problem is that you don't need just a driver, but a new subsystem, that needs to be designed and maintained. Well, I believe there have been some lightweight superio locking coordinator patches been floating around on the lm_sensors list, and I have reviewed them and then a new version was done with my issues fixed. I kinda liked the proposed solution there, it was quite simple, moved all the generic superio stuff into generic superio code, and added locking for super io access from multiple drivers, what ever happened to those patches? If were to start using those, we could actually do a request region and then never release it, as things should be. Regards, Hans ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
* Milton Miller [EMAIL PROTECTED] wrote: Hi Rusty, Ingo. Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic numbers didn't find kernel/trace/ftrace.c in -next, causing an immediate almost NULL pointer dereference in ftrace_dynamic_init. Rusty - what's going on here? Please do not change APIs like that, which cause code to crash. Either do a compatible API change, or change it over in a way that causes clear build failures, not crashes. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
Hi Chirag,
On Wed, 9 Jul 2008 21:35:43 +0530 Chirag Jog [EMAIL PROTECTED] wrote:
Hi,
This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
variables are accessed in a preempt unsafe way.
When a power box with -rt kernel is booted, multiple BUG messages are
generated BUG: init:1 task might have lost a preemption check!.
After booting a kernel with these patches applied, these messages
don't appear.
That does indeed greatly reduce BUGs display. Good. Thanks.
Tested-by: Sebastien Dugue [EMAIL PROTECTED]
Sebastien.
Also I ran the realtime tests from ltp to ensure the stability.
Signed-Off-By: Chirag [EMAIL PROTECTED]
arch/powerpc/mm/tlb_64.c | 31 ---
arch/powerpc/platforms/pseries/iommu.c | 14 ++
include/asm-powerpc/tlb.h |5 ++---
3 files changed, 28 insertions(+), 22 deletions(-)
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
===
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-09
21:29:21.0 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-09
21:30:37.0 +0530
@@ -38,7 +38,6 @@
* include/asm-powerpc/tlb.h file -- tgall
*/
DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
struct pte_freelist_batch
@@ -48,7 +47,7 @@
pgtable_free_t tables[0];
};
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
+DEFINE_PER_CPU_LOCKED(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
#define PTE_FREELIST_SIZE \
@@ -92,24 +91,21 @@
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
- /*
- * This is safe since tlb_gather_mmu has disabled preemption.
- * tlb-cpu is set by tlb_gather_mmu as well.
- */
+ int cpu;
cpumask_t local_cpumask = cpumask_of_cpu(tlb-cpu);
- struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
+ struct pte_freelist_batch **batchp =
get_cpu_var_locked(pte_freelist_cur, cpu);
if (atomic_read(tlb-mm-mm_users) 2 ||
cpus_equal(tlb-mm-cpu_vm_mask, local_cpumask)) {
pgtable_free(pgf);
- return;
+ goto cleanup;
}
if (*batchp == NULL) {
*batchp = (struct pte_freelist_batch
*)__get_free_page(GFP_ATOMIC);
if (*batchp == NULL) {
pgtable_free_now(pgf);
- return;
+ goto cleanup;
}
(*batchp)-index = 0;
}
@@ -118,6 +114,9 @@
pte_free_submit(*batchp);
*batchp = NULL;
}
+
+ cleanup:
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/*
@@ -253,13 +252,15 @@
void pte_free_finish(void)
{
- /* This is safe since tlb_gather_mmu has disabled preemption */
- struct pte_freelist_batch **batchp = __get_cpu_var(pte_freelist_cur);
+ int cpu;
+ struct pte_freelist_batch **batchp =
get_cpu_var_locked(pte_freelist_cur, cpu);
- if (*batchp == NULL)
- return;
- pte_free_submit(*batchp);
- *batchp = NULL;
+ if (*batchp) {
+ pte_free_submit(*batchp);
+ *batchp = NULL;
+ }
+
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/**
Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
===
--- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-09
21:29:21.0 +0530
+++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-09
21:29:41.0 +0530
@@ -40,18 +40,17 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
- struct ppc64_tlb_batch *tlbbatch = __get_cpu_var(ppc64_tlb_batch);
+ struct ppc64_tlb_batch *tlbbatch = get_cpu_var(ppc64_tlb_batch);
/* If there's a TLB batch pending, then we must flush it because the
* pages are going to be freed and we really don't want to have a CPU
* access a freed page because it has a stale TLB
*/
if (tlbbatch-index) {
- preempt_disable();
__flush_tlb_pending(tlbbatch);
- preempt_enable();
}
+ put_cpu_var(ppc64_tlb_batch);
pte_free_finish();
}
Index: linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c
===
--- linux-2.6.25.8-rt7.orig/arch/powerpc/platforms/pseries/iommu.c
2008-07-09 21:29:21.0 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c 2008-07-09
21:29:41.0 +0530
@@ -124,7 +124,7 @@
}
}
-static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
+static
Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
* Ingo Molnar [EMAIL PROTECTED] wrote: * Milton Miller [EMAIL PROTECTED] wrote: Hi Rusty, Ingo. Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic numbers didn't find kernel/trace/ftrace.c in -next, causing an immediate almost NULL pointer dereference in ftrace_dynamic_init. Rusty - what's going on here? Please do not change APIs like that, which cause code to crash. Either do a compatible API change, or change it over in a way that causes clear build failures, not crashes. ah, i see it from Rusty's other reply that there's going to be another version of this. Good :-) Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
On Friday 11 July 2008 03:57:53 Nathan Fontenot wrote:
Hello Chandru,
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
+ cell_t *dm, *ls, *endp, *usm;
unsigned long l, n, flags;
u64 base, size, lmb_size;
+ char buf[32], t[8];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
@@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc
if ((base + size) 0x8000ul)
size = 0x8000ul - base;
}
- lmb_add(base, size);
+ strcpy(buf, linux,usable-memory);
+ sprintf(t, %d, (int)n);
+ strcat(buf, t);
+ usm = (cell_t *)of_get_flat_dt_prop(node,
+(const char *)buf, l);
+ if (usm != NULL) {
+ endp = usm + (l / sizeof(cell_t));
+ while ((endp - usm) = (dt_root_addr_cells +
+dt_root_size_cells)) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+usm);
+ if (size == 0)
+ continue;
+ if (iommu_is_off) {
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+ }
+ lmb_add(base, size);
+ }
+
+ /* Continue with next lmb entry */
+ continue;
+ } else {
+ lmb_add(base, size);
+ }
}
I am still digging through the kexec tools but I don't think you want
the processing of the linux,usable-memory property inside of the
for (; n!= 0; --n) loop. This should be moved up so that it looks for
the linux,usable-memory property and parses it, then if it is not found
look for the ibm,dynamic-reconfiguration-memory property and parse it.
There is no need to look for the linux-usable-memory property every time
a piece of the ibm,dynamic-reconfiguration-memory property is parsed.
-Nathan
Hello Nathan,
Thanks for the review. kexec-tools adds a 'linux,usable-memory' property for
each memory range listed in the device tree. If the regions are not
crashkernel or rtas or tce regions, then it sets base and size to zero but
still adds them as linux,usable-memory property. If we look at the code
above, in a kdump kernel we don't add an lmb through lmb_add() if the regions
are not one of the mentioned above. We check for (size == 0) and continue
with next lmb if it is so. We still have the complete device tree which
kexec-tools passes in as the buffer that we are scanning here and
linux,usable-memory properties aid in making kdump kernel to see only those
memory regions that it is suppose to use. I just worked on another version
of this patch based on comments from Michael Neuling and Stephen Rothwell. I
will post it shortly.
Thanks,
Chandru
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
On Friday 11 July 2008 17:46:03 Ingo Molnar wrote: * Milton Miller [EMAIL PROTECTED] wrote: Hi Rusty, Ingo. Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic numbers didn't find kernel/trace/ftrace.c in -next, causing an immediate almost NULL pointer dereference in ftrace_dynamic_init. Rusty - what's going on here? Please do not change APIs like that, which cause code to crash. Either do a compatible API change, or change it over in a way that causes clear build failures, not crashes. To be fair, I did. Unfortunately GCC only warns about passing an int to a pointer arg, and boom. But compatible is even better. Given the number of stop_machine_run users I thought it unlikely that a new one would be introduced during the change. I was wrong, so I'll do it the Right Way. Cheers, Rusty. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
Scan for linux,usable-memory properties in case of dynamic reconfiguration
memory. Support for kexec/kdump.
Signed-off-by: Chandru Siddalingappa [EMAIL PROTECTED]
---
Patch applies on linux-next tree (patch-v2.6.26-rc9-next-20080711.gz)
arch/powerpc/kernel/prom.c | 40 +++--
arch/powerpc/mm/numa.c | 48 ---
2 files changed, 65 insertions(+), 23 deletions(-)
diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c
linux-2.6.26-rc9/arch/powerpc/kernel/prom.c
--- linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c2008-07-11
14:44:55.0 +0530
+++ linux-2.6.26-rc9/arch/powerpc/kernel/prom.c 2008-07-11 14:58:26.0
+0530
@@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *usm;
+ unsigned long l, n, flags, ranges;
u64 base, size, lmb_size;
+ char buf[32];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
@@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
or if the block is not assigned to this partition (0x8) */
if ((flags 0x80) || !(flags 0x8))
continue;
- size = lmb_size;
- if (iommu_is_off) {
+ if (iommu_is_off)
if (base = 0x8000ul)
continue;
- if ((base + size) 0x8000ul)
- size = 0x8000ul - base;
- }
- lmb_add(base, size);
+ size = lmb_size;
+
+ /*
+* Append 'n' to 'linux,usable-memory' to get special
+* properties passed in by tools like kexec-tools. Relevant
+* only if this is a kexec/kdump kernel.
+*/
+ sprintf(buf, linux,usable-memory%d, (int)n);
+ usm = of_get_flat_dt_prop(node, buf, l);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (l 2)/(dt_root_addr_cells
+ + dt_root_size_cells);
+ do {
+ if (usm != NULL) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+usm);
+ if (size == 0)
+ break;
+ }
+ if (iommu_is_off)
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+
+ lmb_add(base, size);
+ } while (--ranges);
}
lmb_dump_all();
return 0;
diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c
linux-2.6.26-rc9/arch/powerpc/mm/numa.c
--- linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c2008-07-11
14:44:55.0
+0530
+++ linux-2.6.26-rc9/arch/powerpc/mm/numa.c 2008-07-11 15:01:56.0
+0530
@@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm;
- unsigned int n, rc;
- unsigned long lmb_size, size;
+ const u32 *dm, *usm;
+ unsigned int n, rc, len, ranges;
+ unsigned long lmb_size, size, sz;
int nid;
struct assoc_arrays aa;
+ char buf[32];
+ u64 base;
n = of_get_drconf_memory(memory, dm);
if (!n)
@@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
nid = of_drconf_to_nid_single(drmem, aa);
- fake_numa_create_new_node(
- ((drmem.base_addr + lmb_size) PAGE_SHIFT),
- nid);
-
- node_set_online(nid);
-
- size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
- if (!size)
- continue;
+ /*
+* Append 'n' to 'linux,usable-memory' to get special
+* properties passed in by tools like kexec-tools. Relevant
+* only if this is a kexec/kdump kernel.
+*/
+ sprintf(buf, linux,usable-memory%d, (int)n);
+ usm = of_get_property(memory, buf, len);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (len 2) /
+(n_mem_addr_cells + n_mem_size_cells);
+
+ base = drmem.base_addr;
+ size = lmb_size
OF next: microblaze movement
Hi All, Can you review OF files which I have in microblaze pack for linux-next? Patch is available at http://kerneltrap.org/mailarchive/linux-kernel/2008/7/8/2387284 Thanks, Michal Simek ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [V2] powerpc: Xilinx: PS2: driver updates based on review
On Thu, Jul 10, 2008 at 12:34:43PM -0700, John Linn wrote:
Review comments were incorporated to improve the driver.
1. Some data was eliminated that was not needed.
2. Renaming of variables for clarity.
3. Removed unneeded type casting.
4. Changed to use dev_err rather than other I/O.
5. Merged together some functions.
6. Added kerneldoc format to functions.
Signed-off-by: Sadanand [EMAIL PROTECTED]
Signed-off-by: John Linn [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]
---
This patch is an incremental patch to be applied to
[V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver.
V2
Updated based on Peter's comments.
drivers/input/serio/xilinx_ps2.c | 207
--
1 files changed, 111 insertions(+), 96 deletions(-)
diff --git a/drivers/input/serio/xilinx_ps2.c
b/drivers/input/serio/xilinx_ps2.c
index e86f11b..86ec91c 100644
--- a/drivers/input/serio/xilinx_ps2.c
+++ b/drivers/input/serio/xilinx_ps2.c
@@ -58,23 +58,20 @@
/* Mask for all the Receive Interrupts */
#define XPS2_IPIXR_RX_ALL(XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \
- XPS2_IPIXR_RX_FULL)
+ XPS2_IPIXR_RX_FULL)
/* Mask for all the Interrupts */
#define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL
| \
- XPS2_IPIXR_WDT_TOUT)
+ XPS2_IPIXR_WDT_TOUT)
/* Global Interrupt Enable mask */
#define XPS2_GIER_GIE_MASK 0x8000
struct xps2data {
int irq;
- u32 phys_addr;
- u32 remap_size;
spinlock_t lock;
- u8 rxb; /* Rx buffer */
void __iomem *base_address; /* virt. address of control registers */
- unsigned int dfl;
+ unsigned int flags;
struct serio serio; /* serio */
};
@@ -82,8 +79,13 @@ struct xps2data {
/* XPS PS/2 data transmission calls */
//
-/*
- * xps2_recv() will attempt to receive a byte of data from the PS/2 port.
+/**
+ * xps2_recv() - attempts to receive a byte from the PS/2 port.
+ * @drvdata: pointer to ps2 device private data structure
+ * @byte:address where the read data will be copied
+ *
+ * If there is any data available in the PS/2 receiver, this functions reads
+ * the data, otherwise it returns error.
*/
static int xps2_recv(struct xps2data *drvdata, u8 *byte)
{
@@ -105,7 +107,7 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte)
/*/
static irqreturn_t xps2_interrupt(int irq, void *dev_id)
{
- struct xps2data *drvdata = (struct xps2data *)dev_id;
+ struct xps2data *drvdata = dev_id;
u32 intr_sr;
u8 c;
int status;
@@ -115,35 +117,28 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
out_be32(drvdata-base_address + XPS2_IPISR_OFFSET, intr_sr);
/* Check which interrupt is active */
- if (intr_sr XPS2_IPIXR_RX_OVF) {
- printk(KERN_ERR %s: receive overrun error\n,
- drvdata-serio.name);
- }
+ if (intr_sr XPS2_IPIXR_RX_OVF)
+ dev_err(drvdata-serio.dev.parent, receive overrun error\n);
if (intr_sr XPS2_IPIXR_RX_ERR)
- drvdata-dfl |= SERIO_PARITY;
+ drvdata-flags |= SERIO_PARITY;
if (intr_sr (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_WDT_TOUT))
- drvdata-dfl |= SERIO_TIMEOUT;
+ drvdata-flags |= SERIO_TIMEOUT;
if (intr_sr XPS2_IPIXR_RX_FULL) {
- status = xps2_recv(drvdata, drvdata-rxb);
+ status = xps2_recv(drvdata, c);
/* Error, if a byte is not received */
if (status) {
- printk(KERN_ERR
- %s: wrong rcvd byte count (%d)\n,
- drvdata-serio.name, status);
+ dev_err(drvdata-serio.dev.parent,
+ wrong rcvd byte count (%d)\n, status);
} else {
- c = drvdata-rxb;
- serio_interrupt(drvdata-serio, c, drvdata-dfl);
- drvdata-dfl = 0;
+ serio_interrupt(drvdata-serio, c, drvdata-flags);
+ drvdata-flags = 0;
}
}
- if (intr_sr XPS2_IPIXR_TX_ACK)
- drvdata-dfl = 0;
-
return IRQ_HANDLED;
}
@@ -151,8 +146,15 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
/* serio callbacks */
/***/
-/*
- * sxps2_write() sends a byte out through the PS/2 interface.
+/**
+ * sxps2_write() - sends a byte out through the PS/2 port.
+ * @pserio: pointer to the serio structure of the PS/2 port
+ * @c: data that needs to be written to the PS/2 port
+ *
+ * This function checks if the PS/2
[PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
Firstly kernel warns at set_irq_chip, and then dies completely:
Trying to install chip for IRQ-1
[ cut here ]
Badness at c00463b0 [verbose debug info unavailable]
NIP: c00463b0 LR: c00463b0 CTR: c0158e80
REGS: cf821cd0 TRAP: 0700 Not tainted
(2.6.26-rc8-next-20080704-20216-g7bcfaff-dirty)
MSR: 00029032 EE,ME,IR,DR CR: 24044042 XER: 2000
TASK = cf81f8a0[1] 'swapper' THREAD: cf82
GPR00: c00463b0 cf821d80 cf81f8a0 0024 15cb c015c1fc 4000
GPR08: c035e960 c035 c035e4b8 15cb 84044042 0fffd000
GPR16: 0fff3028 0fff6cf0 0fff8390 0ff494a0 0004 c02ef520
GPR24: cf934210 cf821dfc c02ef4f8 c035ac08
NIP [c00463b0] set_irq_chip+0x90/0x9c
LR [c00463b0] set_irq_chip+0x90/0x9c
Call Trace:
[cf821d80] [c00463b0] set_irq_chip+0x90/0x9c (unreliable)
[cf821da0] [c004641c] set_irq_chip_and_handler+0x1c/0x40
[cf821dc0] [c0005a64] irq_dispose_mapping+0x70/0x13c
[cf821df0] [c01ebf10] of_register_i2c_devices+0x124/0x504
[cf821e50] [c0276f78] 0xc0276f78
[cf821e70] [c01eba20] of_platform_device_probe+0x5c/0x84
[cf821e90] [c0160724] really_probe+0x78/0x1a8
[cf821eb0] [c016095c] __driver_attach+0x84/0x88
[cf821ed0] [c015fc14] bus_for_each_dev+0x5c/0x98
[cf821f00] [c016056c] driver_attach+0x24/0x34
[cf821f10] [c0160220] bus_add_driver+0xb4/0x1cc
[cf821f30] [c0160c4c] driver_register+0x5c/0x114
[cf821f40] [c01eb8e8] of_register_driver+0x54/0x70
[cf821f50] [c032a2e0] fsl_i2c_init+0x24/0x54
[cf821f60] [c0310244] do_one_initcall+0x34/0x198
[cf821fd0] [c03103e0] do_initcalls+0x38/0x58
[cf821fe0] [c0310464] kernel_init+0x30/0x90
[cf821ff0] [c000f944] kernel_thread+0x44/0x60
Instruction dump:
80010024 bba10014 38210020 7c0803a6 4e800020 3d20c034 3be977b8 4bac
3c60c02d 7fc4f378 386329e0 4bfd6465 0fe0 3860ffea 4bc8 9421ffe0
Trying to install type control for IRQ-1
Unable to handle kernel paging request for data at address 0x3863ce7c
Faulting instruction address: 0xc0005a68
Oops: Kernel access of bad area, sig: 11 [#1]
MPC837x RDB
Modules linked in:
NIP: c0005a68 LR: c0005a64 CTR: c0158e80
REGS: cf821d10 TRAP: 0300 Not tainted
(2.6.26-rc8-next-20080704-20216-g7bcfaff-dirty)
MSR: 9032 EE,ME,IR,DR CR: 24044042 XER: 2000
DAR: 3863ce7c, DSISR: 2000
TASK = cf81f8a0[1] 'swapper' THREAD: cf82
GPR00: c0005a64 cf821dc0 cf81f8a0 002c 1d4f c015c1fc 4000
GPR08: c035e960 3863ce74 c035e4b8 1d4f 24044042 0fffd000
GPR16: 0fff3028 0fff6cf0 0fff8390 0ff494a0 0004 c02ef520
GPR24: cf934210 cf821dfc c02ef4f8 c035ac08 cf821df8 fff8 c000d9f0
NIP [c0005a68] irq_dispose_mapping+0x74/0x13c
LR [c0005a64] irq_dispose_mapping+0x70/0x13c
Call Trace:
[cf821dc0] [c0005a64] irq_dispose_mapping+0x70/0x13c (unreliable)
[cf821df0] [c01ebf10] of_register_i2c_devices+0x124/0x504
[cf821e50] [c0276f78] 0xc0276f78
[cf821e70] [c01eba20] of_platform_device_probe+0x5c/0x84
[cf821e90] [c0160724] really_probe+0x78/0x1a8
[cf821eb0] [c016095c] __driver_attach+0x84/0x88
[cf821ed0] [c015fc14] bus_for_each_dev+0x5c/0x98
[cf821f00] [c016056c] driver_attach+0x24/0x34
[cf821f10] [c0160220] bus_add_driver+0xb4/0x1cc
[cf821f30] [c0160c4c] driver_register+0x5c/0x114
[cf821f40] [c01eb8e8] of_register_driver+0x54/0x70
[cf821f50] [c032a2e0] fsl_i2c_init+0x24/0x54
[cf821f60] [c0310244] do_one_initcall+0x34/0x198
[cf821fd0] [c03103e0] do_initcalls+0x38/0x58
[cf821fe0] [c0310464] kernel_init+0x30/0x90
[cf821ff0] [c000f944] kernel_thread+0x44/0x60
Instruction dump:
5400d97e 0f00 2f9f 41beffc8 801f0008 2f80 41beffbc 7fc3f378
3880 38a0 480409a1 813f0018 80090008 2f80 419e0014 7fe3fb78
---[ end trace 1db4087de5c456f2 ]---
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/of/of_i2c.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..95a24de 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
- continue;
- }
+ if (of_find_i2c_driver(node, info) 0)
+ goto err;
info.addr = *addr;
@@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
- irq_dispose_mapping(info.irq);
- continue;
+ goto err;
}
+ continue;
+err:
+ if (info.irq 0)
+ irq_dispose_mapping(info.irq);
}
}
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
On Thu, Jul 10, 2008 at 12:36:58PM -0400, Timur Tabi wrote: On Jul 9, 2008, at 1:22 PM, Grant Likely wrote: On Mon, Jun 30, 2008 at 5:01 PM, Jon Smirl [EMAIL PROTECTED] wrote: Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c to make i2c modules dynamically loadable by the device tree. Timur, can you please test this one on an 83xx platform? It works on 5200, but I want to make sure 83xx doesn't break before I pick it up. I'm on vacation this week, so I'll have to deal with it next week, after I've handled higher-priority issues. Kumar, is there anyone else who can test this out before the merge window opens? OTOH, it should be pretty safe. It's been tested on 5200. I could just pick it up without 8xxx testing if you're okay with it. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
Firstly kernel warns at set_irq_chip, and then dies completely:
Trying to install chip for IRQ-1
[ cut here ]
Badness at c00463b0 [verbose debug info unavailable]
[..]
Unable to handle kernel paging request for data at address 0x3863ce7c
Btw, I'm seeing this on linux-next. Just looked into the current Linus'
tree, and it seems that the bug is there too. So, this is probably should
go for 2.6.26.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
drivers/of/of_i2c.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..95a24de 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
- continue;
- }
+ if (of_find_i2c_driver(node, info) 0)
+ goto err;
info.addr = *addr;
@@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
- irq_dispose_mapping(info.irq);
- continue;
+ goto err;
}
+ continue;
+err:
+ if (info.irq 0)
+ irq_dispose_mapping(info.irq);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
--
1.5.5.4
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote: Firstly kernel warns at set_irq_chip, and then dies completely: Trying to install chip for IRQ-1 diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c index b2ccdcb..95a24de 100644 --- a/drivers/of/of_i2c.c +++ b/drivers/of/of_i2c.c @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap, if (info.irq == NO_IRQ) info.irq = -1; What is the reason that info.irq is set to -1 in the first place? This looks like another bug to me. Does something in the i2c layer depend on the -1 value? g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
On Fri, Jul 11, 2008 at 12:12:14PM -0600, Grant Likely wrote: On Thu, Jul 10, 2008 at 12:36:58PM -0400, Timur Tabi wrote: On Jul 9, 2008, at 1:22 PM, Grant Likely wrote: On Mon, Jun 30, 2008 at 5:01 PM, Jon Smirl [EMAIL PROTECTED] wrote: Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c to make i2c modules dynamically loadable by the device tree. Timur, can you please test this one on an 83xx platform? It works on 5200, but I want to make sure 83xx doesn't break before I pick it up. I'm on vacation this week, so I'll have to deal with it next week, after I've handled higher-priority issues. Kumar, is there anyone else who can test this out before the merge window opens? FWIW, they seem to work for me. At least RTC still works. p.s. [1/2] conflicts with fsl_soc.c. And these patches will conflict a bit more (now with of_i2c.c), if/when [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel kernel will oops will be applied to 2.6.26. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
On Fri, Jul 11, 2008 at 10:45:56PM +0400, Anton Vorontsov wrote: On Fri, Jul 11, 2008 at 12:12:14PM -0600, Grant Likely wrote: On Thu, Jul 10, 2008 at 12:36:58PM -0400, Timur Tabi wrote: On Jul 9, 2008, at 1:22 PM, Grant Likely wrote: On Mon, Jun 30, 2008 at 5:01 PM, Jon Smirl [EMAIL PROTECTED] wrote: Convert i2c-mpc to an of_platform driver. Utilize the code in drivers/of-i2c.c to make i2c modules dynamically loadable by the device tree. Timur, can you please test this one on an 83xx platform? It works on 5200, but I want to make sure 83xx doesn't break before I pick it up. I'm on vacation this week, so I'll have to deal with it next week, after I've handled higher-priority issues. Kumar, is there anyone else who can test this out before the merge window opens? FWIW, they seem to work for me. At least RTC still works. Good enough for me. Unless someone screams really loudly I'm going to go ahead and pick it up. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 12:23:23PM -0600, Grant Likely wrote: On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote: Firstly kernel warns at set_irq_chip, and then dies completely: Trying to install chip for IRQ-1 diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c index b2ccdcb..95a24de 100644 --- a/drivers/of/of_i2c.c +++ b/drivers/of/of_i2c.c @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap, if (info.irq == NO_IRQ) info.irq = -1; What is the reason that info.irq is set to -1 in the first place? I believe this is because of this checking mess: grep irq -r drivers/rtc/ drivers/i2c/chips/ | grep if grep define NO_IRQ -r include/ -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
Hi Grant, What is the reason that info.irq is set to -1 in the first place? This looks like another bug to me. Does something in the i2c layer depend on the -1 value? Nope, it was a bug in the i2c documentation fixed recently: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8e29da9ee8958cc17e27f4053420f1c982614793 Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
Hi Anton,
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..95a24de 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
- continue;
- }
+ if (of_find_i2c_driver(node, info) 0)
+ goto err;
info.addr = *addr;
@@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
- irq_dispose_mapping(info.irq);
- continue;
+ goto err;
}
+ continue;
+err:
+ if (info.irq 0)
+ irq_dispose_mapping(info.irq);
Shouldn't this be:
if (info.irq != NO_IRQ)
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 09:01:10PM +0200, Jochen Friedrich wrote:
Hi Grant,
What is the reason that info.irq is set to -1 in the first place? This
looks like another bug to me. Does something in the i2c layer depend on
the -1 value?
Nope, it was a bug in the i2c documentation fixed recently:
Nope? I'm looking into i2c-core.c:
.. i2c_new_device(...)
{
client-irq = info-irq;
Core will blindly pass irq, so clients should ensure that irq contains
correct value. And as far as there is no common scheme of checking that
there is no irq specified, the most safe option is -1.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8e29da9ee8958cc17e27f4053420f1c982614793
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 09:11:02PM +0200, Jochen Friedrich wrote:
Hi Anton,
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..95a24de 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, info) 0) {
- irq_dispose_mapping(info.irq);
- continue;
- }
+ if (of_find_i2c_driver(node, info) 0)
+ goto err;
info.addr = *addr;
@@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
printk(KERN_ERR
of-i2c: Failed to load driver for %s\n,
info.type);
- irq_dispose_mapping(info.irq);
- continue;
+ goto err;
}
+ continue;
+err:
+ if (info.irq 0)
+ irq_dispose_mapping(info.irq);
Shouldn't this be:
if (info.irq != NO_IRQ)
Maybe, maybe not. See
http://lkml.org/lkml/2005/11/21/211
I.e. maybe we should use if (irq). Or if we should use NO_IRQ, then we
need to fixup all the users of .irq.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 11:19:30PM +0400, Anton Vorontsov wrote: On Fri, Jul 11, 2008 at 09:11:02PM +0200, Jochen Friedrich wrote: Shouldn't this be: if (info.irq != NO_IRQ) Maybe, maybe not. See http://lkml.org/lkml/2005/11/21/211 I.e. maybe we should use if (irq). Or if we should use NO_IRQ, then we need to fixup all the users of .irq. Yes, these are definitely wrong and need to be fixed. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Fri, Jul 11, 2008 at 03:18:13PM -0600, Grant Likely wrote: On Fri, Jul 11, 2008 at 11:19:30PM +0400, Anton Vorontsov wrote: On Fri, Jul 11, 2008 at 09:11:02PM +0200, Jochen Friedrich wrote: Shouldn't this be: if (info.irq != NO_IRQ) Maybe, maybe not. See http://lkml.org/lkml/2005/11/21/211 I.e. maybe we should use if (irq). Or if we should use NO_IRQ, then we need to fixup all the users of .irq. Yes, these are definitely wrong and need to be fixed. In rc9? ;-) Something tells me that even for 2.6.27 such change would be somewhat late... -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
On Sat, Jul 12, 2008 at 01:46:14AM +0400, Anton Vorontsov wrote: On Fri, Jul 11, 2008 at 03:18:13PM -0600, Grant Likely wrote: On Fri, Jul 11, 2008 at 11:19:30PM +0400, Anton Vorontsov wrote: On Fri, Jul 11, 2008 at 09:11:02PM +0200, Jochen Friedrich wrote: Shouldn't this be: if (info.irq != NO_IRQ) Maybe, maybe not. See http://lkml.org/lkml/2005/11/21/211 I.e. maybe we should use if (irq). Or if we should use NO_IRQ, then we need to fixup all the users of .irq. Yes, these are definitely wrong and need to be fixed. In rc9? ;-) I said no such thing. :-) It agree that it is too late for .26, but I think is a reasonable goal to get fixed for 2.6.27. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Installation on a MPC5200 based custom board
On Fri, Jul 11, 2008 at 06:07:54PM -0400, Sylvain Lamontagne wrote: Greetings We are currently trying to put a Kernel 2.6.26 on a custom board based on the MPC5200 processor and the designed of the board was based on the lite5200b evaluation board. We would like to have some advice regarding the installation process for this kernel. The hardware currently work (still buggy, but work) with a kernel 2.6.23 compiled with ARCH ppc running on a U-Boot 1.1.6. For what I understand now, the ARCH ppc if kind of deprecated and we have to switch to ARCH powerpc. I'm new to the concept of device tree, do I have to modify it myself or the file wild be generated automatically ? You need to modify it yourself. I suspect that most of it will be identical to the lite5200b, but you'll need to make adjustments for things like PSC usage and PCI interrupt mappings. Should it be better for us to upgrade our version of U-Boot to 1.3.* to get the support of device tree? Currently we tried with the wrapper trick of using cuImage.lite5200b and the v1.1.6 but it doesn't seem to work. It's a good idea, but you don't need to. The cuImage target should work well after you've created a custom .dts file for your board. Also, we would like to know if we have to recompile everything on the board (U-Boot/Kernel/Busybox) since we switched ARCH from ppc to powerpc? No, you do not. We are also wondering what is the cross-compilation tools that you are using? Or do you have any good advice on a choice? Currently we are building with gcc-4.1.0-glibc-2.3.6 for ppc on an x86 host running Ubuntu 8.04 or we also have a Fedora Core 7 laptop but, I have see a kernel compilation warning regarding gcc 4.1 saying that it's known to brake the kernel. Personally, I use ELDK from Denx. Should we upgrade everything (U-Boot/Kernel/Busybox) and recreate a new Ramdisk ? No, you don't have to. Anybody know a good development tools to use with a CodeWarrior USB TAP from freescale ? The CodeWarrior IDE doesn't seems to work properly for us. I haven't used codewarrior for Linux development. The Abatron BDI-3000 works really well for me. Cheers, g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Installation on a MPC5200 based custom board
Greetings We are currently trying to put a Kernel 2.6.26 on a custom board based on the MPC5200 processor and the designed of the board was based on the lite5200b evaluation board. We would like to have some advice regarding the installation process for this kernel. The hardware currently work (still buggy, but work) with a kernel 2.6.23 compiled with ARCH ppc running on a U-Boot 1.1.6. For what I understand now, the ARCH ppc if kind of deprecated and we have to switch to ARCH powerpc. I'm new to the concept of device tree, do I have to modify it myself or the file wild be generated automatically ? Should it be better for us to upgrade our version of U-Boot to 1.3.* to get the support of device tree? Currently we tried with the wrapper trick of using cuImage.lite5200b and the v1.1.6 but it doesn't seem to work. Also, we would like to know if we have to recompile everything on the board (U-Boot/Kernel/Busybox) since we switched ARCH from ppc to powerpc? We are also wondering what is the cross-compilation tools that you are using? Or do you have any good advice on a choice? Currently we are building with gcc-4.1.0-glibc-2.3.6 for ppc on an x86 host running Ubuntu 8.04 or we also have a Fedora Core 7 laptop but, I have see a kernel compilation warning regarding gcc 4.1 saying that it's known to brake the kernel. Should we upgrade everything (U-Boot/Kernel/Busybox) and recreate a new Ramdisk ? Anybody know a good development tools to use with a CodeWarrior USB TAP from freescale ? The CodeWarrior IDE doesn't seems to work properly for us. This is a lot of questions and they maybe unclear since I'm new to all this, but if you need any more information I can provide them. Best Regards, -- Sylvain Lamontagne Software Developer Novariant Canada Ext.: 4940 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Modify MPC52xx maintainers entry to cover all MPC5xxx parts
From: Grant Likely [EMAIL PROTECTED] Linux now supports the MPC5121 part and is handled by the same maintainer. Update MAINTAINERS to reflect this. Also remove URLs which do not work or contain out of date information. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- MAINTAINERS |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 8f0ec46..c984014 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2489,13 +2489,11 @@ W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org S: Maintained -LINUX FOR POWERPC EMBEDDED MPC52XX +LINUX FOR POWERPC EMBEDDED MPC5XXX P: Sylvain Munaut M: [EMAIL PROTECTED] P: Grant Likely M: [EMAIL PROTECTED] -W: http://www.246tNt.com/mpc52xx/ -W: http://www.penguinppc.org/ L: linuxppc-dev@ozlabs.org S: Maintained ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: don't spin on sync
Push the sync below the secondary smp init hold loop and comment its purpose. This should speed up boot by reducing global traffic during the single-threaded portion of boot. Signed-off-by: Sonny Rao [EMAIL PROTECTED] Signed-off-by: Milton Miller [EMAIL PROTECTED] --- next.git/arch/powerpc/kernel/head_64.S~orig 2008-07-11 17:28:47.0 -0500 +++ next.git/arch/powerpc/kernel/head_64.S 2008-07-11 17:31:50.0 -0500 @@ -1198,7 +1198,6 @@ _GLOBAL(generic_secondary_smp_init) 3: HMT_LOW lbz r23,PACAPROCSTART(r13) /* Test if this processor should */ /* start.*/ - sync #ifndef CONFIG_SMP b 3b /* Never go on non-SMP */ @@ -1206,6 +1205,8 @@ _GLOBAL(generic_secondary_smp_init) cmpwi 0,r23,0 beq 3b /* Loop until told to go */ + sync/* order paca.run and cur_cpu_spec */ + /* See if we need to call a cpu state restore handler */ LOAD_REG_IMMEDIATE(r23, cur_cpu_spec) ld r23,0(r23) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/6] Document Freescale power management nodes, and the sleep property.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Documentation/powerpc/booting-without-of.txt | 142 +---
Documentation/powerpc/dts-bindings/fsl/pmc.txt | 63 +++
2 files changed, 163 insertions(+), 42 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/pmc.txt
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index de2e5c0..5cd1ef0 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -77,10 +77,12 @@ Table of Contents
3) OpenPIC Interrupt Controllers
4) ISA Interrupt Controllers
- VIII - Specifying GPIO information for devices
+ IX - Specifying GPIO information for devices
1) gpios property
2) gpio-controller nodes
+ X - Specifying device power management information (sleep property)
+
Appendix A - Sample SOC node for MPC8540
@@ -2422,8 +2424,8 @@ encodings listed below:
2 = high to low edge sensitive type enabled
3 = low to high edge sensitive type enabled
-VIII - Specifying GPIO information for devices
-==
+IX - Specifying GPIO information for devices
+
1) gpios property
-
@@ -2471,6 +2473,37 @@ Example of two SOC GPIO banks defined as gpio-controller
nodes:
gpio-controller;
};
+X - Specifying Device Power Management Information (sleep property)
+===
+
+Devices on SOCs often have mechanisms for placing devices into low-power
+states that are decoupled from the devices' own register blocks. Sometimes,
+this information is more complicated than a cell-index property can
+reasonably describe. Thus, each device controlled in such a manner
+may contain a sleep property which describes these connections.
+
+The sleep property consists of one or more sleep resources, each of
+which consists of a phandle to a sleep controller, followed by a
+controller-specific sleep specifier of zero or more cells.
+
+The semantics of what type of low power modes are possible are defined
+by the sleep controller. Some examples of the types of low power modes
+that may be supported are:
+
+ - Dynamic: The device may be disabled or enabled at any time.
+ - System Suspend: The device may request to be disabled or remain
+ awake during system suspend, but will not be disabled until then.
+ - Permanent: The device is disabled permanently (until the next hard
+ reset).
+
+Some devices may share a clock domain with each other, such that they should
+only be suspended when none of the devices are in use. Where reasonable,
+such nodes should be placed on a virtual bus, where the bus has the sleep
+property. If the clock domain is shared among devices that cannot be
+reasonably grouped in this manner, then create a virtual sleep controller
+(similar to an interrupt nexus, except that defining a standardized
+sleep-map should wait until its necessity is demonstrated).
+
Appendix A - Sample SOC node for MPC8540
@@ -2487,47 +2520,48 @@ not necessary as they are usually the same as the root
node.
reg = e000 3000;
bus-frequency = 0;
- [EMAIL PROTECTED] {
- reg = 24520 20;
- device_type = mdio;
- compatible = gianfar;
-
- [EMAIL PROTECTED] {
- linux,phandle = 2452000
- interrupt-parent = 4;
- interrupts = 35 1;
- reg = 0;
- device_type = ethernet-phy;
- };
-
- [EMAIL PROTECTED] {
- linux,phandle = 2452001
- interrupt-parent = 4;
- interrupts = 35 1;
- reg = 1;
- device_type = ethernet-phy;
- };
-
- [EMAIL PROTECTED] {
- linux,phandle = 2452002
- interrupt-parent = 4;
- interrupts = 35 1;
- reg = 3;
- device_type = ethernet-phy;
- };
-
- };
-
[EMAIL PROTECTED] {
- #size-cells = 0;
+ #address-cells = 1;
+ #size-cells = 1;
device_type = network;
model = TSEC;
- compatible = gianfar;
+ compatible = gianfar, simple-bus;
reg = 24000 1000;
[PATCH 4/6] Add fsl,magic-packet to, and clean up, the gianfar binding.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 31 +--
1 files changed, 12 insertions(+), 19 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
index 583ef6b..cf55fa4 100644
--- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/tsec.txt
@@ -24,46 +24,39 @@ Example:
* Gianfar-compatible ethernet nodes
-Required properties:
+Properties:
- device_type : Should be network
- model : Model of the device. Can be TSEC, eTSEC, or FEC
- compatible : Should be gianfar
- reg : Offset and length of the register set for the device
- - mac-address : List of bytes representing the ethernet address of
+ - local-mac-address : List of bytes representing the ethernet address of
this controller
- - interrupts : a b where a is the interrupt number and b is a
-field that represents an encoding of the sense and level
-information for the interrupt. This should be encoded based on
-the information in section 2) depending on the type of interrupt
-controller you have.
- - interrupt-parent : the phandle for the interrupt controller that
-services interrupts for this device.
+ - interrupts : For FEC devices, the first interrupt is the device's
+interrupt. For TSEC and eTSEC devices, the first interrupt is
+transmit, the second is receive, and the third is error.
- phy-handle : The phandle for the PHY connected to this ethernet
controller.
- fixed-link : a b c d e where a is emulated phy id - choose any,
but unique to the all specified fixed-links, b is duplex - 0 half,
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
-
-Recommended properties:
-
- phy-connection-type : a string naming the controller/PHY interface type,
i.e., mii (default), rmii, gmii, rgmii, rgmii-id, sgmii,
tbi, or rtbi. This property is only really needed if the connection
is of type rgmii-id, as all other connection types are detected by
hardware.
-
+ - fsl,magic-packet : If present, indicates that the hardware supports
+waking up via magic packet.
Example:
[EMAIL PROTECTED] {
- #size-cells = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
- reg = 24000 1000;
- mac-address = [ 00 E0 0C 00 73 00 ];
- interrupts = d 3 e 3 12 3;
- interrupt-parent = 4;
- phy-handle = 2452000
+ reg = 0x24000 0x1000;
+ local-mac-address = [ 00 E0 0C 00 73 00 ];
+ interrupts = 29 2 30 2 34 2;
+ interrupt-parent = mpic;
+ phy-handle = phy0
};
--
1.5.6.rc1.6.gc53ad.dirty
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/6] gianfar: Add magic packet and suspend/resume support.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c |3 +
drivers/net/gianfar.c | 118 -
drivers/net/gianfar.h | 12 -
drivers/net/gianfar_ethtool.c | 41 +-
include/linux/fsl_devices.h |1 +
5 files changed, 169 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index ca54563..2fcd714 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -357,6 +357,9 @@ static int __init gfar_of_init(void)
else
gfar_data.interface = PHY_INTERFACE_MODE_MII;
+ if (of_get_property(np, fsl,magic-packet, NULL))
+ gfar_data.device_flags |=
FSL_GIANFAR_DEV_HAS_MAGIC_PACKET;
+
ph = of_get_property(np, phy-handle, NULL);
if (ph == NULL) {
u32 *fixed_link;
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 25bdd08..f218dcc 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -142,6 +142,7 @@ static int gfar_clean_tx_ring(struct net_device *dev);
static int gfar_process_frame(struct net_device *dev, struct sk_buff *skb, int
length);
static void gfar_vlan_rx_register(struct net_device *netdev,
struct vlan_group *grp);
+static void gfar_halt_nodisable(struct net_device *dev);
void gfar_halt(struct net_device *dev);
void gfar_start(struct net_device *dev);
static void gfar_clear_exact_match(struct net_device *dev);
@@ -216,6 +217,7 @@ static int gfar_probe(struct platform_device *pdev)
spin_lock_init(priv-txlock);
spin_lock_init(priv-rxlock);
+ spin_lock_init(priv-bflock);
platform_set_drvdata(pdev, dev);
@@ -393,6 +395,103 @@ static int gfar_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gfar_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct gfar_private *priv = netdev_priv(dev);
+ unsigned long flags;
+ u32 tempval;
+
+ int magic_packet = priv-wol_en
+ (priv-einfo-device_flags FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+
+ netif_device_detach(dev);
+
+ if (netif_running(dev)) {
+ spin_lock_irqsave(priv-txlock, flags);
+ spin_lock(priv-rxlock);
+
+ gfar_halt_nodisable(dev);
+
+ /* Disable Tx, and Rx if wake-on-LAN is disabled. */
+ tempval = gfar_read(priv-regs-maccfg1);
+
+ tempval = ~MACCFG1_TX_EN;
+
+ if (!magic_packet)
+ tempval = ~MACCFG1_RX_EN;
+
+ gfar_write(priv-regs-maccfg1, tempval);
+
+ spin_unlock(priv-rxlock);
+ spin_unlock_irqrestore(priv-txlock, flags);
+
+#ifdef CONFIG_GFAR_NAPI
+ napi_disable(priv-napi);
+#endif
+
+ if (magic_packet) {
+ /* Enable interrupt on Magic Packet */
+ gfar_write(priv-regs-imask, IMASK_MAG);
+
+ /* Enable Magic Packet mode */
+ tempval = gfar_read(priv-regs-maccfg2);
+ tempval |= MACCFG2_MPEN;
+ gfar_write(priv-regs-maccfg2, tempval);
+ } else {
+ phy_stop(priv-phydev);
+ }
+ }
+
+ return 0;
+}
+
+static int gfar_resume(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct gfar_private *priv = netdev_priv(dev);
+ unsigned long flags;
+ u32 tempval;
+ int magic_packet = priv-wol_en
+ (priv-einfo-device_flags FSL_GIANFAR_DEV_HAS_MAGIC_PACKET);
+
+ if (!netif_running(dev)) {
+ netif_device_attach(dev);
+ return 0;
+ }
+
+ if (!magic_packet priv-phydev)
+ phy_start(priv-phydev);
+
+ /* Disable Magic Packet mode, in case something
+* else woke us up.
+*/
+
+ spin_lock_irqsave(priv-txlock, flags);
+ spin_lock(priv-rxlock);
+
+ tempval = gfar_read(priv-regs-maccfg2);
+ tempval = ~MACCFG2_MPEN;
+ gfar_write(priv-regs-maccfg2, tempval);
+
+ gfar_start(dev);
+
+ spin_unlock(priv-rxlock);
+ spin_unlock_irqrestore(priv-txlock, flags);
+
+ netif_device_attach(dev);
+
+#ifdef CONFIG_GFAR_NAPI
+ napi_enable(priv-napi);
+#endif
+
+ return 0;
+}
+#else
+#define gfar_suspend NULL
+#define gfar_resume NULL
+#endif
/* Reads the controller's registers to determine what interface
* connects it to the PHY.
@@ -550,7 +649,7 @@ static void init_registers(struct net_device *dev)
/* Halt the receive and transmit queues */
-void gfar_halt(struct net_device *dev)
+static void gfar_halt_nodisable(struct
[PATCH 6/6] mpc8313erdb: Add power management to the device tree.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8313erdb.dts | 241 +++--
1 files changed, 171 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 3664fb5..2a94ae0 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -109,18 +109,38 @@
reg = 0x200 0x100;
};
- [EMAIL PROTECTED] {
+ sleep-nexus {
#address-cells = 1;
- #size-cells = 0;
- cell-index = 0;
- compatible = fsl-i2c;
- reg = 0x3000 0x100;
- interrupts = 14 0x8;
- interrupt-parent = ipic;
- dfsrr;
- [EMAIL PROTECTED] {
- compatible = dallas,ds1339;
- reg = 0x68;
+ #size-cells = 1;
+ compatible = simple-bus;
+ sleep = pmc 0x0300;
+ ranges;
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 14 0x8;
+ interrupt-parent = ipic;
+ dfsrr;
+ [EMAIL PROTECTED] {
+ compatible = dallas,ds1339;
+ reg = 0x68;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,sec2.2, fsl,sec2.1,
+fsl,sec2.0;
+ reg = 0x3 0x1;
+ interrupts = 11 0x8;
+ interrupt-parent = ipic;
+ fsl,num-channels = 1;
+ fsl,channel-fifo-len = 24;
+ fsl,exec-units-mask = 0x4c;
+ fsl,descriptor-types-mask = 0x0122003f;
};
};
@@ -188,37 +208,44 @@
interrupt-parent = ipic;
interrupts = 38 0x8;
phy_type = utmi_wide;
+ sleep = pmc 0x0030;
};
- [EMAIL PROTECTED] {
+ enet0: [EMAIL PROTECTED] {
#address-cells = 1;
- #size-cells = 0;
- compatible = fsl,gianfar-mdio;
- reg = 0x24520 0x20;
- phy1: [EMAIL PROTECTED] {
- interrupt-parent = ipic;
- interrupts = 19 0x8;
- reg = 0x1;
- device_type = ethernet-phy;
- };
- phy4: [EMAIL PROTECTED] {
- interrupt-parent = ipic;
- interrupts = 20 0x8;
- reg = 0x4;
- device_type = ethernet-phy;
- };
- };
+ #size-cells = 1;
+ sleep = pmc 0x2000;
+ ranges;
- enet0: [EMAIL PROTECTED] {
cell-index = 0;
device_type = network;
model = eTSEC;
- compatible = gianfar;
+ compatible = gianfar, simple-bus;
reg = 0x24000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 37 0x8 36 0x8 35 0x8;
interrupt-parent = ipic;
phy-handle = phy1 ;
+ fsl,magic-packet;
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl,gianfar-mdio;
+ reg = 0x24520 0x20;
+ phy1: [EMAIL PROTECTED] {
+ interrupt-parent = ipic;
+ interrupts = 19 0x8;
+ reg = 0x1;
+ device_type = ethernet-phy;
+ };
+ phy4: [EMAIL PROTECTED] {
+
[PATCH 3/6] mpc83xx: Power Management support
Basic PM support for 83xx. Standby is implemented as sleep. Suspend-to-RAM is implemented as deep sleep (with the processor turned off) on 831x. Signed-off-by: Scott Wood [EMAIL PROTECTED] --- arch/powerpc/Kconfig |2 +- arch/powerpc/platforms/83xx/Makefile |1 + arch/powerpc/platforms/83xx/suspend-asm.S | 533 + arch/powerpc/platforms/83xx/suspend.c | 388 + arch/powerpc/sysdev/fsl_soc.h |1 + arch/powerpc/sysdev/ipic.c| 71 include/asm-powerpc/reg.h |4 + include/linux/fsl_devices.h |6 + 8 files changed, 1005 insertions(+), 1 deletions(-) create mode 100644 arch/powerpc/platforms/83xx/suspend-asm.S create mode 100644 arch/powerpc/platforms/83xx/suspend.c diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index f2a0f50..c22a7bf 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -192,7 +192,7 @@ config ARCH_HIBERNATION_POSSIBLE config ARCH_SUSPEND_POSSIBLE def_bool y - depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 + depends on ADB_PMU || PPC_EFIKA || PPC_LITE5200 || PPC_83xx config PPC_DCR_NATIVE bool diff --git a/arch/powerpc/platforms/83xx/Makefile b/arch/powerpc/platforms/83xx/Makefile index f331fd7..32c7ad1 100644 --- a/arch/powerpc/platforms/83xx/Makefile +++ b/arch/powerpc/platforms/83xx/Makefile @@ -3,6 +3,7 @@ # obj-y := misc.o usb.o obj-$(CONFIG_PCI) += pci.o +obj-$(CONFIG_SUSPEND) += suspend.o suspend-asm.o obj-$(CONFIG_MPC831x_RDB) += mpc831x_rdb.o obj-$(CONFIG_MPC832x_RDB) += mpc832x_rdb.o obj-$(CONFIG_MPC834x_MDS) += mpc834x_mds.o diff --git a/arch/powerpc/platforms/83xx/suspend-asm.S b/arch/powerpc/platforms/83xx/suspend-asm.S new file mode 100644 index 000..1930543 --- /dev/null +++ b/arch/powerpc/platforms/83xx/suspend-asm.S @@ -0,0 +1,533 @@ +/* + * Enter and leave deep sleep state on MPC83xx + * + * Copyright (c) 2006-2008 Freescale Semiconductor, Inc. + * Author: Scott Wood [EMAIL PROTECTED] + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + */ + +#include asm/page.h +#include asm/ppc_asm.h +#include asm/reg.h +#include asm/asm-offsets.h + +#define SS_MEMSAVE 0x00 /* First 8 bytes of RAM */ +#define SS_HID 0x08 /* 3 HIDs */ +#define SS_IABR0x14 /* 2 IABRs */ +#define SS_IBCR0x1c +#define SS_DABR0x20 /* 2 DABRs */ +#define SS_DBCR0x28 +#define SS_SP 0x2c +#define SS_SR 0x30 /* 16 segment registers */ +#define SS_R2 0x70 +#define SS_MSR 0x74 +#define SS_SDR10x78 +#define SS_LR 0x7c +#define SS_SPRG0x80 /* 4 SPRGs */ +#define SS_DBAT0x90 /* 8 DBATs */ +#define SS_IBAT0xd0 /* 8 IBATs */ +#define SS_TB 0x110 +#define SS_CR 0x118 +#define SS_GPREG 0x11c /* r12-r31 */ +#define STATE_SAVE_SIZE 0x16c + + .section .data + .align 5 + +mpc83xx_sleep_save_area: + .space STATE_SAVE_SIZE +immrbase: + .long 0 + + .section .text + .align 5 + + /* r3 = physical address of IMMR */ +_GLOBAL(mpc83xx_enter_deep_sleep) + lis r4, [EMAIL PROTECTED] + stw r3, [EMAIL PROTECTED](r4) + + /* The first 2 words of memory are used to communicate with the +* bootloader, to tell it how to resume. +* +* The first word is the magic number 0xf5153ae5, and the second +* is the pointer to mpc83xx_deep_resume. +* +* The original content of these two words is saved in SS_MEMSAVE. +*/ + + lis r3, [EMAIL PROTECTED] + ori r3, r3, [EMAIL PROTECTED] + + lis r4, [EMAIL PROTECTED] + lwz r5, 0(r4) + lwz r6, 4(r4) + + stw r5, SS_MEMSAVE+0(r3) + stw r6, SS_MEMSAVE+4(r3) + + mfspr r5, SPRN_HID0 + mfspr r6, SPRN_HID1 + mfspr r7, SPRN_HID2 + + stw r5, SS_HID+0(r3) + stw r6, SS_HID+4(r3) + stw r7, SS_HID+8(r3) + + mfspr r4, SPRN_IABR + mfspr r5, SPRN_IABR2 + mfspr r6, SPRN_IBCR + mfspr r7, SPRN_DABR + mfspr r8, SPRN_DABR2 + mfspr r9, SPRN_DBCR + + stw r4, SS_IABR+0(r3) + stw r5, SS_IABR+4(r3) + stw r6, SS_IBCR(r3) + stw r7, SS_DABR+0(r3) + stw r8, SS_DABR+4(r3) + stw r9, SS_DBCR(r3) + + mfspr r4, SPRN_SPRG0 + mfspr r5, SPRN_SPRG1 + mfspr r6, SPRN_SPRG2 + mfspr r7, SPRN_SPRG3 + mfsdr1 r8 + + stw r4, SS_SPRG+0(r3) + stw r5, SS_SPRG+4(r3) + stw r6, SS_SPRG+8(r3) + stw r7,
Re: Updates to powerpc.git
What is your intent with the 'master' branch? I hope you do NOT plan on ever rebasing it. I assume if a patch gets into master and we drop it you'll do a git-revert of it? I'll try as much as possible. But I'll keep the option open. next is the one that should never be rebased I'd say. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix problems with 32bit PPC's running with more than 2GB of RAM
Are you *sure* you can see all 4GB? I thought we lost some of the 32- bit PCI address space for PCI IO.. Disclaimer: I'm no expert on PCI :) You are right. I didn't think that through when I replied. We do lose some of it for MMIO (not IO). So we cannot really go all the way to 4G because we can't DMA to all of it, right. FYI, I'm *very* close to having swiotlb fully functional on powerpc to support larger RAM - I am able to boot with 6GB on 8641 right now. There are some bugs that I'm still shaking out - I hope to push this out in the next couple of weeks. That won't make .27 then ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Updates to powerpc.git
On Sat, Jul 12, 2008 at 01:30:58PM +1000, Benjamin Herrenschmidt wrote: What is your intent with the 'master' branch? I hope you do NOT plan on ever rebasing it. I assume if a patch gets into master and we drop it you'll do a git-revert of it? I'll try as much as possible. But I'll keep the option open. next is the one that should never be rebased I'd say. I'm cool with that. As long as I've got something stable to commit on top of. :-) g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Updates to powerpc.git
On Wed, 2008-07-09 at 09:18 -0400, Josh Boyer wrote: If you want to use your master branch as a place for experimental stuff, that's fine by me. But you'll want to keep next separate from it so it's as clean as possible for those trying to track what is definitely going into the next release. Yes. The idea is that next stays clean. If it were up to me (which it's not), I would have master just track Linus, next track what's going into the next release, and bleeding or experimental track stuff that isn't fully vetted yet. I might start doing that with my tree in the very near future. Why keeping a branch to track linus in my public tree ? I have plenty of these locally :-) Also, Paul is pretty good about not rebasing his branches when at all possible, and I suspect that's why his master and next were often the same. It makes life lots easier for the sub-maintainers and anyone trying to track against the tree. I humbly beg you to keep that going. Yes. I intend to stay on that line, but as I'm new to the job, mistake are more likely to happen. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: manual merge of the powerpc tree
On Fri, 2008-07-11 at 21:01 +0200, Bartlomiej Zolnierkiewicz wrote: Since I haven't heard back from Ben [1] on ide-pmac/media-bay IRQ issue I took another look at ide-pmac patches and I think that it should be possible to rework them in such way that consecutive ide patches ( 100) won't depend on ide-pmac: media-bay support fixes (take 4) patch. This would allow us to re-schedule it to 2.6.28 (which is probably what we want because 2.6.26 is probably just around the corner and we will be pretty busy with 2.6.27 merge window soon). Ben, what's your opinion? [1] which doesn't surprise me given his new responsibilities ;) That and I just moved house... been hectic lately. I'll give another shot at the IRQ issues early next week, and if it still doesn't work, we'll postpone. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/5] spi: Add OF binding support for SPI busses
On Wed, Jul 02, 2008 at 11:02:23PM -0400, Jon Smirl wrote: On 7/2/08, Grant Likely [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] This patch adds support for populating an SPI bus based on data in the OF device tree. This is useful for powerpc platforms which use the device tree instead of discrete code for describing platform layout. Signed-off-by: Grant Likely [EMAIL PROTECTED] --- + /* Select device driver */ + sprop = of_get_property(nc, linux,modalias, len); + if (sprop len 0) + strncpy(spi-modalias, sprop, KOBJ_NAME_LEN); + else + strncpy(spi-modalias, spidev, KOBJ_NAME_LEN); You're missing a request_module(%s, info.type) to make sure the module is loaded. It might make sense to share code with of_find_i2c_driver() so we have a common way of guessing module names. You're right. I've refactored the i2c code to make it usable by SPI also. I'll post the new patch series this evening. g. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
