* Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Kumar Gala @ 2008-04-30 21:49 UTC (permalink / raw)
To: benh
Cc: Andrew Morton, htejun, Jeff Garzik, Greg KH, linux-kernel,
Emilian.Medve, linuxppc-dev
In-Reply-To: <1209591750.18023.233.camel@pasglop>
On Apr 30, 2008, at 4:42 PM, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote:
>> From: Emil Medve <Emilian.Medve@Freescale.com>
>>
>> We provide an ioremap_flags so provide a coresphonding
>> devm_ioremap_flags.
>>
>> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> ---
>>
>> Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
>>
>> Which tree should this go through, powerpc.git?
>
> Let's call it ioremap_prot instead please. I'm about to change
> ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument
> unsigned long for now (it can be argued it should be a pgprot but that
> hasn't been sorted out completely).
No problem. I've always wondered why ioremap_* aren't better
specified by generic code.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] Set lower flag bits in regs->trap to indicate debug level exception
From: Kumar Gala @ 2008-04-30 21:49 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209591811.18023.234.camel@pasglop>
On Apr 30, 2008, at 4:43 PM, Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote:
>> We use the low bits of regs->trap as flag bits. We already indicate
>> critical and machine check level exceptions via this mechanism.
>> Extend it
>> to indicate debug level exceptions.
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>
> Ack.
that was the easy one :)
- k
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Benjamin Herrenschmidt @ 2008-04-30 21:42 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, htejun, Jeff Garzik, Greg KH, linux-kernel,
Emilian.Medve, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804301106010.22992@blarg.am.freescale.net>
On Wed, 2008-04-30 at 11:08 -0500, Kumar Gala wrote:
> From: Emil Medve <Emilian.Medve@Freescale.com>
>
> We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
>
> Which tree should this go through, powerpc.git?
Let's call it ioremap_prot instead please. I'm about to change
ioremap_flags to ioremap_prot anyways. Keep the flags/prot argument
unsigned long for now (it can be argued it should be a pgprot but that
hasn't been sorted out completely).
Cheers,
Ben.
> - k
>
> arch/powerpc/lib/Makefile | 1 +
> arch/powerpc/lib/devres.c | 33 +++++++++++++++++++++++++++++++++
> include/asm-powerpc/io.h | 8 +++++++-
> include/linux/io.h | 1 +
> lib/devres.c | 2 +-
> 5 files changed, 43 insertions(+), 2 deletions(-)
> create mode 100644 arch/powerpc/lib/devres.c
>
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index 4bb023f..f1d2cdc 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_SMP) += locks.o
> endif
>
> obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
> +obj-$(CONFIG_HAS_IOMEM) += devres.o
> diff --git a/arch/powerpc/lib/devres.c b/arch/powerpc/lib/devres.c
> new file mode 100644
> index 0000000..b73c64b
> --- /dev/null
> +++ b/arch/powerpc/lib/devres.c
> @@ -0,0 +1,33 @@
> +#include <linux/device.h> /* devres_*(), devm_ioremap_release() */
> +#include <linux/io.h> /* ioremap_flags() */
> +#include <linux/module.h> /* EXPORT_SYMBOL() */
> +
> +/**
> + * devm_ioremap_flags - Managed ioremap_flags()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + * @flags: Page flags
> + *
> + * Managed ioremap_flags(). Map is automatically unmapped on driver
> + * detach.
> + */
> +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
> + size_t size, unsigned long flags)
> +{
> + void __iomem **ptr, *addr;
> +
> + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + addr = ioremap_flags(offset, size, flags);
> + if (addr) {
> + *ptr = addr;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_flags);
> diff --git a/include/asm-powerpc/io.h b/include/asm-powerpc/io.h
> index afae069..3b8c334 100644
> --- a/include/asm-powerpc/io.h
> +++ b/include/asm-powerpc/io.h
> @@ -2,7 +2,7 @@
> #define _ASM_POWERPC_IO_H
> #ifdef __KERNEL__
>
> -/*
> +/*
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> * as published by the Free Software Foundation; either version
> @@ -18,6 +18,9 @@ extern int check_legacy_ioport(unsigned long base_port);
> #define _PNPWRP 0xa79
> #define PNPBIOS_BASE 0xf000
>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +
> #include <linux/compiler.h>
> #include <asm/page.h>
> #include <asm/byteorder.h>
> @@ -744,6 +747,9 @@ static inline void * bus_to_virt(unsigned long address)
>
> #define clrsetbits_8(addr, clear, set) clrsetbits(8, addr, clear, set)
>
> +void __iomem *devm_ioremap_flags(struct device *dev, resource_size_t offset,
> + size_t size, unsigned long flags);
> +
> #endif /* __KERNEL__ */
>
> #endif /* _ASM_POWERPC_IO_H */
> diff --git a/include/linux/io.h b/include/linux/io.h
> index 831f57c..7a390cf 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -58,6 +58,7 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
> }
> #endif
>
> +void devm_ioremap_release(struct device *dev, void *res);
> void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
> unsigned long size);
> void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
> diff --git a/lib/devres.c b/lib/devres.c
> index 26c87c4..72c8909 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -2,7 +2,7 @@
> #include <linux/io.h>
> #include <linux/module.h>
>
> -static void devm_ioremap_release(struct device *dev, void *res)
> +void devm_ioremap_release(struct device *dev, void *res)
> {
> iounmap(*(void __iomem **)res);
> }
^ permalink raw reply
* Re: [PATCH] [POWERPC] Set lower flag bits in regs->trap to indicate debug level exception
From: Benjamin Herrenschmidt @ 2008-04-30 21:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804300544370.7714@blarg.am.freescale.net>
On Wed, 2008-04-30 at 05:44 -0500, Kumar Gala wrote:
> We use the low bits of regs->trap as flag bits. We already indicate
> critical and machine check level exceptions via this mechanism. Extend it
> to indicate debug level exceptions.
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Ack.
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Benjamin Herrenschmidt @ 2008-04-30 21:18 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev list
In-Reply-To: <4818C33F.60007@am.sony.com>
On Wed, 2008-04-30 at 12:06 -0700, Geoff Levand wrote:
> > booting 2.6.25 with a ps3_defconfig and that doesn't work neither
> > (though at least when doing the later, I do get a black screen & no
> > sync, like of ps3fb failed monitor detection, while with current
> > upstream, I just get the last kexec messages and nothing happens).
>
>
> This should work. You are the first to report a problem with
> 2.6.25. Could you double check your build, and if you still have
> trouble, put your vmlinux somewhere I can get it?
I'll dbl check today. It could be bad monitor detection...
> OK, I'll try it with the upstream kernel from last week and report
> within the next day or so.
Thanks.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2008-04-30 21:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <2af4cf23ed3fc48c87b50a5f63d868d7@kernel.crashing.org>
On Wed, Apr 30, 2008 at 11:01:47PM +0200, Segher Boessenkool wrote:
> >>3. The style in all the assembly code is not to have spaces after
> >>commas separating instruction operands.
> >
> >I'll do that if that's what is prefered, but how did that come about as
> >the style used? It's different from what we do in C,
>
> But this isn't C code, it's assembler code.
Enh. It's a comma-delineated list in both cases.
> PowerPC assembler code (and most other assembler code) doesn't use
> spaces here usually.
Looking at other arches, it seems pretty evenly split.
> >and adding the space helps readability in asm as well...
>
> Many people disagree ;-)
Compressionhelpsreadability?
> Anyway, it's better to keep a consistent style, whatever that style
> is, don't you agree?
Not if it's GNU-style. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Segher Boessenkool @ 2008-04-30 21:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <20080430172254.GA28169@ld0162-tx32.am.freescale.net>
>> 3. The style in all the assembly code is not to have spaces after
>> commas separating instruction operands.
>
> I'll do that if that's what is prefered, but how did that come about as
> the style used? It's different from what we do in C,
But this isn't C code, it's assembler code. PowerPC assembler code
(and most other assembler code) doesn't use spaces here usually.
> and adding the
> space helps readability in asm as well...
Many people disagree ;-)
Anyway, it's better to keep a consistent style, whatever that style
is, don't you agree?
Segher
^ permalink raw reply
* [Cbe-oss-dev] [PATCH] Updated: Reworked Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-30 20:35 UTC (permalink / raw)
To: linuxppc-dev, cbe-oss-dev, linux-kernel, Arnd Bergmann,
oprofile-list
This is a reworked patch to fix the SPU data storage. Currently, the
SPU escape sequences and program counter data is being added directly
into the kernel buffer without holding the buffer_mutex lock. This
patch changes how the data is stored. A new function,
oprofile_add_value, is added into the oprofile driver to allow adding
generic data to the per cpu buffers. This enables a series of calls
to the oprofile_add_value to enter the needed SPU escape sequences
and SPU program data into the kernel buffer via the per cpu buffers
without any additional processing. The oprofile_add_value function is
generic so it could be used by other architecures as well provided
the needed postprocessing was added to opreport.
Finally, this patch backs out the changes previously added to the
oprofile generic code for handling the architecture specific
ops.sync_start and ops.sync_stop that allowed the architecture
to skip the per CPU buffer creation.
Signed-off-by: Carl Love <carll@us.ibm.com>
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
===================================================================
--- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/pr_util.h
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/pr_util.h
@@ -20,11 +20,6 @@
#include <asm/cell-regs.h>
#include <asm/spu.h>
-/* Defines used for sync_start */
-#define SKIP_GENERIC_SYNC 0
-#define SYNC_START_ERROR -1
-#define DO_GENERIC_SYNC 1
-
struct spu_overlay_info { /* map of sections within an SPU overlay */
unsigned int vma; /* SPU virtual memory address from elf */
unsigned int size; /* size of section from elf */
@@ -85,7 +80,7 @@ void stop_spu_profiling(void);
int spu_sync_start(void);
/* remove the hooks */
-int spu_sync_stop(void);
+void spu_sync_stop(void);
/* Record SPU program counter samples to the oprofile event buffer. */
void spu_sync_buffer(int spu_num, unsigned int *samples,
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
===================================================================
---
Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -31,11 +31,12 @@
#define RELEASE_ALL 9999
-static DEFINE_SPINLOCK(buffer_lock);
+static DEFINE_SPINLOCK(add_value_lock);
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
int spu_prof_num_nodes;
int last_guard_val[MAX_NUMNODES * 8];
+static int spu_ctx_sw_seen[MAX_NUMNODES * 8];
/* Container for caching information about an active SPU task. */
struct cached_info {
@@ -289,6 +290,7 @@ static int process_context_switch(struct
int retval;
unsigned int offset = 0;
unsigned long spu_cookie = 0, app_dcookie;
+ int cpu_buf;
retval = prepare_cached_spu_info(spu, objectId);
if (retval)
@@ -303,17 +305,28 @@ static int process_context_switch(struct
goto out;
}
- /* Record context info in event buffer */
- spin_lock_irqsave(&buffer_lock, flags);
- add_event_entry(ESCAPE_CODE);
- add_event_entry(SPU_CTX_SWITCH_CODE);
- add_event_entry(spu->number);
- add_event_entry(spu->pid);
- add_event_entry(spu->tgid);
- add_event_entry(app_dcookie);
- add_event_entry(spu_cookie);
- add_event_entry(offset);
- spin_unlock_irqrestore(&buffer_lock, flags);
+ /* Record context info in event buffer. Note, there are 4x more
+ * SPUs then CPUs. Map the SPU events/data for a given SPU to
+ * the same CPU buffer. Need to ensure the cntxt switch data and
+ * samples stay in order.
+ */
+ cpu_buf = spu->number >> 2;
+ spin_lock_irqsave(&add_value_lock, flags);
+ oprofile_add_value(ESCAPE_CODE, cpu_buf);
+ oprofile_add_value(SPU_CTX_SWITCH_CODE, cpu_buf);
+ oprofile_add_value(spu->number, cpu_buf);
+ oprofile_add_value(spu->pid, cpu_buf);
+ oprofile_add_value(spu->tgid, cpu_buf);
+ oprofile_add_value(app_dcookie, cpu_buf);
+ oprofile_add_value(spu_cookie, cpu_buf);
+ oprofile_add_value(offset, cpu_buf);
+
+ /* Set flag to indicate SPU PC data can now be written out. If
+ * the SPU program counter data is seen before an SPU context
+ * record is seen, the postprocessing will fail.
+ */
+ spu_ctx_sw_seen[spu->number] = 1;
+ spin_unlock_irqrestore(&add_value_lock, flags);
smp_wmb(); /* insure spu event buffer updates are written */
/* don't want entries intermingled... */
out:
@@ -333,7 +346,6 @@ static int spu_active_notify(struct noti
unsigned long flags;
struct spu *the_spu = data;
- pr_debug("SPU event notification arrived\n");
if (!val) {
spin_lock_irqsave(&cache_lock, flags);
retval = release_cached_info(the_spu->number);
@@ -363,38 +375,38 @@ static int number_of_online_nodes(void)
/* The main purpose of this function is to synchronize
* OProfile with SPUFS by registering to be notified of
* SPU task switches.
- *
- * NOTE: When profiling SPUs, we must ensure that only
- * spu_sync_start is invoked and not the generic sync_start
- * in drivers/oprofile/oprof.c. A return value of
- * SKIP_GENERIC_SYNC or SYNC_START_ERROR will
- * accomplish this.
*/
int spu_sync_start(void)
{
int k;
- int ret = SKIP_GENERIC_SYNC;
+ int ret = 0;
int register_ret;
- unsigned long flags = 0;
+ int cpu;
spu_prof_num_nodes = number_of_online_nodes();
num_spu_nodes = spu_prof_num_nodes * 8;
- spin_lock_irqsave(&buffer_lock, flags);
- add_event_entry(ESCAPE_CODE);
- add_event_entry(SPU_PROFILING_CODE);
- add_event_entry(num_spu_nodes);
- spin_unlock_irqrestore(&buffer_lock, flags);
+ /* The SPU_PROFILING_CODE escape sequence must proceed
+ * the SPU context switch info.
+ */
+ for_each_online_cpu(cpu) {
+ oprofile_add_value(ESCAPE_CODE, cpu);
+ oprofile_add_value(SPU_PROFILING_CODE, cpu);
+ oprofile_add_value((unsigned long int)
+ num_spu_nodes, cpu);
+ }
/* Register for SPU events */
register_ret = spu_switch_event_register(&spu_active);
if (register_ret) {
- ret = SYNC_START_ERROR;
+ ret = -1;
goto out;
}
- for (k = 0; k < (MAX_NUMNODES * 8); k++)
+ for (k = 0; k < (MAX_NUMNODES * 8); k++) {
last_guard_val[k] = 0;
+ spu_ctx_sw_seen[k] = 0;
+ }
pr_debug("spu_sync_start -- running.\n");
out:
return ret;
@@ -432,7 +444,7 @@ void spu_sync_buffer(int spu_num, unsign
map = c_info->map;
the_spu = c_info->the_spu;
- spin_lock(&buffer_lock);
+ spin_lock(&add_value_lock);
for (i = 0; i < num_samples; i++) {
unsigned int sample = *(samples+i);
int grd_val = 0;
@@ -452,31 +464,38 @@ void spu_sync_buffer(int spu_num, unsign
break;
}
- add_event_entry(file_offset | spu_num_shifted);
+ /* We must ensure that the SPU context switch has been written
+ * out before samples for the SPU. Otherwise, the SPU context
+ * information is not available and the postprocessing of the
+ * SPU PC will fail with no available anonymous map information.
+ */
+ if (spu_ctx_sw_seen[spu_num])
+ oprofile_add_value((file_offset | spu_num_shifted),
+ (spu_num >> 2));
}
- spin_unlock(&buffer_lock);
+ spin_unlock(&add_value_lock);
out:
spin_unlock_irqrestore(&cache_lock, flags);
}
-int spu_sync_stop(void)
+void spu_sync_stop(void)
{
unsigned long flags = 0;
- int ret = spu_switch_event_unregister(&spu_active);
- if (ret) {
- printk(KERN_ERR "SPU_PROF: "
- "%s, line %d: spu_switch_event_unregister returned %d\n",
- __FUNCTION__, __LINE__, ret);
- goto out;
- }
+
+ /* Ignoring the return value from the unregister
+ * call. A failed return value simply says there
+ * was no registered event. Hence there will not
+ * be any calls to process a switch event that
+ * could cause a problem.
+ */
+ spu_switch_event_unregister(&spu_active);
spin_lock_irqsave(&cache_lock, flags);
- ret = release_cached_info(RELEASE_ALL);
+ release_cached_info(RELEASE_ALL);
spin_unlock_irqrestore(&cache_lock, flags);
-out:
pr_debug("spu_sync_stop -- done.\n");
- return ret;
+ return;
}
Index: Cell_kernel_4_15_2008/arch/powerpc/oprofile/op_model_cell.c
===================================================================
--- Cell_kernel_4_15_2008.orig/arch/powerpc/oprofile/op_model_cell.c
+++ Cell_kernel_4_15_2008/arch/powerpc/oprofile/op_model_cell.c
@@ -1191,15 +1191,15 @@ static int cell_sync_start(void)
if (spu_cycle_reset)
return spu_sync_start();
else
- return DO_GENERIC_SYNC;
+ return 0;
}
-static int cell_sync_stop(void)
+static void cell_sync_stop(void)
{
if (spu_cycle_reset)
- return spu_sync_stop();
- else
- return 1;
+ spu_sync_stop();
+
+ return;
}
struct op_powerpc_model op_model_cell = {
Index: Cell_kernel_4_15_2008/drivers/oprofile/buffer_sync.c
===================================================================
--- Cell_kernel_4_15_2008.orig/drivers/oprofile/buffer_sync.c
+++ Cell_kernel_4_15_2008/drivers/oprofile/buffer_sync.c
@@ -521,6 +521,20 @@ void sync_buffer(int cpu)
} else if (s->event == CPU_TRACE_BEGIN) {
state = sb_bt_start;
add_trace_begin();
+ } else if (s->event == VALUE_HEADER_ID) {
+ /* The next event contains a value
+ * to enter directly into the event buffer.
+ */
+ increment_tail(cpu_buf);
+ i++; /* one less entry in buffer to process */
+
+ s = &cpu_buf->buffer[cpu_buf->tail_pos];
+
+ if (unlikely(is_code(s->eip)))
+ add_event_entry(s->event);
+ else
+ printk("KERN_ERR Oprofile per CPU" \
+ "buffer sequence error.\n");
} else {
struct mm_struct * oldmm = mm;
Index: Cell_kernel_4_15_2008/drivers/oprofile/cpu_buffer.c
===================================================================
--- Cell_kernel_4_15_2008.orig/drivers/oprofile/cpu_buffer.c
+++ Cell_kernel_4_15_2008/drivers/oprofile/cpu_buffer.c
@@ -224,6 +224,29 @@ static void oprofile_end_trace(struct op
cpu_buf->tracing = 0;
}
+/*
+ * The first entry in the per cpu buffer consists of the escape code
and
+ * the VALUE_HEADER_ID value. The next entry consists of an escape
code
+ * with the value to store. The syn_buffer routine takes the value
from
+ * the second entry and put it into the kernel buffer.
+ */
+void oprofile_add_value(unsigned long value, int cpu) {
+ struct oprofile_cpu_buffer * cpu_buf = &cpu_buffer[cpu];
+
+ /* Enter a sequence of two events. The first event says the
+ * next event contains a value that is to be put directly into the
+ * event buffer.
+ */
+
+ if (nr_available_slots(cpu_buf) < 3) {
+ cpu_buf->sample_lost_overflow++;
+ return;
+ }
+
+ add_sample(cpu_buf, ESCAPE_CODE, VALUE_HEADER_ID);
+ add_sample(cpu_buf, ESCAPE_CODE, value);
+}
+
void oprofile_add_ext_sample(unsigned long pc, struct pt_regs * const
regs,
unsigned long event, int is_kernel)
{
Index: Cell_kernel_4_15_2008/drivers/oprofile/cpu_buffer.h
===================================================================
--- Cell_kernel_4_15_2008.orig/drivers/oprofile/cpu_buffer.h
+++ Cell_kernel_4_15_2008/drivers/oprofile/cpu_buffer.h
@@ -54,5 +54,6 @@ void cpu_buffer_reset(struct oprofile_cp
/* transient events for the CPU buffer -> event buffer */
#define CPU_IS_KERNEL 1
#define CPU_TRACE_BEGIN 2
+#define VALUE_HEADER_ID 3
#endif /* OPROFILE_CPU_BUFFER_H */
Index: Cell_kernel_4_15_2008/drivers/oprofile/oprof.c
===================================================================
--- Cell_kernel_4_15_2008.orig/drivers/oprofile/oprof.c
+++ Cell_kernel_4_15_2008/drivers/oprofile/oprof.c
@@ -53,24 +53,13 @@ int oprofile_setup(void)
* us missing task deaths and eventually oopsing
* when trying to process the event buffer.
*/
- if (oprofile_ops.sync_start) {
- int sync_ret = oprofile_ops.sync_start();
- switch (sync_ret) {
- case 0:
- goto post_sync;
- case 1:
- goto do_generic;
- case -1:
- goto out3;
- default:
- goto out3;
- }
- }
-do_generic:
+ if (oprofile_ops.sync_start
+ && ((err = oprofile_ops.sync_start())))
+ goto out2;
+
if ((err = sync_start()))
goto out3;
-post_sync:
is_setup = 1;
mutex_unlock(&start_mutex);
return 0;
@@ -133,20 +122,9 @@ out:
void oprofile_shutdown(void)
{
mutex_lock(&start_mutex);
- if (oprofile_ops.sync_stop) {
- int sync_ret = oprofile_ops.sync_stop();
- switch (sync_ret) {
- case 0:
- goto post_sync;
- case 1:
- goto do_generic;
- default:
- goto post_sync;
- }
- }
-do_generic:
+ if (oprofile_ops.sync_stop)
+ oprofile_ops.sync_stop();
sync_stop();
-post_sync:
if (oprofile_ops.shutdown)
oprofile_ops.shutdown();
is_setup = 0;
Index: Cell_kernel_4_15_2008/include/linux/oprofile.h
===================================================================
--- Cell_kernel_4_15_2008.orig/include/linux/oprofile.h
+++ Cell_kernel_4_15_2008/include/linux/oprofile.h
@@ -56,12 +56,10 @@ struct oprofile_operations {
/* Stop delivering interrupts. */
void (*stop)(void);
/* Arch-specific buffer sync functions.
- * Return value = 0: Success
- * Return value = -1: Failure
- * Return value = 1: Run generic sync function
+ * Sync start: Return 0 for Success, -1 for Failure
*/
int (*sync_start)(void);
- int (*sync_stop)(void);
+ void (*sync_stop)(void);
/* Initiate a stack backtrace. Optional. */
void (*backtrace)(struct pt_regs * const regs, unsigned int depth);
@@ -84,13 +82,6 @@ int oprofile_arch_init(struct oprofile_o
void oprofile_arch_exit(void);
/**
- * Add data to the event buffer.
- * The data passed is free-form, but typically consists of
- * file offsets, dcookies, context information, and ESCAPE codes.
- */
-void add_event_entry(unsigned long data);
-
-/**
* Add a sample. This may be called from any context. Pass
* smp_processor_id() as cpu.
*/
@@ -106,6 +97,17 @@ void oprofile_add_sample(struct pt_regs
void oprofile_add_ext_sample(unsigned long pc, struct pt_regs * const
regs,
unsigned long event, int is_kernel);
+/*
+ * Add a value to the per CPU buffer. The value is passed from the per
CPU
+ * buffer to the kernel buffer with no additional processing. The
assumption
+ * is any processing of the value will be done in the postprocessor.
This
+ * function should only be used for special architecture specific data.
+ * Currently only used by the CELL processor.
+ *
+ * This function does not perform a backtrace.
+ */
+void oprofile_add_value(unsigned long value, int cpu);
+
/* Use this instead when the PC value is not from the regs. Doesn't
* backtrace. */
void oprofile_add_pc(unsigned long pc, int is_kernel, unsigned long
event);
Index: Cell_kernel_4_15_2008/include/asm-powerpc/oprofile_impl.h
===================================================================
--- Cell_kernel_4_15_2008.orig/include/asm-powerpc/oprofile_impl.h
+++ Cell_kernel_4_15_2008/include/asm-powerpc/oprofile_impl.h
@@ -48,7 +48,7 @@ struct op_powerpc_model {
void (*stop) (void);
void (*global_stop) (void);
int (*sync_start)(void);
- int (*sync_stop)(void);
+ void (*sync_stop)(void);
void (*handle_interrupt) (struct pt_regs *,
struct op_counter_config *);
int num_counters;
Index: Cell_kernel_4_15_2008/drivers/oprofile/event_buffer.h
===================================================================
--- Cell_kernel_4_15_2008.orig/drivers/oprofile/event_buffer.h
+++ Cell_kernel_4_15_2008/drivers/oprofile/event_buffer.h
@@ -17,6 +17,14 @@ int alloc_event_buffer(void);
void free_event_buffer(void);
+
+/**
+ * Add data to the event buffer.
+ * The data passed is free-form, but typically consists of
+ * file offsets, dcookies, context information, and ESCAPE codes.
+ */
+void add_event_entry(unsigned long data);
+
/* wake up the process sleeping on the event file */
void wake_up_buffer_waiter(void);
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Kumar Gala @ 2008-04-30 20:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-dev, rdunlap, paulus, torvalds
In-Reply-To: <20080430121239.28492328.akpm@linux-foundation.org>
On Apr 30, 2008, at 2:12 PM, Andrew Morton wrote:
> On Wed, 30 Apr 2008 14:01:12 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>>
>> On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
>>> On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
>>> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>>>
>>>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>>>
>>>> Don't refer to file that no longer exists:
>>>> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
>>>> or directory
>>>>
>>>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>>>> ---
>>>> Documentation/DocBook/rapidio.tmpl | 1 -
>>>> 1 file changed, 1 deletion(-)
>>>>
>>>> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
>>>> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
>>>> @@ -133,7 +133,6 @@
>>>> !Idrivers/rapidio/rio-sysfs.c
>>>> </sect1>
>>>> <sect1 id="PPC32_support"><title>PPC32 support</title>
>>>> -!Iarch/powerpc/kernel/rio.c
>>>> !Earch/powerpc/sysdev/fsl_rio.c
>>>> !Iarch/powerpc/sysdev/fsl_rio.c
>>>> </sect1>
>>>
>>> grumble.
>>>
>>> This is a subset of rapidio-fix-docbook-references.patch, but I
>>> appear to
>>> be unable to interest anyone in merging/reviewing/accepting/
>>> anything-
>>> else
>>> that quite large set of patches.
>>>
>>> Guys, those patches were sent six weeks ago and it now looks like
>>> they will
>>> miss 2.6.26. This is pretty slack of us. Help?
>>
>> Odd. I thought Paul had picked up a docbook RapidIO patch from you
>> in
>> the latest merge round.
>>
>
> Well it's more than "a" patch. The six-week-old patch series is:
>
> rapidio-add-memory-mapping-driver-to-rapidio.patch
> rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
> rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
> rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-
> space-resources.patch
> rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
> rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
> rapidio-fix-docbook-references.patch
> rapidio-fix-kernel-doc-problems.patch
>
> totalling:
>
> arch/powerpc/sysdev/fsl_rio.c | 13 +
> include/linux/rio.h | 10
> drivers/net/Kconfig | 10
> drivers/net/rionet.c | 324 ++++++++++++++++++++++++++
> ++++
> drivers/rapidio/Makefile | 1
> drivers/rapidio/rio.c | 10
> drivers/rapidio/sallocator/Kconfig | 9
> drivers/rapidio/sallocator/Makefile | 12 +
> drivers/rapidio/sallocator/bitmap.c | 384 ++++++++++++++++++++++++++
> ++++++++++
> include/linux/rio.h | 10
> include/linux/rio_drv.h | 41 +++
> 16 files changed, 1425 insertions(+), 14 deletions(-)
>
>
> (seems that I forgot to cc Jeff on the rionet change too).
>
>
> Oh well. If nobody puts their hand up in the next 24 hours or so
> I'll just
> send it all in to Linus.
I'm raising my hand. The memory map driver needs further review. If
the Docbook issues can be applied w/o the other patches I suggest we
go forward with those.
- k
^ permalink raw reply
* Re: drivers/net/fec_8xx config problem
From: Jan Engelhardt @ 2008-04-30 20:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20080430192329.GA9150@ld0162-tx32.am.freescale.net>
On Wednesday 2008-04-30 21:23, Scott Wood wrote:
>> On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
>> >On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
>> >>I just noticed that the fec_8xx driver is not currently reachable via
>> >>menuconfig because it depends on 8XX instead of 8xx.
>> >[snip]
>> >>Since nobody has noticed this problem, I'm wondering if this driver
>> >>is still in (infrequent) use, or if it's been superseded and should
>> >>be removed, or if I'm just completely missing something with respect
>> >>to the use of "8XX" instead of "8xx".
Blame those developers who had the brilliant idea of using lowercase in
kconfig symbols (these things emit cosmic particles en masse!) :-)
arch/arm/mach-pxa/Kconfig:config PXA3xx
^ permalink raw reply
* Re: [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
From: Timur Tabi @ 2008-04-30 19:42 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080430193040.GA9239@polina.dev.rtsoft.ru>
Anton Vorontsov wrote:
> + Example:
> + qe_pio_a: gpio-controller@1400 {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8360-qe-pario-bank",
> + "fsl,mpc8323-qe-pario-bank";
I know this is an example, but would we ever include both compatible strings in
one DTS? Isn't the norm something like:
"fsl,mpc8360-qe-pario-bank", "fsl,qe-pario-bank";
I.e. specific version, then generic version?
Otherwise, every time we introduce a new QE part, we'll have to update *every*
QE-enabled device tree *and* the QE gpio driver.
> +static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct qe_pio_regs __iomem *regs = mm_gc->regs;
> + u32 pin_mask = 1 << (QE_PIO_PINS - 1 - gpio);
> +
> + return in_be32(®s->cpdata) & pin_mask;
> +}
Return value should be "u32", not "int".
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH v2 4/6] [POWERPC] QE: implement support for the GPIO LIB API
From: Anton Vorontsov @ 2008-04-30 19:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20080429190045.GD21203@polina.dev.rtsoft.ru>
This is needed to access QE GPIOs via Linux GPIO API.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Updated per Timur Tabi's comments.
Documentation/powerpc/booting-without-of.txt | 27 +++++
arch/powerpc/sysdev/qe_lib/Kconfig | 9 ++
arch/powerpc/sysdev/qe_lib/Makefile | 1 +
arch/powerpc/sysdev/qe_lib/gpio.c | 146 ++++++++++++++++++++++++++
include/asm-powerpc/qe.h | 3 +
5 files changed, 186 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/qe_lib/gpio.c
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index fc7a235..c1044ee 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1738,6 +1738,33 @@ platforms are moved over to use the flattened-device-tree model.
......
};
+ Note that "par_io" nodes are obsolete, and should not be used for
+ the new device trees. Instead, each Par I/O bank should be represented
+ via its own gpio-controller node:
+
+ Required properties:
+ - #gpio-cells : should be "2".
+ - compatible : should be "fsl,<chip>-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank".
+ - reg : offset to the register set and its length.
+ - gpio-controller : node to identify gpio controllers.
+
+ Example:
+ qe_pio_a: gpio-controller@1400 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank";
+ reg = <0x1400 0x18>;
+ gpio-controller;
+ };
+
+ qe_pio_e: gpio-controller@1460 {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+ "fsl,mpc8323-qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ };
vi) Pin configuration nodes
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
index 76ffbc4..4bb18f5 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -24,3 +24,12 @@ config QE_USB
bool
help
QE USB Host Controller support
+
+config QE_GPIO
+ bool "QE GPIO support"
+ depends on QUICC_ENGINE
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
+ help
+ Say Y here if you're going to use hardware that connects to the
+ QE GPIOs.
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/sysdev/qe_lib/Makefile
index e9ff888..f1855c1 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
obj-$(CONFIG_UCC_FAST) += ucc_fast.o
obj-$(CONFIG_QE_USB) += usb.o
+obj-$(CONFIG_QE_GPIO) += gpio.o
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c b/arch/powerpc/sysdev/qe_lib/gpio.c
new file mode 100644
index 0000000..c712e24
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -0,0 +1,146 @@
+/*
+ * QUICC Engine GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <avorontsov@ru.mvista.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/kernel.h>
+#include <linux/spinlock.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/gpio.h>
+#include <asm/qe.h>
+
+struct qe_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct qe_gpio_chip *
+to_qe_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct qe_gpio_chip, mm_gc);
+}
+
+static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+
+ qe_gc->cpdata = in_be32(®s->cpdata);
+}
+
+static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+ u32 pin_mask = 1 << (QE_PIO_PINS - 1 - gpio);
+
+ return in_be32(®s->cpdata) & pin_mask;
+}
+
+static void qe_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ struct qe_pio_regs __iomem *regs = mm_gc->regs;
+ unsigned long flags;
+ u32 pin_mask = 1 << (QE_PIO_PINS - 1 - gpio);
+
+ spin_lock_irqsave(&qe_gc->lock, flags);
+
+ if (val)
+ qe_gc->cpdata |= pin_mask;
+ else
+ qe_gc->cpdata &= ~pin_mask;
+
+ out_be32(®s->cpdata, qe_gc->cpdata);
+
+ spin_unlock_irqrestore(&qe_gc->lock, flags);
+}
+
+static int qe_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&qe_gc->lock, flags);
+
+ __par_io_config_pin(mm_gc->regs, gpio, QE_PIO_DIR_IN, 0, 0, 0);
+
+ spin_unlock_irqrestore(&qe_gc->lock, flags);
+
+ return 0;
+}
+
+static int qe_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
+ unsigned long flags;
+
+ spin_lock_irqsave(&qe_gc->lock, flags);
+
+ __par_io_config_pin(mm_gc->regs, gpio, QE_PIO_DIR_OUT, 0, 0, 0);
+
+ spin_unlock_irqrestore(&qe_gc->lock, flags);
+
+ qe_gpio_set(gc, gpio, val);
+
+ return 0;
+}
+
+void __init qe_add_gpiochips(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "fsl,mpc8323-qe-pario-bank") {
+ int ret;
+ struct qe_gpio_chip *qe_gc;
+ struct of_mm_gpio_chip *mm_gc;
+ struct of_gpio_chip *of_gc;
+ struct gpio_chip *gc;
+
+ qe_gc = kzalloc(sizeof(*qe_gc), GFP_KERNEL);
+ if (!qe_gc) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ spin_lock_init(&qe_gc->lock);
+
+ mm_gc = &qe_gc->mm_gc;
+ of_gc = &mm_gc->of_gc;
+ gc = &of_gc->gc;
+
+ mm_gc->save_regs = qe_gpio_save_regs;
+ of_gc->gpio_cells = 2;
+ gc->ngpio = QE_PIO_PINS;
+ gc->direction_input = qe_gpio_dir_in;
+ gc->direction_output = qe_gpio_dir_out;
+ gc->get = qe_gpio_get;
+ gc->set = qe_gpio_set;
+
+ ret = of_mm_gpiochip_add(np, mm_gc);
+ if (ret)
+ goto err;
+ continue;
+err:
+ pr_err("%s: registration failed with status %d\n",
+ np->full_name, ret);
+ kfree(qe_gc);
+ /* try others anyway */
+ }
+}
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index c4523ac..01e3c70 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -100,8 +100,11 @@ struct qe_pio_regs {
#endif
};
+extern void __init qe_add_gpiochips(void);
extern int par_io_init(struct device_node *np);
extern int par_io_of_config(struct device_node *np);
+#define QE_PIO_DIR_IN 2
+#define QE_PIO_DIR_OUT 1
extern void __par_io_config_pin(struct qe_pio_regs __iomem *par_io, u8 pin,
int dir, int open_drain, int assignment,
int has_irq);
--
1.5.5.1
^ permalink raw reply related
* patch devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch added to gregkh-2.6 tree
From: gregkh @ 2008-04-30 18:42 UTC (permalink / raw)
To: galak, akpm, gregkh, greg, htejun, jbarnes, jgarzik, linux-kernel,
linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804291025140.25102@blarg.am.freescale.net>
This is a note to let you know that I've just added the patch titled
Subject: devres: support addresses greater than an unsigned long via dev_ioremap
to my gregkh-2.6 tree. Its filename is
devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch
This tree can be found at
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
>From galak@kernel.crashing.org Wed Apr 30 11:27:51 2008
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 29 Apr 2008 10:25:48 -0500 (CDT)
Subject: devres: support addresses greater than an unsigned long via dev_ioremap
To: Greg KH <greg@kroah.com>
Cc: Tejun Heo <htejun@gmail.com>, Jeff Garzik <jgarzik@pobox.com>, Andrew Morton <akpm@osdl.org>, "linuxppc-dev@ozlabs.org list" <linuxppc-dev@ozlabs.org>, lkml Mailing List <linux-kernel@vger.kernel.org>, Jesse Barnes <jbarnes@virtuousgeek.org>
Message-ID: <Pine.LNX.4.64.0804291025140.25102@blarg.am.freescale.net>
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Cc: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jgarzik@pobox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
include/linux/io.h | 4 ++--
lib/devres.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(str
}
#endif
-void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size);
-void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size);
void devm_iounmap(struct device *dev, void __iomem *addr);
int check_signature(const volatile void __iomem *io_addr,
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -20,7 +20,7 @@ static int devm_ioremap_match(struct dev
*
* Managed ioremap(). Map is automatically unmapped on driver detach.
*/
-void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap);
* Managed ioremap_nocache(). Map is automatically unmapped on driver
* detach.
*/
-void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
unsigned long size)
{
void __iomem **ptr, *addr;
Patches currently in gregkh-2.6 which might be from galak@kernel.crashing.org are
driver-core/devres-support-addresses-greater-than-an-unsigned-long-via-dev_ioremap.patch
^ permalink raw reply
* Re: drivers/net/fec_8xx config problem
From: Scott Wood @ 2008-04-30 19:23 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev@ozlabs.org list, jengelh
In-Reply-To: <151BA0B1-A188-41C7-B2DB-E8D63D15C218@freescale.com>
On Wed, Apr 30, 2008 at 02:24:19PM -0500, Becky Bruce wrote:
>
> On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
> >On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
> >>I just noticed that the fec_8xx driver is not currently reachable via
> >>menuconfig because it depends on 8XX instead of 8xx.
> >[snip]
> >>Since nobody has noticed this problem, I'm wondering if this driver
> >>is still in (infrequent) use, or if it's been superseded and should
> >>be removed, or if I'm just completely missing something with respect
> >>to the use of "8XX" instead of "8xx".
> >
> >It's been superseded by drivers/net/fs_enet.
>
> Is there any reason we haven't removed it?
To keep arch/ppc/8xx_io company? :-)
> If not, I can push a patch to yank it.
I have no objection.
-Scott
^ permalink raw reply
* Re: drivers/net/fec_8xx config problem
From: Becky Bruce @ 2008-04-30 19:24 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list, jengelh
In-Reply-To: <20080430192030.GA9084@ld0162-tx32.am.freescale.net>
On Apr 30, 2008, at 2:20 PM, Scott Wood wrote:
> On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
>> I just noticed that the fec_8xx driver is not currently reachable via
>> menuconfig because it depends on 8XX instead of 8xx.
> [snip]
>> Since nobody has noticed this problem, I'm wondering if this driver
>> is still in (infrequent) use, or if it's been superseded and should
>> be removed, or if I'm just completely missing something with respect
>> to the use of "8XX" instead of "8xx".
>
> It's been superseded by drivers/net/fs_enet.
Is there any reason we haven't removed it? If not, I can push a
patch to yank it.
Cheers,
B
^ permalink raw reply
* Re: RE: FW: SKB corruption on heavy traffic
From: Gerhard Pircher @ 2008-04-30 19:20 UTC (permalink / raw)
To: Franca, Jose (NSN - PT/Portugal - MiniMD), scottwood
Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <56DEE2D3217CD946B290399093C8FA7C212F55@PTLIEXC001.nsn-intra.net>
-------- Original-Nachricht --------
> Datum: Wed, 30 Apr 2008 14:03:02 +0100
> Von: "Franca, Jose (NSN - PT/Portugal - MiniMD)" <jose.franca@nsn.com>
> An: "ext Gerhard Pircher" <gerhard_pircher@gmx.net>, "Scott Wood" <scottwood@freescale.com>
> CC: linuxppc-embedded@ozlabs.org, linuxppc-dev@ozlabs.org
> Betreff: RE: FW: SKB corruption on heavy traffic
> Hi!
>
> There was a sugestion to change slab to slub alocation method... I > don't know quite well yet what is necessary to do this, but it seems that
> the current implementation of slub is more commonly available on 2.6
> kernels, not in 2.4 that I use :(...
> Any guesses or hints on this?
I'm using SLUB with kernel v2.6.25 and I still get data corruption on high
load. On the other side it is a good idea to enable SLAB debugging, as
Scott suggested. Maybe that sheds some light on this issue (even if most
of the network drivers make use of DMA).
regards,
Gerhard
>
> Regards!
> Filipe.
>
> -----Original Message-----
> From: ext Gerhard Pircher [mailto:gerhard_pircher@gmx.net]
> Sent: quarta-feira, 30 de Abril de 2008 13:26
> To: Franca, Jose (NSN - PT/Portugal - MiniMD); Scott Wood
> Cc: linuxppc-embedded@ozlabs.org; linuxppc-dev@ozlabs.org
> Subject: Re: FW: SKB corruption on heavy traffic
>
> Hi,
>
> I think I have the same problem here with all versions of the 2.6.x
> kernel series (tested with kernel v2.6.8/14/16/18/25 on a PPC7455 machine
> with different PCI network cards by transferring a big file over
> NFS/SCP). Data corruption occurs under high load, but I don't get any
> kernel oops.
>
> regards,
>
> Gerhard
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
^ permalink raw reply
* Re: drivers/net/fec_8xx config problem
From: Scott Wood @ 2008-04-30 19:20 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev@ozlabs.org list, jengelh
In-Reply-To: <6E2EBEAF-DF1E-4439-91EF-B15EE39CAF61@freescale.com>
On Wed, Apr 30, 2008 at 02:19:21PM -0500, Becky Bruce wrote:
> I just noticed that the fec_8xx driver is not currently reachable via
> menuconfig because it depends on 8XX instead of 8xx.
[snip]
> Since nobody has noticed this problem, I'm wondering if this driver
> is still in (infrequent) use, or if it's been superseded and should
> be removed, or if I'm just completely missing something with respect
> to the use of "8XX" instead of "8xx".
It's been superseded by drivers/net/fs_enet.
-Scott
^ permalink raw reply
* drivers/net/fec_8xx config problem
From: Becky Bruce @ 2008-04-30 19:19 UTC (permalink / raw)
To: pantelis.antoniou, jengelh; +Cc: linuxppc-dev@ozlabs.org list
I just noticed that the fec_8xx driver is not currently reachable via
menuconfig because it depends on 8XX instead of 8xx. It looks like
this change occurred in commit
d1c0a65fb597697d1fbce4eadf42b84f70483edc, almost a year ago:
diff --git a/drivers/net/fec_8xx/Kconfig b/drivers/net/fec_8xx/Kconfig
index a84c232..afb34de 100644
--- a/drivers/net/fec_8xx/Kconfig+++ b/drivers/net/fec_8xx/Kconfig
@@ -1,6 +1,6 @@
config FEC_8XX
tristate "Motorola 8xx FEC driver"
- depends on NET_ETHERNET && 8xx
+ depends on 8XX
select MII
Since nobody has noticed this problem, I'm wondering if this driver
is still in (infrequent) use, or if it's been superseded and should
be removed, or if I'm just completely missing something with respect
to the use of "8XX" instead of "8xx".
I'm happy to submit a patch to correct this, I'm just not sure what
the right answer is.
Thanks,
Becky
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Andrew Morton @ 2008-04-30 19:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-dev, rdunlap, paulus, torvalds
In-Reply-To: <51A34080-7981-4958-B225-4921FC95B84A@kernel.crashing.org>
On Wed, 30 Apr 2008 14:01:12 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
> > On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> > "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> >
> >> From: Randy Dunlap <randy.dunlap@oracle.com>
> >>
> >> Don't refer to file that no longer exists:
> >> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
> >> or directory
> >>
> >> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> >> ---
> >> Documentation/DocBook/rapidio.tmpl | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> >> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> >> @@ -133,7 +133,6 @@
> >> !Idrivers/rapidio/rio-sysfs.c
> >> </sect1>
> >> <sect1 id="PPC32_support"><title>PPC32 support</title>
> >> -!Iarch/powerpc/kernel/rio.c
> >> !Earch/powerpc/sysdev/fsl_rio.c
> >> !Iarch/powerpc/sysdev/fsl_rio.c
> >> </sect1>
> >
> > grumble.
> >
> > This is a subset of rapidio-fix-docbook-references.patch, but I
> > appear to
> > be unable to interest anyone in merging/reviewing/accepting/anything-
> > else
> > that quite large set of patches.
> >
> > Guys, those patches were sent six weeks ago and it now looks like
> > they will
> > miss 2.6.26. This is pretty slack of us. Help?
>
> Odd. I thought Paul had picked up a docbook RapidIO patch from you in
> the latest merge round.
>
Well it's more than "a" patch. The six-week-old patch series is:
rapidio-add-memory-mapping-driver-to-rapidio.patch
rapidio-add-rapidio-space-allocation-bitmap-arithmetic.patch
rapidio-add-fsl-rapidio-controller-memory-ops-functions.patch
rapidio-add-the-rapidio-master-port-maintance-and-doorbell-window-to-space-resources.patch
rapidio-add-rapidio-proc-fs-for-memory-mapping-debugging.patch
rapidio-add-the-memory-mapping-support-in-rionet-driver.patch
rapidio-fix-docbook-references.patch
rapidio-fix-kernel-doc-problems.patch
totalling:
arch/powerpc/sysdev/fsl_rio.c | 13 +
include/linux/rio.h | 10
drivers/net/Kconfig | 10
drivers/net/rionet.c | 324 ++++++++++++++++++++++++++++++
drivers/rapidio/Makefile | 1
drivers/rapidio/rio.c | 10
drivers/rapidio/sallocator/Kconfig | 9
drivers/rapidio/sallocator/Makefile | 12 +
drivers/rapidio/sallocator/bitmap.c | 384 ++++++++++++++++++++++++++++++++++++
include/linux/rio.h | 10
include/linux/rio_drv.h | 41 +++
16 files changed, 1425 insertions(+), 14 deletions(-)
(seems that I forgot to cc Jeff on the rionet change too).
Oh well. If nobody puts their hand up in the next 24 hours or so I'll just
send it all in to Linus.
^ permalink raw reply
* Re: [RFC] [PATCH] vmemmap fixes to use smaller pages
From: Geoff Levand @ 2008-04-30 19:06 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1209534108.18023.221.camel@pasglop>
Benjamin Herrenschmidt wrote:
> This patch changes vmemmap to use a different region (region 0xf) of the
> address space whose page size can be dynamically configured at boot.
>
> The problem with the current approach of always using 16M pages is that
> it's not well suited to machines that have small amounts of memory such
> as small partitions on pseries, or PS3's.
>
> In fact, on the PS3, failure to allocate the 16M page backing vmmemmap
> tends to prevent hotplugging the HV's "additional" memory, thus limiting
> the available memory even more, from my experience down to something
> like 80M total, which makes it really not very useable.
>
> The logic used by my match to choose the vmemmap page size is:
>
> - If 16M pages are available and there's 1G or more RAM at boot, use that size.
> - Else if 64K pages are available, use that
> - Else use 4K pages
>
> I've tested on a POWER6 (16M pages) and on an iSeries POWER3 (4K pages)
> and it seems to work fine.
>
> However, when attempting to test on a PS3, it didn't boot.
>
> In fact, it doesn't boot without my patch with current upstream.
Yes, this is a know problem I am working on, related to recent
changes in bootmem. Errors with: 'sparse_early_usemap_alloc: allocation failed'.
I tried
> booting 2.6.25 with a ps3_defconfig and that doesn't work neither
> (though at least when doing the later, I do get a black screen & no
> sync, like of ps3fb failed monitor detection, while with current
> upstream, I just get the last kexec messages and nothing happens).
This should work. You are the first to report a problem with
2.6.25. Could you double check your build, and if you still have
trouble, put your vmlinux somewhere I can get it?
> Since the PS3 boot failures are impossible to debug unless your email is
> @sony* and you have the special magic tools, I'll let Geoff try the
> patch out.
OK, I'll try it with the upstream kernel from last week and report
within the next day or so.
-Geoff
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Kumar Gala @ 2008-04-30 19:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, linuxppc-dev, Randy.Dunlap, Paul Mackerras,
torvalds
In-Reply-To: <20080430113500.dfe21880.akpm@linux-foundation.org>
On Apr 30, 2008, at 1:35 PM, Andrew Morton wrote:
> On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Don't refer to file that no longer exists:
>> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file
>> or directory
>>
>> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
>> ---
>> Documentation/DocBook/rapidio.tmpl | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
>> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
>> @@ -133,7 +133,6 @@
>> !Idrivers/rapidio/rio-sysfs.c
>> </sect1>
>> <sect1 id="PPC32_support"><title>PPC32 support</title>
>> -!Iarch/powerpc/kernel/rio.c
>> !Earch/powerpc/sysdev/fsl_rio.c
>> !Iarch/powerpc/sysdev/fsl_rio.c
>> </sect1>
>
> grumble.
>
> This is a subset of rapidio-fix-docbook-references.patch, but I
> appear to
> be unable to interest anyone in merging/reviewing/accepting/anything-
> else
> that quite large set of patches.
>
> Guys, those patches were sent six weeks ago and it now looks like
> they will
> miss 2.6.26. This is pretty slack of us. Help?
Odd. I thought Paul had picked up a docbook RapidIO patch from you in
the latest merge round.
- k
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Randy Dunlap @ 2008-04-30 18:48 UTC (permalink / raw)
To: Andrew Morton
Cc: Benjamin, linux-kernel, linuxppc-dev, Paul Mackerras, torvalds
In-Reply-To: <20080430113500.dfe21880.akpm@linux-foundation.org>
On Wed, 30 Apr 2008 11:35:00 -0700 Andrew Morton wrote:
> On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
> "Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
> > From: Randy Dunlap <randy.dunlap@oracle.com>
> >
> > Don't refer to file that no longer exists:
> > docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory
> >
> > Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> > ---
> > Documentation/DocBook/rapidio.tmpl | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> > +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> > @@ -133,7 +133,6 @@
> > !Idrivers/rapidio/rio-sysfs.c
> > </sect1>
> > <sect1 id="PPC32_support"><title>PPC32 support</title>
> > -!Iarch/powerpc/kernel/rio.c
> > !Earch/powerpc/sysdev/fsl_rio.c
> > !Iarch/powerpc/sysdev/fsl_rio.c
> > </sect1>
>
> grumble.
>
> This is a subset of rapidio-fix-docbook-references.patch, but I appear to
> be unable to interest anyone in merging/reviewing/accepting/anything-else
> that quite large set of patches.
>
> Guys, those patches were sent six weeks ago and it now looks like they will
> miss 2.6.26. This is pretty slack of us. Help?
There's nothing there that can hurt. (famous last words)
Just merge it.
---
~Randy
^ permalink raw reply
* Re: [PATCH] docbook: fix fatal rapidio yet again (and more to come)
From: Andrew Morton @ 2008-04-30 18:35 UTC (permalink / raw)
To: Randy.Dunlap
Cc: Benjamin, linux-kernel, linuxppc-dev, Paul Mackerras, torvalds
In-Reply-To: <Pine.LNX.4.64.0804292009000.18219@shark.he.net>
On Tue, 29 Apr 2008 20:10:55 -0700 (PDT)
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Don't refer to file that no longer exists:
> docproc: linux-2.6.25-git14/arch/powerpc/kernel/rio.c: No such file or directory
>
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
> Documentation/DocBook/rapidio.tmpl | 1 -
> 1 file changed, 1 deletion(-)
>
> --- linux-2.6.25-git14.orig/Documentation/DocBook/rapidio.tmpl
> +++ linux-2.6.25-git14/Documentation/DocBook/rapidio.tmpl
> @@ -133,7 +133,6 @@
> !Idrivers/rapidio/rio-sysfs.c
> </sect1>
> <sect1 id="PPC32_support"><title>PPC32 support</title>
> -!Iarch/powerpc/kernel/rio.c
> !Earch/powerpc/sysdev/fsl_rio.c
> !Iarch/powerpc/sysdev/fsl_rio.c
> </sect1>
grumble.
This is a subset of rapidio-fix-docbook-references.patch, but I appear to
be unable to interest anyone in merging/reviewing/accepting/anything-else
that quite large set of patches.
Guys, those patches were sent six weeks ago and it now looks like they will
miss 2.6.26. This is pretty slack of us. Help?
^ permalink raw reply
* Re: mpc8379e rdb nand flash support
From: Scott Wood @ 2008-04-30 18:28 UTC (permalink / raw)
To: ???; +Cc: linuxppc-embedded
In-Reply-To: <2F9EE17A2D4D48458F49220889E0FAAD@baby>
On Thu, Apr 24, 2008 at 09:52:25AM +0800, ??? wrote:
> Since our projects need more capability to store filesystems,I changed nand flash to 1G byte.
> I think it is the same to operate nand flash both in u-boot and linux kernel ,because the code about FCM nand flash control is almost the same.So I just test it in u-boot.
> From the mpc8379e reference manual page 484 :
> 21 PGS NAND Flash E2PROM page size, buffer size, and block size.
> 0 Page size of 512 main area bytes plus 16 spare area bytes (small page devices);
> FCM RAM buffers are 1 Kbyte each; Flash block size of 16 Kbytes.
> 1 Page size of 2048 main area bytes plus 64 spare area bytes (large page devices);
> FCM RAM buffers are 4 Kbytes each; Flash block size of 128 Kbytes.
>
> Because the 32M nand flash block size is just the 16Kbytes,and it
> works well.But the block size of the 1G bytes nand flash is
> 256Kbytes,when every time I tried to write to it ,It just can be writed
> the first 128kbytes of every 256kbytes.As I wrote in last email.
> Below is the linux kernel information when I operate nand flash.
Try changing set_addr() to hardcode the shift applied before writing to
FBAR to the width of FPAR[PI], rather than basing it on the actual erase
block size.
-Scott
^ permalink raw reply
* Re: [PATCH v2] [POWERPC] devres: Add devm_ioremap_flags()
From: Andrew Morton @ 2008-04-30 17:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: htejun, jeff, greg, linux-kernel, Emilian.Medve, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0804301106010.22992@blarg.am.freescale.net>
On Wed, 30 Apr 2008 11:08:51 -0500 (CDT)
Kumar Gala <galak@kernel.crashing.org> wrote:
> From: Emil Medve <Emilian.Medve@Freescale.com>
>
> We provide an ioremap_flags so provide a coresphonding devm_ioremap_flags.
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
>
> Forgot to commit the actual implemtation in arch/powerpc/lib/devres.c
>
> Which tree should this go through, powerpc.git?
I'd say so, yes.
> arch/powerpc/lib/Makefile | 1 +
> arch/powerpc/lib/devres.c | 33 +++++++++++++++++++++++++++++++++
> include/asm-powerpc/io.h | 8 +++++++-
> include/linux/io.h | 1 +
> lib/devres.c | 2 +-
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox