* Re: Xilinx GPIO driver / CONFIG_OF
From: Johann Baudy @ 2008-04-23 14:54 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn
In-Reply-To: <fa686aa40804230733n43064fa5q7b900bcf2b2754e6@mail.gmail.com>
Perfect :)
Many thanks,
Johann Baudy
On Wed, Apr 23, 2008 at 2:33 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Wed, Apr 23, 2008 at 7:21 AM, John Linn <John.Linn@xilinx.com> wrote:
> > Hi Johann,
> >
> > Not to my knowledge yet. We have it on our list to do.
> >
> > Thanks,
> > John
>
> I've got a partial driver but it's not updated to the new GPIO
> infrastructure. I'll try to post what I have today.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Johann Baudy
johaahn@gmail.com
^ permalink raw reply
* [Cbe-oss-dev] [PATCH] Reworked Cell OProfile: SPU mutex lock fix
From: Carl Love @ 2008-04-23 15:50 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,13 @@
#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 per_cpu_buffers_exist=0;
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 +291,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 +306,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:
@@ -363,41 +377,55 @@ 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);
+ /* At this point, the CPU buffers have been generated so
+ * writes to the per CPU buffers can occur. Need to
+ * set the flag that the buffers exist before registering for
+ * the SPU context switches or the routine to process the
+ * context switches will not write context switch information.
+ */
+ per_cpu_buffers_exist = 1;
+
+ /* 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;
+ /* Stop the profile_spus() function from trying
+ * to store samples into the per CPU buffer. The
+ * buffer will not be there.
+ */
+ per_cpu_buffers_exist = 0;
+ 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;
+
}
/* Record SPU program counter samples to the oprofile event buffer. */
@@ -432,7 +460,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,15 +480,22 @@ 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);
@@ -475,8 +510,9 @@ int spu_sync_stop(void)
ret = release_cached_info(RELEASE_ALL);
spin_unlock_irqrestore(&cache_lock, flags);
out:
+ per_cpu_buffers_exist = 0;
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 (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,35 @@ static void oprofile_end_trace(struct op
cpu_buf->tracing = 0;
}
+/*
+ * 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.
+ *
+ * The first enty 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 evnets. 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);
@@ -106,6 +104,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;
^ permalink raw reply
* [PATCH] powerpc: Don't play type punning games with lock_token
From: Segher Boessenkool @ 2008-04-23 15:13 UTC (permalink / raw)
To: linuxppc-dev
The two u16 fields lock_token and paca_index in struct paca_struct are
accessed as one u32 field via type punning. Change this into one u32
field paca_id, and add a paca_get_index() function to access only the
low 16 bits of this.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kernel/paca.c | 3 +--
arch/powerpc/platforms/iseries/exception.S | 2 +-
include/asm-powerpc/iseries/hv_call.h | 2 +-
include/asm-powerpc/paca.h | 18 ++++++++++++------
include/asm-powerpc/smp.h | 2 +-
include/asm-powerpc/spinlock.h | 2 +-
7 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index 4b749c4..d00171f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -108,7 +108,7 @@ int main(void)
DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct ppc64_caches, ilines_per_page));
/* paca */
DEFINE(PACA_SIZE, sizeof(struct paca_struct));
- DEFINE(PACAPACAINDEX, offsetof(struct paca_struct, paca_index));
+ DEFINE(PACAPACAID, offsetof(struct paca_struct, paca_id));
DEFINE(PACAPROCSTART, offsetof(struct paca_struct, cpu_start));
DEFINE(PACAKSAVE, offsetof(struct paca_struct, kstack));
DEFINE(PACACURRENT, offsetof(struct paca_struct, __current));
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 55f1a25..d68d86c 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -68,8 +68,7 @@ struct slb_shadow slb_shadow[] __cacheline_aligned = {
*/
#define PACA_INIT_COMMON(number) \
.lppaca_ptr = &lppaca[number], \
- .lock_token = 0x8000, \
- .paca_index = (number), /* Paca Index */ \
+ .paca_id = 0x80000000 | (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
.hw_cpu_id = 0xffff, \
.slb_shadow_ptr = &slb_shadow[number],
diff --git a/arch/powerpc/platforms/iseries/exception.S b/arch/powerpc/platforms/iseries/exception.S
index 5381038..17dea0d 100644
--- a/arch/powerpc/platforms/iseries/exception.S
+++ b/arch/powerpc/platforms/iseries/exception.S
@@ -42,7 +42,7 @@ system_reset_iSeries:
mfmsr r24
ori r24,r24,MSR_RI
mtmsrd r24 /* RI on */
- lhz r24,PACAPACAINDEX(r13) /* Get processor # */
+ lhz r24,(PACAPACAID+2)(r13) /* Get processor # */
cmpwi 0,r24,0 /* Are we processor 0? */
bne 1f
b .__start_initialization_iSeries /* Start up the first processor */
diff --git a/include/asm-powerpc/iseries/hv_call.h b/include/asm-powerpc/iseries/hv_call.h
index 162d653..998db2c 100644
--- a/include/asm-powerpc/iseries/hv_call.h
+++ b/include/asm-powerpc/iseries/hv_call.h
@@ -105,7 +105,7 @@ extern void HvCall_writeLogBuffer(const void *buffer, u64 bufLen);
static inline void HvCall_sendIPI(struct paca_struct *targetPaca)
{
- HvCall1(HvCallBaseSendIPI, targetPaca->paca_index);
+ HvCall1(HvCallBaseSendIPI, paca_get_index(targetPaca));
}
#endif /* _ASM_POWERPC_ISERIES_HV_CALL_H */
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index 748b35a..7665d0a 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -65,13 +65,12 @@ struct paca_struct {
#endif /* CONFIG_PPC_ISERIES */
/*
- * MAGIC: the spinlock functions in arch/powerpc/lib/locks.c
- * load lock_token and paca_index with a single lwz
- * instruction. They must travel together and be properly
- * aligned.
+ * MAGIC: the spinlock functions in arch/powerpc/lib/locks.c
+ * load paca_id with a single lwz instruction. The high half
+ * of this is constant 0x8000; the low half is the paca index,
+ * accessed with paca_get_index().
*/
- u16 lock_token; /* Constant 0x8000, used in locks */
- u16 paca_index; /* Logical processor number */
+ u32 paca_id;
u64 kernel_toc; /* Kernel TOC address */
u64 stab_real; /* Absolute address of segment table */
@@ -117,6 +116,13 @@ struct paca_struct {
u64 startspurr; /* SPURR value snapshot */
};
+static inline u16 paca_get_index(struct paca_struct *paca)
+{
+ /* GCC will transform this into a single lhz instruction. */
+
+ return paca->paca_id & 0xffff;
+}
+
extern struct paca_struct paca[];
#endif /* __KERNEL__ */
diff --git a/include/asm-powerpc/smp.h b/include/asm-powerpc/smp.h
index 505f35b..5fb4f13 100644
--- a/include/asm-powerpc/smp.h
+++ b/include/asm-powerpc/smp.h
@@ -46,7 +46,7 @@ void generic_mach_cpu_die(void);
#endif
#ifdef CONFIG_PPC64
-#define raw_smp_processor_id() (local_paca->paca_index)
+#define raw_smp_processor_id() paca_get_index(local_paca)
#define hard_smp_processor_id() (get_paca()->hw_cpu_id)
#else
/* 32-bit */
diff --git a/include/asm-powerpc/spinlock.h b/include/asm-powerpc/spinlock.h
index cc4cfce..5922a2f 100644
--- a/include/asm-powerpc/spinlock.h
+++ b/include/asm-powerpc/spinlock.h
@@ -31,7 +31,7 @@
#ifdef CONFIG_PPC64
/* use 0x800000yy when locked, where yy == CPU number */
-#define LOCK_TOKEN (*(u32 *)(&get_paca()->lock_token))
+#define LOCK_TOKEN (get_paca()->paca_id)
#else
#define LOCK_TOKEN 1
#endif
--
1.5.5.23.g2a5f.dirty
^ permalink raw reply related
* missing current-speed property prevents autoconsole on pegasos
From: Olaf Hering @ 2008-04-23 15:22 UTC (permalink / raw)
To: linuxppc-dev
Pegasos2 has no current-speed property in
/pci@80000000/isa@C/serial@i2F8. As a result, console=ttyS0,115200 is
still required unless the patch below is used.
What is the correct way to restore console detection on pegasos2?
Index: linux-2.6.25-pegasos/arch/powerpc/platforms/chrp/setup.c
===================================================================
--- linux-2.6.25-pegasos.orig/arch/powerpc/platforms/chrp/setup.c
+++ linux-2.6.25-pegasos/arch/powerpc/platforms/chrp/setup.c
@@ -302,7 +305,7 @@ static void chrp_init_early(void)
if (!property)
goto out_put;
if (!strcmp(property, "failsafe") || !strcmp(property, "serial"))
- add_preferred_console("ttyS", 0, NULL);
+ add_preferred_console("ttyS", 0, "115200");
out_put:
of_node_put(node);
}
^ permalink raw reply
* Re: SecretLab 2.6.24 with USB
From: Peter Korsgaard @ 2008-04-23 15:12 UTC (permalink / raw)
To: Aaron Sells; +Cc: linuxppc-embedded
In-Reply-To: <480F4E8E.4010506@zin-tech.com>
>>>>> "Aaron" == Aaron Sells <aaron.sells@zin-tech.com> writes:
Hi,
Aaron> root@xilinx-ml403:/# dmesg | grep -i usb
Aaron> [ 0.175963] usbcore: registered new interface driver usbfs
Aaron> [ 0.178207] usbcore: registered new interface driver hub
Aaron> [ 0.179810] usbcore: registered new device driver usb
Aaron> [ 3.426016] usbcore: registered new interface driver ub
Aaron> [ 4.156086] usbmon: debugfs is not available
Aaron> [ 4.209160] Initializing USB Mass Storage driver...
Aaron> [ 4.268302] usbcore: registered new interface driver usb-storage
Aaron> [ 4.336109] USB Mass Storage support registered.
Aaron> [ 4.958294] usbcore: registered new interface driver usbhid
Aaron> [ 5.020120] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
Yes, the USB core and drivers gets loaded, but because you haven't
provided a struct platform_device the c67x00 driver doesn't get
probed.
Aaron> It still doesn't look like the ML403 Cypress host device is being
Aaron> recognized. No messages appear upon insertion and removal of USB
Aaron> devices.
Aaron> Regards,
Aaron> Aaron Sells
Aaron> diff linux-2.6-xlnx_arch-ppc-syslib-virtex_devices.c secretlab_arch-ppc-syslib-virtex_devices.c
Aaron> 77,92d76
Aaron> < * ML300/ML403 Video Device: shortcut macro for single instance
Please use diff -u.
I don't see anything with platform devices for the c67x00 driver. You
need something like:
#include <linux/usb/c67x00.h>
static struct resource c67x00_resources[] = {
[0] = {
.start = 0x84000000,
.end = 0x8400000f,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = 3,
.end = 3,
.flags = IORESOURCE_IRQ,
},
};
static struct c67x00_platform_data thinlite_c67x00_data = {
.sie_config = C67X00_SIE1_HOST | C67X00_SIE2_PERIPHERAL_B,
.hpi_regstep = 0x02, /* A0 not connected on 16bit bus */
};
static struct platform_device thinlite_c67x00 = {
.name = "c67x00",
.id = 0,
.num_resources = ARRAY_SIZE(c67x00_resources),
.resource = c67x00_resources,
.dev.platform_data = &thinlite_c67x00_data,
};
Which you then register with the platform bus with
platform_add_devices or similar. Either you do this by hand or you
create XPAR_* macros which take the needed info out of xparameter.h
(sorry, I don't have an xparameters.h with those defines at hand).
Aaron> diff -Naur c67x00.old/c67x00-drv.c c67x00/c67x00-drv.c
Aaron> --- c67x00.old/c67x00-drv.c 2008-04-23 10:36:16.000000000 -0400
Aaron> +++ c67x00/c67x00-drv.c 2008-04-23 10:39:20.000000000 -0400
Aaron> @@ -57,8 +57,7 @@
Aaron> c67x00_hcd_probe(sie);
Aaron> break;
Aaron> - case C67X00_SIE_PERIPHERAL_A:
Aaron> - case C67X00_SIE_PERIPHERAL_B:
Aaron> + case C67X00_SIE_PERIPHERAL:
This seems to be from an earlier version of my driver.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: SecretLab 2.6.24 with USB
From: Aaron Sells @ 2008-04-23 14:58 UTC (permalink / raw)
To: Grant Likely, Peter Korsgaard; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40804221355s11f8fd6em3f2075bbb2073c8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
Grant Likely wrote:
> Compare arch/ppc/syslib/virtex_devices.c with the one in my git tree.
> Add the relevant missing bits.
Peter Korsgaard wrote:
> Did you register a struct platform_device for the c67x00?
I copied over the relevant USB code from secretlab's virtex_devices.c to
my Xilinx tree. In case I missed something, the diff between the two
files is attached. And yes, I copied over include/linux/usb/c67x00.h as
well. After doing this, I had to modify a couple of the c67x00 driver
files to get the kernel to compile. The patch is attached.
root@xilinx-ml403:/# dmesg | grep -i usb
[ 0.175963] usbcore: registered new interface driver usbfs
[ 0.178207] usbcore: registered new interface driver hub
[ 0.179810] usbcore: registered new device driver usb
[ 3.426016] usbcore: registered new interface driver ub
[ 4.156086] usbmon: debugfs is not available
[ 4.209160] Initializing USB Mass Storage driver...
[ 4.268302] usbcore: registered new interface driver usb-storage
[ 4.336109] USB Mass Storage support registered.
[ 4.958294] usbcore: registered new interface driver usbhid
[ 5.020120] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
It still doesn't look like the ML403 Cypress host device is being
recognized. No messages appear upon insertion and removal of USB devices.
Regards,
Aaron Sells
[-- Attachment #2: virtex_devices.c.diff --]
[-- Type: text/plain, Size: 6125 bytes --]
diff linux-2.6-xlnx_arch-ppc-syslib-virtex_devices.c secretlab_arch-ppc-syslib-virtex_devices.c
77,92d76
< * ML300/ML403 Video Device: shortcut macro for single instance
< */
< #define XPAR_TFT(num) { \
< .name = "xilinxfb", \
< .id = num, \
< .num_resources = 1, \
< .resource = (struct resource[]) { \
< { \
< .start = XPAR_TFT_##num##_BASEADDR, \
< .end = XPAR_TFT_##num##_BASEADDR+7, \
< .flags = IORESOURCE_IO, \
< }, \
< }, \
< }
<
< /*
126,152d109
< * EMAC: shortcut macro for single instance
< */
< #define XPAR_EMACLITE(num) { \
< .name = "xilinx_emaclite", \
< .id = num, \
< .num_resources = 2, \
< .resource = (struct resource[]) { \
< { \
< .start = XPAR_EMACLITE_##num##_BASEADDR, \
< .end = XPAR_EMACLITE_##num##_HIGHADDR, \
< .flags = IORESOURCE_MEM, \
< }, \
< { \
< .start = XPAR_INTC_0_EMACLITE_##num##_VEC_ID, \
< .flags = IORESOURCE_IRQ, \
< }, \
< }, \
< .dev.platform_data = &(struct xemaclite_platform_data) { \
< .tx_ping_pong = XPAR_EMACLITE_##num##_TX_PING_PONG, \
< .rx_ping_pong = XPAR_EMACLITE_##num##_RX_PING_PONG, \
< /* locally administered default address */ \
< .mac_addr = {2, 0, 0, 0, 0, num}, \
< }, \
< }
<
<
< /*
199,288c156,160
< #define XPAR_LLTEMAC_RESOURCES(num) \
< .name = "xilinx_lltemac", \
< .id = XPAR_LLTEMAC_##num##_DEVICE_ID, \
< .num_resources = 2, \
< .resource = (struct resource[]) { \
< { \
< .start = XPAR_LLTEMAC_##num##_BASEADDR, \
< .end = XPAR_LLTEMAC_##num##_BASEADDR + 0x1000, \
< .flags = IORESOURCE_MEM \
< }, \
< { \
< .start = XPAR_INTC_0_LLTEMAC_##num##_VEC_ID, \
< .end = XPAR_INTC_0_LLTEMAC_##num##_VEC_ID, \
< .flags = IORESOURCE_IRQ \
< } \
< }
<
< #ifdef XPAR_XLLDMA_USE_DCR
< #define DCRHOST 0xFF
< #else
< #define DCRHOST 0x00
< #endif
<
< #define XPAR_LLTEMAC(num) { \
< XPAR_LLTEMAC_RESOURCES(num), \
< .dev.platform_data = &(struct xlltemac_platform_data) { \
< .tx_csum = XPAR_LLTEMAC_##num##_TXCSUM, \
< .rx_csum = XPAR_LLTEMAC_##num##_RXCSUM, \
< .phy_type = XPAR_LLTEMAC_##num##_PHY_TYPE, \
< .dcr_host = DCRHOST, \
< .ll_dev_type = XPAR_LLTEMAC_##num##_LLINK_CONNECTED_TYPE, \
< .ll_dev_baseaddress = XPAR_LLTEMAC_##num##_LLINK_CONNECTED_BASEADDR, \
< .ll_dev_dma_rx_irq = XPAR_LLTEMAC_##num##_LLINK_CONNECTED_DMARX_INTR, \
< .ll_dev_dma_tx_irq = XPAR_LLTEMAC_##num##_LLINK_CONNECTED_DMATX_INTR, \
< .ll_dev_fifo_irq = XPAR_LLTEMAC_##num##_LLINK_CONNECTED_FIFO_INTR, \
< /* locally administered default address */ \
< .mac_addr = {2, 0, 0, 0, 0, num}, \
< }, \
< }
<
<
< #define XPAR_PS2(num) { \
< .name = "xilinx_ps2", \
< .id = num, \
< .num_resources = 2, \
< .resource = (struct resource[]) { \
< { \
< .start = XPAR_PS2_##num##_BASEADDR, \
< .end = XPAR_PS2_##num##_HIGHADDR, \
< .flags = IORESOURCE_MEM, \
< }, \
< { \
< .start = XPAR_INTC_0_PS2_##num##_VEC_ID, \
< .flags = IORESOURCE_IRQ, \
< }, \
< }, \
< }
<
< #define XPAR_IIC(num) { \
< .name = "xilinx_iic", \
< .id = num, \
< .num_resources = 2, \
< .resource = (struct resource[]) { \
< { \
< .start = XPAR_IIC_##num##_BASEADDR, \
< .end = XPAR_IIC_##num##_HIGHADDR, \
< .flags = IORESOURCE_MEM, \
< }, \
< { \
< .start = XPAR_INTC_0_IIC_##num##_VEC_ID, \
< .flags = IORESOURCE_IRQ, \
< }, \
< }, \
< }
<
< #ifdef CONFIG_XILINX_VIRTEX_II_PRO
< #define XPAR_HWICAP_FAMILY "virtex2p"
< #endif
< #ifdef CONFIG_XILINX_VIRTEX_4_FX
< #define XPAR_HWICAP_FAMILY "virtex4"
< #endif
< #ifdef CONFIG_XILINX_VIRTEX_5
< #define XPAR_HWICAP_FAMILY "virtex5"
< #endif
< #ifndef XPAR_HWICAP_FAMILY
< #define XPAR_HWICAP_FAMILY NULL
< #endif
<
< #define XPAR_HWICAP(num) { \
< .name = "xilinx_icap", \
---
> /*
> * ML300/ML403 Video Device: shortcut macro for single instance
> */
> #define XPAR_TFT(num) { \
> .name = "xilinxfb", \
293,295c165,167
< .start = XPAR_HWICAP_##num##_BASEADDR, \
< .end = XPAR_HWICAP_##num##_HIGHADDR, \
< .flags = IORESOURCE_MEM, \
---
> .start = XPAR_TFT_##num##_BASEADDR, \
> .end = XPAR_TFT_##num##_BASEADDR+7, \
> .flags = IORESOURCE_IO, \
298d169
< .dev.platform_data = XPAR_HWICAP_FAMILY, \
409,410c280,281
< .name = "serial8250",
< .id = 0,
---
> .name = "serial8250",
> .id = 0,
437,450d307
< /* EMACLITE instances */
< #if defined(XPAR_EMACLITE_0_BASEADDR)
< XPAR_EMACLITE(0),
< #endif
< #if defined(XPAR_EMACLITE_1_BASEADDR)
< XPAR_EMACLITE(1),
< #endif
< #if defined(XPAR_EMACLITE_2_BASEADDR)
< XPAR_EMACLITE(2),
< #endif
< #if defined(XPAR_EMACLITE_3_BASEADDR)
< XPAR_EMACLITE(3),
< #endif
<
484,518d340
< /* LLTEMAC instances */
< #if defined(XPAR_LLTEMAC_0_BASEADDR)
< XPAR_LLTEMAC(0),
< #endif
< #if defined(XPAR_LLTEMAC_1_BASEADDR)
< XPAR_LLTEMAC(1),
< #endif
< #if defined(XPAR_LLTEMAC_2_BASEADDR)
< XPAR_LLTEMAC(2),
< #endif
< #if defined(XPAR_LLTEMAC_3_BASEADDR)
< XPAR_LLTEMAC(3),
< #endif
<
< #if defined(XPAR_PS2_0_BASEADDR)
< XPAR_PS2(0),
< #endif
< #if defined(XPAR_PS2_1_BASEADDR)
< XPAR_PS2(1),
< #endif
< #if defined(XPAR_PS2_2_BASEADDR)
< XPAR_PS2(2),
< #endif
< #if defined(XPAR_PS2_3_BASEADDR)
< XPAR_PS2(3),
< #endif
<
< #if defined(XPAR_IIC_0_BASEADDR)
< XPAR_IIC(0),
< #endif
<
< #if defined(XPAR_HWICAP_0_BASEADDR)
< XPAR_HWICAP(0),
< #endif
<
554d375
< extern void gen550_init(int i, struct uart_port *serial_req);
558,564c379,385
< serial_req.mapbase = pdata->mapbase;
< serial_req.membase = pdata->membase;
< serial_req.irq = pdata->irq;
< serial_req.uartclk = pdata->uartclk;
< serial_req.regshift = pdata->regshift;
< serial_req.iotype = pdata->iotype;
< serial_req.flags = pdata->flags;
---
> serial_req.mapbase = pdata->mapbase;
> serial_req.membase = pdata->membase;
> serial_req.irq = pdata->irq;
> serial_req.uartclk = pdata->uartclk;
> serial_req.regshift = pdata->regshift;
> serial_req.iotype = pdata->iotype;
> serial_req.flags = pdata->flags;
608,609d428
< printk(KERN_INFO "Registering device %s:%d\n",
< index->name, index->id);
[-- Attachment #3: c67x00.patch --]
[-- Type: text/plain, Size: 1074 bytes --]
diff -Naur c67x00.old/c67x00-drv.c c67x00/c67x00-drv.c
--- c67x00.old/c67x00-drv.c 2008-04-23 10:36:16.000000000 -0400
+++ c67x00/c67x00-drv.c 2008-04-23 10:39:20.000000000 -0400
@@ -57,8 +57,7 @@
c67x00_hcd_probe(sie);
break;
- case C67X00_SIE_PERIPHERAL_A:
- case C67X00_SIE_PERIPHERAL_B:
+ case C67X00_SIE_PERIPHERAL:
c67x00_udc_probe(sie);
break;
@@ -82,8 +81,7 @@
c67x00_hcd_remove(sie);
break;
- case C67X00_SIE_PERIPHERAL_A:
- case C67X00_SIE_PERIPHERAL_B:
+ case C67X00_SIE_PERIPHERAL:
c67x00_udc_remove(sie);
break;
diff -Naur c67x00.old/c67x00-ll-hpi.c c67x00/c67x00-ll-hpi.c
--- c67x00.old/c67x00-ll-hpi.c 2008-04-23 10:36:16.000000000 -0400
+++ c67x00/c67x00-ll-hpi.c 2008-04-23 10:39:35.000000000 -0400
@@ -431,7 +431,7 @@
USB_CTL_REG(sie->sie_num),
SOF_EOP_EN(0) | SOF_EOP_EN(1));
- if (sie->mode == C67X00_SIE_PERIPHERAL_A)
+ if (sie->mode == C67X00_SIE_PERIPHERAL)
hpi_write_word(dev, DEVICE_N_PORT_SEL(sie->sie_num), 0x0000);
else
hpi_write_word(dev, DEVICE_N_PORT_SEL(sie->sie_num), 0x4000);
^ permalink raw reply
* Re: Xilinx GPIO driver / CONFIG_OF
From: Grant Likely @ 2008-04-23 14:33 UTC (permalink / raw)
To: John Linn; +Cc: Johann Baudy, linuxppc-dev
In-Reply-To: <20080423132127.632CC1290067@mail80-sin.bigfish.com>
On Wed, Apr 23, 2008 at 7:21 AM, John Linn <John.Linn@xilinx.com> wrote:
> Hi Johann,
>
> Not to my knowledge yet. We have it on our list to do.
>
> Thanks,
> John
I've got a partial driver but it's not updated to the new GPIO
infrastructure. I'll try to post what I have today.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: new warnings from stacktrace patch
From: Christoph Hellwig @ 2008-04-23 14:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <20080423175938.a4b3cc26.sfr@canb.auug.org.au>
On Wed, Apr 23, 2008 at 05:59:38PM +1000, Stephen Rothwell wrote:
> This is from commit fd3e0bbc6052ca9747a5332b382584ece83aab6d ("[POWERPC]
> Stacktrace support for lockdep"). We don't include asm-offsets.h in any
> other C file in the powerpc build.
I think the include can be safely removed.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/powerpc/kernel/stacktrace.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:05.000000000 +0200
+++ linux-2.6/arch/powerpc/kernel/stacktrace.c 2008-04-23 15:28:16.000000000 +0200
@@ -13,7 +13,6 @@
#include <linux/sched.h>
#include <linux/stacktrace.h>
#include <asm/ptrace.h>
-#include <asm/asm-offsets.h>
/*
* Save stack-backtrace addresses into a stack_trace buffer.
^ permalink raw reply
* Re: [RFC POWERPC] booting-without-of: bindings for FHCI USB, GPIO LEDs, MCU, and NAND on UPM
From: Anton Vorontsov @ 2008-04-23 14:01 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200804231115.39126.laurentp@cse-semaphore.com>
On Wed, Apr 23, 2008 at 11:15:35AM +0200, Laurent Pinchart wrote:
> Hi Anton,
>
> On Tuesday 22 April 2008 21:41, Anton Vorontsov wrote:
> > Hi all,
> >
> > Here is purposed bindings draft for the new drivers that I would like to
> > send for this or next merge window, depending on results of this RFC. ;-)
> > (The new bindings needs to be in-tree or at least Acked before I could
> > send the drivers.)
> >
> > Comments and suggestions are highly appreciated.
> >
> > Thanks.
> >
> > diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> > index c350623..38fe3e9 100644
> > --- a/Documentation/powerpc/booting-without-of.txt
> > +++ b/Documentation/powerpc/booting-without-of.txt
> > @@ -59,6 +59,11 @@ Table of Contents
> > p) Freescale Synchronous Serial Interface
> > q) USB EHCI controllers
> > r) Freescale General-purpose Timers Module
> > + s) Freescale USB Parameter RAM:
> > + t) Freescale QUICC Engine USB Controller
> > + u) LEDs on GPIOs
> > + v) Freescale MCU with MPC8349E-mITX compatible firmware
> > + w) NAND on UPM-driven Freescale Localbus
> >
> > VII - Marvell Discovery mv64[345]6x System Controller chips
> > 1) The /system-controller node
> > @@ -2866,6 +2871,139 @@ platforms are moved over to use the
> flattened-device-tree model.
> > clock-frequency = <0>;
> > };
> >
> > + s) Freescale USB Parameter RAM:
> > +
> > + Required properties:
> > + - compatible : should be "fsl,<chip>-qe-muram-usb-pram",
> > + "fsl,qe-muram-usb-pram", "fsl,cpm-muram-usb-pram".
> > + - reg : should contain USB PRAM location and length.
> > +
> > + Example:
> > +
> > + usb-pram@8b00 {
> > + compatible = "fsl,mpc8360-qe-muram-usb-pram",
> > + "fsl,qe-muram-usb-pram",
> > + "fsl,cpm-muram-usb-pram";
> > + reg = <0x8b00 0x100>;
> > + };
> > +
> > + t) Freescale QUICC Engine USB Controller
> > +
> > + Required properties:
> > + - compatible : should be "fsl,<chip>-qe-usb", "fsl,qe-usb",
> > + "fsl,usb-fhci"
> > + - reg : should contain gtm registers location and length.
> > + - interrupts : should contain USB interrupt.
> > + - interrupt-parent : interrupt source phandle.
> > + - fsl,fullspeed-clock : specifies the full speed USB clock source.
> > + - fsl,lowspeed-clock : specifies the low speed USB clock source.
> > + - fsl,usb-mode : should be "host".
> > + - linux,hub-power-budget : optional, USB power budget for the root
> hub
> > + in mA.
> > + - gpios : should specify GPIOs in this order: USBOE, USBTP, USBTN,
> USBRP,
> > + USBRN, SPEED (optional), and SUSPEND (optional).
>
> Suspend should in my opinion be renamed power (or bus power or anything
> similar), as it controls the USB power and not USB PHY sleep mode.
Thanks, I'll rename it.
> > + Example:
> > +
> > + usb@6c0 {
> > + compatible = "fsl,mpc8360-qe-usb", "fsl,qe-usb",
> > + "fsl,usb-fhci";
> > + reg = <0x6c0 0x40>;
> > + interrupts = <11>;
> > + interrupt-parent = <&qeic>;
> > + fsl,fullspeed-clock = "clk21";
> > + fsl,usb-mode = "host";
> > + gpios = <&qe_pio_b 2 0 /* USBOE */
> > + &qe_pio_b 3 0 /* USBTP */
> > + &qe_pio_b 8 0 /* USBTN */
> > + &qe_pio_b 9 0 /* USBRP */
> > + &qe_pio_b 11 0 /* USBRN */
> > + &qe_pio_e 20 0 /* SPEED */
> > + &qe_pio_e 21 0 /* SUSPN */>;
> > + };
> > +
> > + u) LEDs on GPIOs
> > +
> > + Required properties:
> > + - compatible : should be "linux,gpio-led".
> > + - linux,name : LED name.
> > + - linux,active-low : property should be present if LED wired as
> > + active-low.
>
> Just thinking out loud, wasn't the third GPIO cell supposed to be used to
> encode such properties ?
Oh well, yes, origianally I wrote that it `may' encode this information.
Encoding this would be really useful if node is using many gpios that are
wired in some random inverted/not-inverted way...
gpios <&qe_pio 2 1 /* wired active-low */
&qe_pio 3 0 /* wired active-high */
&qe_pio 4 1 /* wired active-low */
&qe_pio 5 0 /* wired active-high */
&qe_pio 6 1>; /* wired active-low */
But we didn't see this setup yet, and I'm not sure if I want to implement
this support now just for the LEDs. Specifying this information via
gpios = <> property or separate one isn't going to conflict anyhow
and when we'll implement actual flags for GPIOs, we'll easily could
switch to it in backwards compatible way.
Thanks for brining it up though.
> > + - linux,default-trigger : Linux default trigger for this LED.
> > + - linux,brightness : default brightness.
> > + - gpios : should specify LED GPIO.
> > +
> > + Example:
> > +
> > + led@0 {
> > + compatible = "linux,gpio-led";
> > + linux,name = "pwr";
> > + linux,brightness = <1>;
> > + linux,active-low;
> > + gpios = <&mcu_pio 0>;
> > + };
> > +
> > + led@1 {
> > + compatible = "linux,gpio-led";
> > + linux,name = "hdd";
> > + linux,default-trigger = "ide-disk";
> > + linux,active-low;
> > + gpios = <&mcu_pio 1>;
> > + };
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-23 13:53 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <20080423144756.3fc9b1bf@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]
On Wednesday 23 April 2008 14:47, Jean Delvare wrote:
> On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> > On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > > I still don't know exactly what happened there... I think I saw some
> > > "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> > > listed below, which I thought they depended upon.
> >
> > The code that went upstream introduces helper functions to create i2c
> > devices from information supplied by the OF device tree. It doesn't
> > strictly depend on the below patches, but the new devices won't be
> > properly bound to a driver without them.
>
> OK. So... Out of the 7 patches Jochen sent originally, only 1 ([3/7] OF
> helpers for the i2c API) went upstream. Am I correct?
>
> Jochen, I'm a bit confused by the dependencies that exist - or not -
> between these 7 patches you sent at once. I thought they had to be
> applied in sequence but it seems not? And some of them should
> apparently go through me i2c tree but others (e.g. [7/7]) not?
>
> I would appreciate if you could summarize quickly which patches depend
> on others in which way. If we can make smaller subsets of patches, that
> will be easier for me to review and push upstream on my limited time.
Here is a summary based on my understanding of the situation. Jochen please
correct me if I'm wrong.
[PATCH1/7] i2c: Add support for device alias names
This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). It basically
adds device id table found in various subsystems (PCI, USB, ...) to i2c
new-style drivers.
The patch extends the new-style i2c device/driver matching code to support
device id tables. It modifies the drivers accordingly, as the probe function
now takes an extra argument (pointer to the device id entry that matched),
but doesn't add device id tables to the drivers.
[PATCH2/7] i2c: Convert all new-style drivers to use module aliasing
This patch adds the device id tables to the new-style i2c drivers. It depends
on the previous patch.
[PATCH3/7] i2c: OF helpers for the i2c API
This one has already been applied through the ppc subsystem. It adds helper
functions to instantiate i2c devices from the OF device tree. The patch has
no compile time dependencies but relies on 1/7 and 2/7 to bind devices to
drivers at runtime.
[PATCH4/7] i2c: Convert PowerPC MPC i2c to of_platform_driver from
platform_driver
This patch should go through the ppc subsystem. It adds OF device tree support
to the i2c-mpc driver. To the best of my knowledge it depends on 3/7 only.
[PATCH5/7] i2c: Kill the old driver matching scheme
This patch removes the old driver_name/type scheme for i2c driver matching.
Only the new matching scheme introduced by 2/7 remains for new-style drivers.
[PATCH6/7] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
This one introduces a new i2c bus driver. It should go through the ppc
subsystem. To the best of my knowledge it depends on 3/7 only.
[PATCH7/7] [POWERPC] Add i2c pins to dts and board setup
This last patch configures i2c pins on various powerpc boards and updates the
associated device trees to include the i2c controller. It should go through
the ppc subsystem. It has no compile-time dependency on any other patch in
the serie.
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jon Smirl @ 2008-04-23 13:46 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Alessandro Zummo, rtc-linux, linuxppc-dev list, i2c, Jean Delvare,
Andrew Morton
In-Reply-To: <480F390A.90707@scram.de>
On 4/23/08, Jochen Friedrich <jochen@scram.de> wrote:
> Hi Jean,
>
>
> > Jochen, I'm a bit confused by the dependencies that exist - or not -
> > between these 7 patches you sent at once. I thought they had to be
> > applied in sequence but it seems not? And some of them should
> > apparently go through me i2c tree but others (e.g. [7/7]) not?
>
>
> [1/7] and [2/7] are forward ports of patches from you. I'm currently
> just running a make allmodconfig compile to check if it really caught
> all affected i2c drivers.
>
> These are the patches we are talking about.
>
> [3/7] is the OF helper stuff which translates between OF names and
> i2c types. It does NOT translate OF names to module names, but relies
> on [1/7] to do so. Without [1/7], [3/7] still applies, but module
> auto loading won't work.
>
> This has been applied to 2.6.26.
>
>
> > I would appreciate if you could summarize quickly which patches depend
> > on others in which way. If we can make smaller subsets of patches, that
> > will be easier for me to review and push upstream on my limited time.
>
>
> [4/7] is the patch from Jon Smirl to convert i2c-mpc to OF. This relies
> on [3/7] instead of Jons initial OF-autoloading patches you didn't like.
> As there were no comments at all, I would however postpone this to 2.6.27.
This is why we chose to ignore mainline and do these changes in our
own tree. There is no certainty when or if these patches will ever go
in. This has also caused us to stop submitting code in other areas.
It's all intertwined and too much work to break up.
> [5/7] is the cleanup patch (originating from you) which completely removes
> old driver matching scheme. This should probably wait until 2.6.27, as well.
> This relies on [1/7] and [2/7].
>
> [6/7] and [7/7] are a new driver and depend on [3/7]. This can wait for 2.6.27,
> as well (i would rather like to see those in -mm to get more testing, though).
>
> Thanks,
>
> Jochen
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jochen Friedrich @ 2008-04-23 13:26 UTC (permalink / raw)
To: Jean Delvare
Cc: Alessandro Zummo, rtc-linux, linuxppc-dev list, i2c,
Andrew Morton
In-Reply-To: <20080423144756.3fc9b1bf@hyperion.delvare>
Hi Jean,
> Jochen, I'm a bit confused by the dependencies that exist - or not -
> between these 7 patches you sent at once. I thought they had to be
> applied in sequence but it seems not? And some of them should
> apparently go through me i2c tree but others (e.g. [7/7]) not?
[1/7] and [2/7] are forward ports of patches from you. I'm currently
just running a make allmodconfig compile to check if it really caught
all affected i2c drivers.
These are the patches we are talking about.
[3/7] is the OF helper stuff which translates between OF names and
i2c types. It does NOT translate OF names to module names, but relies
on [1/7] to do so. Without [1/7], [3/7] still applies, but module
auto loading won't work.
This has been applied to 2.6.26.
> I would appreciate if you could summarize quickly which patches depend
> on others in which way. If we can make smaller subsets of patches, that
> will be easier for me to review and push upstream on my limited time.
[4/7] is the patch from Jon Smirl to convert i2c-mpc to OF. This relies
on [3/7] instead of Jons initial OF-autoloading patches you didn't like.
As there were no comments at all, I would however postpone this to 2.6.27.
[5/7] is the cleanup patch (originating from you) which completely removes
old driver matching scheme. This should probably wait until 2.6.27, as well.
This relies on [1/7] and [2/7].
[6/7] and [7/7] are a new driver and depend on [3/7]. This can wait for 2.6.27,
as well (i would rather like to see those in -mm to get more testing, though).
Thanks,
Jochen
^ permalink raw reply
* RE: Xilinx GPIO driver / CONFIG_OF
From: John Linn @ 2008-04-23 13:21 UTC (permalink / raw)
To: Johann Baudy, linuxppc-dev
In-Reply-To: <7e0dd21a0804230548n21a57969pc5f0acb7d9c77e50@mail.gmail.com>
Hi Johann,
Not to my knowledge yet. We have it on our list to do.
Thanks,
John
-----Original Message-----
From: linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-bounces+john.linn=3Dxilinx.com@ozlabs.org] On =
Behalf
Of Johann Baudy
Sent: Wednesday, April 23, 2008 6:48 AM
To: linuxppc-dev@ozlabs.org
Subject: Xilinx GPIO driver / CONFIG_OF
Hi All,
Is there a Xilinx GPIO driver draft that uses CONFIG_OF somewhere?
Thanks in advance,
Johann Baudy
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jon Smirl @ 2008-04-23 13:11 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, i2c, rtc-linux
In-Reply-To: <20080423131657.71d6312f@hyperion.delvare>
On 4/23/08, Jean Delvare <khali@linux-fr.org> wrote:
> Hi Laurent,
>
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
>
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks are tired of having to wait
> > > > for me and may push it to Linus through their tree? That would be fine
> > > > with me, as I don't want to be the one delaying something many
> > > > developers want (but I also can't sign patches I've not even read.)
My company has stuck with 2.6.24 and my original patch set. We'd like
to sync back up with mainline at some point.
> I still don't know exactly what happened there... I think I saw some
> "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> listed below, which I thought they depended upon.
>
>
> > > The required patches are:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> > >
> > > which are just the forward ported patches you sent to the poweprc mailing
> > > list some time ago:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16283
> >
> > Given that the required patches are just forward-ported versions of patches
> > you sent (and thus probably reviewed as well :-)), what's the best way to get
> > them in 2.6.26 (if at all possible) ?
>
>
> It's not that easy. A lot of new new-style i2c drivers have shown up in
> the kernel since I wrote my patches (themselves derived heavily from
> Jon Smirl's). Even if Jochen's patches are based on mine, we still need
> to take a careful look on how each driver is modified, I remember for
> example that some v4l drivers were using the original new-style driver
> binding in a way I did not expect. So I can't just sign these patches
> and hope they didn't break anything. It needs care, and this requires
> time.
>
> I will do my best to get this done before the 2.6.26 merge window
> closes, but I can't promise anything.
>
> --
>
> Jean Delvare
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [BUG] linux-next: Tree for April 23 - kernel panic during bootup on x86_64 and ppc
From: Kamalesh Babulal @ 2008-04-23 13:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: LKML, linuxppc-dev, linux-next, Ingo Molnar, Balbir Singh
In-Reply-To: <20080423190248.2f21b33f.sfr@canb.auug.org.au>
Hi Stephen,
The next-20080423 kernel panics at various points on x86_64 and ppc machines
I have listed the call trace of ppc machine followed by the trace of x86_64
on ppc box
-----------
kernel BUG at arch/powerpc/lib/locks.c:36!
Oops: Exception in kernel mode, sig: 5 [#43]
SMP NR_CPUS=128 NUMA pSeries
Modules linked in:
NIP: c000000000031e34 LR: c0000000004b91bc CTR: 0000000000000000
REGS: c000000042043160 TRAP: 0700 Tainted: G D (2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 44000044 XER: 20000006
TASK = c00000007e030000[1] 'swapper' THREAD: c000000042040000 CPU: 5
GPR00: 0000000000000001 c0000000420433e0 c0000000008245a8 c0000000426ef580
GPR04: 0000000000000001 0000000000000000 0000000000000000 0000000000000000
GPR08: c000000041007070 0000000000000001 00000000ffffffff 000000000000ffff
GPR12: 0000000600000004 c00000000073b900 0000000000000000 c000000042536000
GPR16: 4000000002100000 c0000000005f8010 0000000000000000 000000000023f000 Re:
GPR20: 00000000027d69c8 c0000000006d69c8 00000000000000a0 c00000007e95c800
GPR24: c000000042043b10 c000000042043b10 0000000000000000 0000000000000000
GPR28: c0000000426ef500 c0000000008a5b4c c0000000007c3c90 c0000000426ef580
NIP [c000000000031e34] .__spin_yield+0x28/0x80
LR [c0000000004b91bc] ._spin_lock+0x5c/0x88
Call Trace:
[c0000000420433e0] [c000000042043b10] 0xc000000042043b10 (unreliable)
[c000000042043450] [c0000000004b91bc] ._spin_lock+0x5c/0x88
[c0000000420434d0] [c0000000000de66c] .get_unused_fd_flags+0x38/0x174
[c000000042043570] [c00000000012a664] .load_elf_binary+0x18c/0x1670
[c0000000420436b0] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043760] [c000000000126ab0] .load_script+0x274/0x2a0
[c000000042043890] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043940] [c0000000000e7c64] .do_execve+0x180/0x258
[c000000042043a00] [c000000000010714] .sys_execve+0x70/0xac
[c000000042043aa0] [c0000000000086ac] syscall_exit+0x0/0x40
--- Exception: c01 at .kernel_execve+0x8/0x14
LR = .run_init_process+0x28/0x40
[c000000042043d90] [c0000000000f05e4] .sys_dup+0x2c/0x44 (unreliable)
[c000000042043e10] [c000000000009284] .init_post+0x98/0xf8
[c000000042043ea0] [c0000000006a2dc4] .kernel_init+0x38c/0x3c0
[c000000042043f90] [c000000000025304] .kernel_thread+0x4c/0x68
Instruction dump:
7c0803a6 4e800020 7c0802a6 f8010010 f821ff91 81430000 2faa0000 794b0420
2b0b007f 419e0054 7c000026 5400d7fe <0b000000> e8029068 79695564 7d290214
---[ end trace 8640abe69a316dee ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
[c000000042042c80] [c00000000000f9e8] .show_stack+0x70/0x1bc (unreliable)
[c000000042042d30] [c000000000055704] .panic+0x80/0x1b8
[c000000042042dd0] [c00000000005a270] .do_exit+0x8c/0x758
[c000000042042e90] [c000000000023778] .die+0x24c/0x27c
[c000000042042f30] [c000000000023aa8] ._exception+0x88/0x204
[c0000000420430f0] [c000000000004a84] program_check_common+0x104/0x180
--- Exception: 700 at .__spin_yield+0x28/0x80
LR = ._spin_lock+0x5c/0x88
[c0000000420433e0] [c000000042043b10] 0xc000000042043b10 (unreliable)
[c000000042043450] [c0000000004b91bc] ._spin_lock+0x5c/0x88
[c0000000420434d0] [c0000000000de66c] .get_unused_fd_flags+0x38/0x174
[c000000042043570] [c00000000012a664] .load_elf_binary+0x18c/0x1670
[c0000000420436b0] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043760] [c000000000126ab0] .load_script+0x274/0x2a0
[c000000042043890] [c0000000000e62d8] .search_binary_handler+0xf0/0x2e4
[c000000042043940] [c0000000000e7c64] .do_execve+0x180/0x258
[c000000042043a00] [c000000000010714] .sys_execve+0x70/0xac
[c000000042043aa0] [c0000000000086ac] syscall_exit+0x0/0x40
--- Exception: c01 at .kernel_execve+0x8/0x14
LR = .run_init_process+0x28/0x40
[c000000042043d90] [c0000000000f05e4] .sys_dup+0x2c/0x44 (unreliable)
[c000000042043e10] [c000000000009284] .init_post+0x98/0xf8
[c000000042043ea0] [c0000000006a2dc4] .kernel_init+0x38c/0x3c0
[c000000042043f90] [c000000000025304] .kernel_thread+0x4c/0x68
Pid: 21, comm: khelper Not tainted 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
RIP: 0010:[<ffffffff804eaa77>] [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP: 0000:ffff81003fa9beb0 EFLAGS: 00010202
RAX: 0000000000000075 RBX: ffff81003fa8e630 RCX: ffff81003fa9bee0
RDX: ffff81003fa8e7c8 RSI: ffff81003fa9a010 RDI: 0000000000000003
RBP: ffff81003fa9beb0 R08: 0000000000000000 R09: ffff810001026458
R10: ffff81003fa8e630 R11: 0000000300000000 R12: 0000000000000000
R13: ffff81003fa8e758 R14: ffffffff807e9420 R15: 0000000000000001
FS: 0000000000000000(0000) GS:ffff81003f9a0800(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 21, threadinfo ffff81003fa9a000, task ffff81003fa8e630)
Stack: ffff81003fa8e630 ffffffff80249cd9 ffff81003fa9bda8 ffff81003fa8e630
ffff81003f9c6000 ffffffff80238a93 ffff81003fa9bee0 ffff81003fa9bee0
ffffffff80646d40 0000000000000000 ffff81003f9a5120 0000000000000000
Call Trace:
[<ffffffff80249cd9>] switch_task_namespaces+0x20/0x54
[<ffffffff80238a93>] ? do_exit+0x4d3/0x661
[<ffffffff80243e58>] ? request_module+0x0/0x15c
[<ffffffff802439f7>] ? __call_usermodehelper+0x0/0x60
[<ffffffff8020cda8>] ? child_rip+0xa/0x12
[<ffffffff802439f7>] ? __call_usermodehelper+0x0/0x60
[<ffffffff80243cfd>] ? ____call_usermodehelper+0x0/0x15b
[<ffffffff8020cd9e>] ? child_rip+0x0/0x12
Code: 33 00 01 75 16 e8 98 f8 d4 ff e8 91 70 d4 ff e8 f2 f4 d4 ff b8 01 00 00 00 eb 02 31 c0 c9 c3 55 48 89 e5 e8 74 e3 d3 ff 83 c0 74 <27> 65 48 8b 04 25 10 00 00 00 f6 80 47 e0 ff ff 10 75 15 83 3d
on x86_64
----------
RIP [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP <ffff81003fa9beb0>
invalid opcode: 0000 [2] <4>---[ end trace ca143223eefdc828 ]---
Fixing recursive fault but reboot is needed!
SMP
last sysfs file:
CPU 0
Modules linked in:
Pid: 1, comm: swapper Tainted: G D 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
RIP: 0010:[<ffffffff804eaa77>] [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP: 0000:ffff81003f9c9e30 EFLAGS: 00010206
RAX: 0000000000000074 RBX: ffffffff806415a0 RCX: 0000000000000000
RDX: 0000000000001312 RSI: ffff81003f9c8010 RDI: 0000000000000003
RBP: ffff81003f9c9e30 R08: 00000000000003c0 R09: 7fffffffffffffff
R10: ffff8100010193c0 R11: 0000000300000000 R12: 00000000fffffff4
R13: ffff81003f9a6500 R14: ffffffff807e9420 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff80688000(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000000 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff81003f9c8000, task ffff81003f9c6000)
Stack: ffff81003f9c9e80 ffffffff804eb062 000000133f9b60e0 ffffffff80653e00
ffff81003f9a6500 ffffffff802d8e28 ffff81003f9a6500 ffffffff80653e00
ffff81003f9a6550 ffffffff802d897e ffff81003f9a6500 0000000000000000
Call Trace:
[<ffffffff804eb062>] mutex_lock+0x1e/0x2f
[<ffffffff802d8e28>] ? sysfs_addrm_start+0x26/0x9a
[<ffffffff802d897e>] ? sysfs_add_file_mode+0x43/0x74
[<ffffffff807dd223>] ? cpu_dev_init+0x2c/0x79
[<ffffffff807c08bb>] ? kernel_init+0x10a/0x2d9
[<ffffffff804ebd6d>] ? _spin_unlock_irq+0x9/0xd
[<ffffffff80230d5d>] ? finish_task_switch+0x5f/0x86
[<ffffffff8020cda8>] ? child_rip+0xa/0x12
[<ffffffff807c07b1>] ? kernel_init+0x0/0x2d9
[<ffffffff8020cd9e>] ? child_rip+0x0/0x12
Code: 33 00 01 75 16 e8 98 f8 d4 ff e8 91 70 d4 ff e8 f2 f4 d4 ff b8 01 00 00 00 eb 02 31 c0 c9 c3 55 48 89 e5 e8 74 e3 d3 ff 83 c0 74 <27> 65 48 8b 04 25 10 00 00 00 f6 80 47 e0 ff ff 10 75 15 83 3d
RIP [<ffffffff804eaa77>] _cond_resched+0xc/0x38
RSP <ffff81003f9c9e30>
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: swapper Tainted: G D 2.6.25-next-20080423-sched-devel.git-x86-latest.git-autotest #1
Call Trace:
[<ffffffff80235624>] panic+0x86/0x146
[<ffffffff8023611c>] printk+0x4e/0x56
[<ffffffff80238631>] do_exit+0x71/0x661
[<ffffffff804ec331>] oops_begin+0x0/0x8c
[<ffffffff8020e224>] do_invalid_op+0x87/0x91
[<ffffffff804eaa77>] _cond_resched+0xc/0x38
[<ffffffff804ebd6d>] _spin_unlock_irq+0x9/0xd
[<ffffffff8022bd23>] __wake_up+0x38/0x4e
[<ffffffff804ebf79>] error_exit+0x0/0x51
[<ffffffff804eaa77>] _cond_resched+0xc/0x38
[<ffffffff804eb062>] mutex_lock+0x1e/0x2f
[<ffffffff802d8e28>] sysfs_addrm_start+0x26/0x9a
[<ffffffff802d897e>] sysfs_add_file_mode+0x43/0x74
[<ffffffff807dd223>] cpu_dev_init+0x2c/0x79
[<ffffffff807c08bb>] kernel_init+0x10a/0x2d9
[<ffffffff804ebd6d>] _spin_unlock_irq+0x9/0xd
[<ffffffff80230d5d>] finish_task_switch+0x5f/0x86
[<ffffffff8020cda8>] child_rip+0xa/0x12
[<ffffffff807c07b1>] kernel_init+0x0/0x2d9
[<ffffffff8020cd9e>] child_rip+0x0/0x12
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* [PATCH v2] [POWERPC] Port fixmap from x86 and use for kmap_atomic
From: Kumar Gala @ 2008-04-23 13:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The fixmap code from x86 allows us to have compile time virtual addresses
that we change the physical addresses of at run time.
This is useful for applications like kmap_atomic, PCI config that is done
via direct memory map, kexec/kdump.
We got ride of CONFIG_HIGHMEM_START as we can now determine a more optimal
location for PKMAP_BASE based on where the fixmap addresses start and
working back from there.
Additionally, the kmap code in asm-powerpc/highmem.h always had debug
enabled. Moved to using CONFIG_DEBUG_HIGHMEM to determine if we should
have the extra debug checking.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Removed __FIXADDR_TOP, __FIXADDR_BOOT_SIZE, and FIXADDR_BOOT_START
as they were duplicates of other defines and held over from the initial
x86 port.
- k
arch/powerpc/Kconfig | 14 -----
arch/powerpc/mm/init_32.c | 8 ---
arch/powerpc/mm/mem.c | 32 ++++++++++--
arch/powerpc/mm/pgtable_32.c | 23 +++++++++
include/asm-powerpc/fixmap.h | 108 +++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/highmem.h | 41 ++++++++-------
6 files changed, 179 insertions(+), 47 deletions(-)
create mode 100644 include/asm-powerpc/fixmap.h
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index fdc755a..20f45a8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -626,20 +626,6 @@ config ADVANCED_OPTIONS
comment "Default settings for advanced configuration options are used"
depends on !ADVANCED_OPTIONS
-config HIGHMEM_START_BOOL
- bool "Set high memory pool address"
- depends on ADVANCED_OPTIONS && HIGHMEM
- help
- This option allows you to set the base address of the kernel virtual
- area used to map high memory pages. This can be useful in
- optimizing the layout of kernel virtual memory.
-
- Say N here unless you know what you are doing.
-
-config HIGHMEM_START
- hex "Virtual start address of high memory pool" if HIGHMEM_START_BOOL
- default "0xfe000000"
-
config LOWMEM_SIZE_BOOL
bool "Set maximum low memory"
depends on ADVANCED_OPTIONS
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 578750e..1952b4d 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -71,14 +71,6 @@ unsigned long agp_special_page;
EXPORT_SYMBOL(agp_special_page);
#endif
-#ifdef CONFIG_HIGHMEM
-pte_t *kmap_pte;
-pgprot_t kmap_prot;
-
-EXPORT_SYMBOL(kmap_prot);
-EXPORT_SYMBOL(kmap_pte);
-#endif
-
void MMU_init(void);
/* XXX should be in current.h -- paulus */
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 0062e6b..5ccb579 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -45,6 +45,7 @@
#include <asm/tlb.h>
#include <asm/sections.h>
#include <asm/vdso.h>
+#include <asm/fixmap.h>
#include "mmu_decl.h"
@@ -57,6 +58,20 @@ int init_bootmem_done;
int mem_init_done;
unsigned long memory_limit;
+#ifdef CONFIG_HIGHMEM
+pte_t *kmap_pte;
+pgprot_t kmap_prot;
+
+EXPORT_SYMBOL(kmap_prot);
+EXPORT_SYMBOL(kmap_pte);
+
+static inline pte_t *virt_to_kpte(unsigned long vaddr)
+{
+ return pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr),
+ vaddr), vaddr), vaddr);
+}
+#endif
+
int page_is_ram(unsigned long pfn)
{
unsigned long paddr = (pfn << PAGE_SHIFT);
@@ -311,14 +326,19 @@ void __init paging_init(void)
unsigned long top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
+#ifdef CONFIG_PPC32
+ unsigned long v = __fix_to_virt(__end_of_fixed_addresses - 1);
+ unsigned long end = __fix_to_virt(FIX_HOLE);
+
+ for (; v < end; v += PAGE_SIZE)
+ map_page(v, 0, 0); /* XXX gross */
+#endif
+
#ifdef CONFIG_HIGHMEM
map_page(PKMAP_BASE, 0, 0); /* XXX gross */
- pkmap_page_table = pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k
- (PKMAP_BASE), PKMAP_BASE), PKMAP_BASE), PKMAP_BASE);
- map_page(KMAP_FIX_BEGIN, 0, 0); /* XXX gross */
- kmap_pte = pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k
- (KMAP_FIX_BEGIN), KMAP_FIX_BEGIN), KMAP_FIX_BEGIN),
- KMAP_FIX_BEGIN);
+ pkmap_page_table = virt_to_kpte(PKMAP_BASE);
+
+ kmap_pte = virt_to_kpte(__fix_to_virt(FIX_KMAP_BEGIN));
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 64c44bc..80d1bab 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -29,6 +29,7 @@
#include <asm/pgtable.h>
#include <asm/pgalloc.h>
+#include <asm/fixmap.h>
#include <asm/io.h>
#include "mmu_decl.h"
@@ -387,3 +388,25 @@ void kernel_map_pages(struct page *page, int numpages, int enable)
change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
}
#endif /* CONFIG_DEBUG_PAGEALLOC */
+
+static int fixmaps;
+unsigned long FIXADDR_TOP = 0xfffff000;
+EXPORT_SYMBOL(FIXADDR_TOP);
+
+void __set_fixmap (enum fixed_addresses idx, phys_addr_t phys, pgprot_t flags)
+{
+ unsigned long address = __fix_to_virt(idx);
+
+ if (idx >= __end_of_fixed_addresses) {
+ BUG();
+ return;
+ }
+
+ map_page(address, phys, flags);
+ fixmaps++;
+}
+
+void __this_fixmap_does_not_exist(void)
+{
+ WARN_ON(1);
+}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
new file mode 100644
index 0000000..974b6de
--- /dev/null
+++ b/include/asm-powerpc/fixmap.h
@@ -0,0 +1,108 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ *
+ * Copyright 2008 Freescale Semiconductor Inc.
+ * Port to powerpc added by Kumar Gala
+ */
+
+#ifndef _ASM_FIXMAP_H
+#define _ASM_FIXMAP_H
+
+extern unsigned long FIXADDR_TOP;
+
+#ifndef __ASSEMBLY__
+#include <linux/kernel.h>
+#include <asm/page.h>
+#ifdef CONFIG_HIGHMEM
+#include <linux/threads.h>
+#include <asm/kmap_types.h>
+#endif
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xfffff000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+ /* FIX_PCIE_MCFG, */
+ __end_of_fixed_addresses
+};
+
+extern void __set_fixmap (enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+extern void __this_fixmap_does_not_exist(void);
+
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without tranlation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ /*
+ * this branch gets completely eliminated after inlining,
+ * except when someone tries to use fixaddr indices in an
+ * illegal way. (such as mixing up address types or using
+ * out-of-range indices).
+ *
+ * If it doesn't get removed, the linker will complain
+ * loudly with a reasonably clear error message..
+ */
+ if (idx >= __end_of_fixed_addresses)
+ __this_fixmap_does_not_exist();
+
+ return __fix_to_virt(idx);
+}
+
+static inline unsigned long virt_to_fix(const unsigned long vaddr)
+{
+ BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+ return __virt_to_fix(vaddr);
+}
+
+#endif /* !__ASSEMBLY__ */
+#endif
diff --git a/include/asm-powerpc/highmem.h b/include/asm-powerpc/highmem.h
index f7b21ee..5d99b64 100644
--- a/include/asm-powerpc/highmem.h
+++ b/include/asm-powerpc/highmem.h
@@ -27,9 +27,7 @@
#include <asm/kmap_types.h>
#include <asm/tlbflush.h>
#include <asm/page.h>
-
-/* undef for production */
-#define HIGHMEM_DEBUG 1
+#include <asm/fixmap.h>
extern pte_t *kmap_pte;
extern pgprot_t kmap_prot;
@@ -40,14 +38,12 @@ extern pte_t *pkmap_page_table;
* easily, subsequent pte tables have to be allocated in one physical
* chunk of RAM.
*/
-#define PKMAP_BASE CONFIG_HIGHMEM_START
#define LAST_PKMAP (1 << PTE_SHIFT)
#define LAST_PKMAP_MASK (LAST_PKMAP-1)
+#define PKMAP_BASE ((FIXADDR_START - PAGE_SIZE*(LAST_PKMAP + 1)) & PMD_MASK)
#define PKMAP_NR(virt) ((virt-PKMAP_BASE) >> PAGE_SHIFT)
#define PKMAP_ADDR(nr) (PKMAP_BASE + ((nr) << PAGE_SHIFT))
-#define KMAP_FIX_BEGIN (PKMAP_BASE + 0x00400000UL)
-
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
@@ -73,7 +69,7 @@ static inline void kunmap(struct page *page)
* be used in IRQ contexts, so in some (very limited) cases we need
* it.
*/
-static inline void *kmap_atomic(struct page *page, enum km_type type)
+static inline void *kmap_atomic_prot(struct page *page, enum km_type type, pgprot_t prot)
{
unsigned int idx;
unsigned long vaddr;
@@ -84,34 +80,39 @@ static inline void *kmap_atomic(struct page *page, enum km_type type)
return page_address(page);
idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = KMAP_FIX_BEGIN + idx * PAGE_SIZE;
-#ifdef HIGHMEM_DEBUG
- BUG_ON(!pte_none(*(kmap_pte+idx)));
+ vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
+#ifdef CONFIG_DEBUG_HIGHMEM
+ BUG_ON(!pte_none(*(kmap_pte-idx)));
#endif
- set_pte_at(&init_mm, vaddr, kmap_pte+idx, mk_pte(page, kmap_prot));
+ set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot));
flush_tlb_page(NULL, vaddr);
return (void*) vaddr;
}
+static inline void *kmap_atomic(struct page *page, enum km_type type)
+{
+ return kmap_atomic_prot(page, type, kmap_prot);
+}
+
static inline void kunmap_atomic(void *kvaddr, enum km_type type)
{
-#ifdef HIGHMEM_DEBUG
+#ifdef CONFIG_DEBUG_HIGHMEM
unsigned long vaddr = (unsigned long) kvaddr & PAGE_MASK;
- unsigned int idx = type + KM_TYPE_NR*smp_processor_id();
+ enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
- if (vaddr < KMAP_FIX_BEGIN) { // FIXME
+ if (vaddr < __fix_to_virt(FIX_KMAP_END)) {
pagefault_enable();
return;
}
- BUG_ON(vaddr != KMAP_FIX_BEGIN + idx * PAGE_SIZE);
+ BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
/*
* force other mappings to Oops if they'll try to access
* this pte without first remap it
*/
- pte_clear(&init_mm, vaddr, kmap_pte+idx);
+ pte_clear(&init_mm, vaddr, kmap_pte-idx);
flush_tlb_page(NULL, vaddr);
#endif
pagefault_enable();
@@ -120,12 +121,14 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type type)
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
+ pte_t *pte;
- if (vaddr < KMAP_FIX_BEGIN)
+ if (vaddr < FIXADDR_START)
return virt_to_page(ptr);
- idx = (vaddr - KMAP_FIX_BEGIN) >> PAGE_SHIFT;
- return pte_page(kmap_pte[idx]);
+ idx = virt_to_fix(vaddr);
+ pte = kmap_pte - (idx - FIX_KMAP_BEGIN);
+ return pte_page(*pte);
}
#define flush_cache_kmaps() flush_cache_all()
--
1.5.4.1
^ permalink raw reply related
* Re: Patches added to powerpc.git master and powerpc-next branches
From: Kumar Gala @ 2008-04-23 12:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18445.11801.422321.151268@cargo.ozlabs.ibm.com>
On Apr 21, 2008, at 7:15 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> Once again I want to go through it carefully and understand how it
>>> all
>>> works, and in particular understand things like the way it ensures
>>> that the base address for the kmap region is aligned to a 4M
>>> boundary
>>> so all the kmap ptes are in a single page (assuming it does :).
>>
>> I'm not clear on why this is needed. I can see value in having the
>> PGD entry in place but the pte PAs would be changing all the time
>> so I
>> don't see what benefit there is in keeping them in one page.
>
> Have a look at map_new_virtual in mm/highmem.c. In particular:
>
> set_pte_at(&init_mm, vaddr,
> &(pkmap_page_table[last_pkmap_nr]), mk_pte(page,
> kmap_prot));
>
> assumes that the ptes that kmap uses are in a contiguous array whose
> base is pkmap_page_table.
>
>> For normal kmap ptes we cover things in one PGD via:
>>
>> #define PKMAP_BASE ((FIXADDR_BOOT_START -
>> PAGE_SIZE*(LAST_PKMAP +
>> 1)) & PMD_MASK)
>
> OK, that probably does the trick ... <checks> ... yes it does.
>
> We seem to have a distinction without a difference between
> FIXADDR_START and FIXADDR_BOOT_START, and similarly between
> __FIXADDR_SIZE and __FIXADDR_BOOT_SIZE. Is there any actual
> difference and if not why do we have two names for the same thing?
>
>
> Also, we seem to have an unnecessary distinction (and unnecessary
> casting) between __FIXADDR_TOP and FIXADDR_TOP.
its left over from the x86 port. I'll get rid of __FIXADDR_BOOT_SIZE,
FIXADDR_BOOT_START, and __FIXADDR_TOP.
If we want the early ioremap support in the future we can add back
__FIXADDR_BOOT_SIZE and FIXADDR_BOOT_START.
- k
^ permalink raw reply
* Re: [U-Boot-Users] AMCC PPC440EPx/sequoia stability question...
From: Stefan Roese @ 2008-04-23 12:49 UTC (permalink / raw)
To: u-boot-users; +Cc: Dave Littell, linuxppc-embedded
In-Reply-To: <480EADF4.2020706@verizon.net>
On Wednesday 23 April 2008, Dave Littell wrote:
> I'm working on an AMCC PPC440EPx-based platform that's similar to the
> Sequoia. The board runs pretty well, but occasionally takes exceptions
> both in U-Boot and while running Linux. The exceptions vary from
> Illegal Instructions to FP Unavailable to FP Unimplemented to ITLB and
> DTLB Errors, to DSI, etc., which made us believe there's a problem with
> SDRAM.
Yes, this is my first idea too. Almost every time such "random" errors are
seen, SDRAM setup/initialization is the cause for it.
> Sometimes there are simple hard lockups from which even the JTAG
> can't regain control. However, the SDRAM physical/electrical and DDR
> Controller configurations have been investigated in detail (and some
> corrections made) with no resulting improvement in the exception behavior.
Is the SDRAM termination similar to the one used on Sequoia too? Are you using
soldered chips and not DIMM modules? Is ECC available?
> We see problems primarily at 667 MHz but have noted some issues at 533
> MHz as well. Some boards seem particularly susceptible to this while
> others rarely (if ever) exhibit the problem.
>
> At this point all possibilities are on the table and I'm looking for any
> input from anyone with experience (good, bad, or whatever) with this
> processor and/or designs similar to the Sequoia.
If you scan the U-Boot mailing list for 440EPx/Denali DDR2 problems, you will
most likely find some references.
Please note that I recently introduced a CFG_MEM_TOP_HIDE option for the
440EPx CHIP 11 errata. I suggest you take a look at this too and see if this
changes your behavior.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jean Delvare @ 2008-04-23 12:47 UTC (permalink / raw)
To: Laurent Pinchart, Jochen Friedrich
Cc: linuxppc-dev list, Alessandro Zummo, i2c, rtc-linux
In-Reply-To: <200804231412.40038.laurentp@cse-semaphore.com>
On Wed, 23 Apr 2008 14:12:37 +0200, Laurent Pinchart wrote:
> On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> > I still don't know exactly what happened there... I think I saw some
> > "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> > listed below, which I thought they depended upon.
>
> The code that went upstream introduces helper functions to create i2c devices
> from information supplied by the OF device tree. It doesn't strictly depend
> on the below patches, but the new devices won't be properly bound to a driver
> without them.
OK. So... Out of the 7 patches Jochen sent originally, only 1 ([3/7] OF
helpers for the i2c API) went upstream. Am I correct?
Jochen, I'm a bit confused by the dependencies that exist - or not -
between these 7 patches you sent at once. I thought they had to be
applied in sequence but it seems not? And some of them should
apparently go through me i2c tree but others (e.g. [7/7]) not?
I would appreciate if you could summarize quickly which patches depend
on others in which way. If we can make smaller subsets of patches, that
will be easier for me to review and push upstream on my limited time.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Xilinx GPIO driver / CONFIG_OF
From: Johann Baudy @ 2008-04-23 12:48 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
Is there a Xilinx GPIO driver draft that uses CONFIG_OF somewhere?
Thanks in advance,
Johann Baudy
^ permalink raw reply
* Re: [RFC patch 6/9] POWERPC remove -traditional
From: Mathieu Desnoyers @ 2008-04-23 12:14 UTC (permalink / raw)
To: Kyle McMartin, Paul Mackerras
Cc: linuxppc-dev, akpm, Sam Ravnborg, Ingo Molnar, linux-kernel
In-Reply-To: <18446.48624.515912.541936@cargo.ozlabs.ibm.com>
* Paul Mackerras (paulus@samba.org) wrote:
> Mathieu Desnoyers writes:
> > Subject: [RFC patch 6/9] Re: [PATCH] Stringify support commas
> > > This is a no-no for those archs that still use -traditional.
> > > > I dunno if this is a problem for you at the moment and the
> > > > right fix is anyway to nuke -traditional.
> > > >
> > > > Sam
> >
> > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> > CC: Sam Ravnborg <sam@ravnborg.org>
> > CC: paulus@samba.org
> > CC: linuxppc-dev@ozlabs.org
> > ---
> > arch/powerpc/boot/Makefile | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Looks OK. I'll put it in my tree.
>
> Paul.
OK, although it won't be needed with v2 of the stringify with commas.
There seems to be some important details which differ between
-traditional and stdc gcc operation which makes it non-trivial to remove
the -traditional, at least on sparc. Maybe Kyle could tell us a bit more
about the nature of these limitations ?
I would wait a bit before merging until we at least identify what those
limitations are.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Laurent Pinchart @ 2008-04-23 12:12 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Alessandro Zummo, rtc-linux, i2c
In-Reply-To: <20080423131657.71d6312f@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 2765 bytes --]
Hi Jean,
On Wednesday 23 April 2008 13:16, Jean Delvare wrote:
> Hi Laurent,
>
> On Tue, 22 Apr 2008 16:11:56 +0200, Laurent Pinchart wrote:
> > Hi Jean,
> >
> > On Saturday 19 April 2008 18:43, Jochen Friedrich wrote:
> > > Jean Delvare wrote:
> > > > I'm not sure. I didn't have the time to look at it myself, but I am
> > > > under the impression that the powerpc folks are tired of having to
> > > > wait for me and may push it to Linus through their tree? That would be
> > > > fine with me, as I don't want to be the one delaying something many
> > > > developers want (but I also can't sign patches I've not even read.)
>
> I still don't know exactly what happened there... I think I saw some
> "OpenFirmware i2c" patches go upstream yesterday? But not the ones
> listed below, which I thought they depended upon.
The code that went upstream introduces helper functions to create i2c devices
from information supplied by the OF device tree. It doesn't strictly depend
on the below patches, but the new devices won't be properly bound to a driver
without them.
> > > The required patches are:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17833
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=17834
> > >
> > > which are just the forward ported patches you sent to the poweprc
> > > mailing list some time ago:
> > >
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16282
> > > http://patchwork.ozlabs.org/linuxppc/patch?id=16283
> >
> > Given that the required patches are just forward-ported versions of
> > patches you sent (and thus probably reviewed as well :-)), what's the best
> > way to get them in 2.6.26 (if at all possible) ?
>
> It's not that easy. A lot of new new-style i2c drivers have shown up in
> the kernel since I wrote my patches (themselves derived heavily from
> Jon Smirl's). Even if Jochen's patches are based on mine, we still need
> to take a careful look on how each driver is modified, I remember for
> example that some v4l drivers were using the original new-style driver
> binding in a way I did not expect. So I can't just sign these patches
> and hope they didn't break anything. It needs care, and this requires
> time.
I won't ask to merge the patches for 2.6.26-rc1 and fix introduced breakages
afterwards, I know how you would react to that :-)
> I will do my best to get this done before the 2.6.26 merge window
> closes, but I can't promise anything.
Nobody will get angry if you can't merge them in time for 2.6.26. But many
people will be happy if you can :-)
Cheers,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Jochen Friedrich @ 2008-04-23 11:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: Alessandro Zummo, rtc-linux, linuxppc-dev, i2c, Jean Delvare
In-Reply-To: <200804231335.08038.sr@denx.de>
Hi Stefan,
> Please don't get we wrong, I didn't want to put additional pressure on you
> here. I just wanted to express that I'm waiting for these patches to arrive
> upstream quite some time now too.
and unfortunately, the longer we wait the more drivers are ported to new-style
and the bigger the patch grows :(.
Thanks,
Jochen
^ permalink raw reply
* Re: [PATCH] rtc-pcf8563: Add device ids table
From: Stefan Roese @ 2008-04-23 11:35 UTC (permalink / raw)
To: Jean Delvare; +Cc: Alessandro Zummo, rtc-linux, linuxppc-dev, i2c
In-Reply-To: <20080423130919.5d55feff@hyperion.delvare>
On Wednesday 23 April 2008, Jean Delvare wrote:
> > > The patches are required for long awaited I2C support on various
> > > PowerPC boards. As the ppc architecture support is going away in
> > > 2.6.27, it would be nice to have them applied in 2.6.26.
> >
> > Yes, please.
>
> I know that many people would like to see these patches upstream
> quickly, no question about that. The problem is that I am very busy
> with my day job and my family life these days
Something I know very well too. ;)
Please don't get we wrong, I didn't want to put additional pressure on you
here. I just wanted to express that I'm waiting for these patches to arrive
upstream quite some time now too.
> so I just don't know when
> I will find the time an energy to go through this huge patch set.
Your hard work is really appreciated. Thanks a lot.
Best regards,
Stefan
^ permalink raw reply
* Re: [2.6 patch] drivers/of/of_i2c.c: add MODULE_LICENSE
From: Jochen Friedrich @ 2008-04-23 11:25 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080423095134.GZ28933@cs181133002.pp.htv.fi>
Adrian Bunk schrieb:
> After commit 585468e5d5962660867c269e26f0a4b89a599473
> ([POWERPC] i2c: Fix build breakage introduced by OF helpers)
> drivers/of/of_i2c.c needs a MODULE_LICENSE.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Jochen Friedrich <jochen@scram.de>
Thanks,
Jochen
^ 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