[PATCH] powerpc/85xx: Add support for SMP initialization
Added 85xx specifc smp_ops structure. We use ePAPR style boot release and the MPIC for IPIs at this point. Additionally added routines for secondary cpu entry and initializtion. Signed-off-by: Andy Fleming <[EMAIL PROTECTED]> Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/kernel/head_fsl_booke.S | 70 +++ arch/powerpc/platforms/85xx/Makefile |2 + arch/powerpc/platforms/85xx/smp.c| 104 ++ 3 files changed, 176 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/platforms/85xx/smp.c diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 2b57605..9a4639c 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -92,6 +92,7 @@ _ENTRY(_start); * if needed */ +_ENTRY(__early_start) /* 1. Find the index of the entry we're executing in */ bl invstr /* Find our address */ invstr:mflrr6 /* Make it accessible */ @@ -348,6 +349,15 @@ skpinv:addir6,r6,1 /* Increment */ mtspr SPRN_DBSR,r2 #endif +#ifdef CONFIG_SMP + /* Check to see if we're the second processor, and jump +* to the secondary_start code if so +*/ + mfspr r24,SPRN_PIR + cmpwi r24,0 + bne __secondary_start +#endif + /* * This is where the main kernel code starts. */ @@ -740,6 +750,9 @@ finish_tlb_load: #else rlwimi r12, r11, 26, 27, 31/* extract WIMGE from pte */ #endif +#ifdef CONFIG_SMP + ori r12, r12, MAS2_M +#endif mtspr SPRN_MAS2, r12 li r10, (_PAGE_HWEXEC | _PAGE_PRESENT) @@ -1042,6 +1055,63 @@ _GLOBAL(flush_dcache_L1) blr +#ifdef CONFIG_SMP +/* When we get here, r24 needs to hold the CPU # */ + .globl __secondary_start +__secondary_start: + lis r3,[EMAIL PROTECTED] + ori r3,r3,[EMAIL PROTECTED] + stw r24,0(r3) + + li r3,0 + mr r4,r24 /* Why? */ + bl call_setup_cpu + + lis r3,[EMAIL PROTECTED] + lwz r3,[EMAIL PROTECTED](r3) + mtctr r3 + li r26,0 /* r26 safe? */ + + /* Load each CAM entry */ +1: mr r3,r26 + bl loadcam_entry + addir26,r26,1 + bdnz1b + + /* get current_thread_info and current */ + lis r1,[EMAIL PROTECTED] + lwz r1,[EMAIL PROTECTED](r1) + lwz r2,TI_TASK(r1) + + /* stack */ + addir1,r1,THREAD_SIZE-STACK_FRAME_OVERHEAD + li r0,0 + stw r0,0(r1) + + /* ptr to current thread */ + addir4,r2,THREAD/* address of our thread_struct */ + mtspr SPRN_SPRG3,r4 + + /* Setup the defaults for TLB entries */ + li r4,(MAS4_TSIZED(BOOKE_PAGESZ_4K))@l + mtspr SPRN_MAS4,r4 + + /* Jump to start_secondary */ + lis r4,[EMAIL PROTECTED] + ori r4,r4,[EMAIL PROTECTED] + lis r3,[EMAIL PROTECTED] + ori r3,r3,[EMAIL PROTECTED] + mtspr SPRN_SRR0,r3 + mtspr SPRN_SRR1,r4 + sync + rfi + sync + + .globl __secondary_hold_acknowledge +__secondary_hold_acknowledge: + .long -1 +#endif + /* * We put a few things here that have to be page-aligned. This stuff * goes at the beginning of the data segment, which is page-aligned. diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile index cb3054e..f0798c0 100644 --- a/arch/powerpc/platforms/85xx/Makefile +++ b/arch/powerpc/platforms/85xx/Makefile @@ -1,6 +1,8 @@ # # Makefile for the PowerPC 85xx linux kernel. # +obj-$(CONFIG_SMP) += smp.o + obj-$(CONFIG_MPC8540_ADS) += mpc85xx_ads.o obj-$(CONFIG_MPC8560_ADS) += mpc85xx_ads.o obj-$(CONFIG_MPC85xx_CDS) += mpc85xx_cds.o diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c new file mode 100644 index 000..d652c71 --- /dev/null +++ b/arch/powerpc/platforms/85xx/smp.c @@ -0,0 +1,104 @@ +/* + * Author: Andy Fleming <[EMAIL PROTECTED]> + *Kumar Gala <[EMAIL PROTECTED]> + * + * Copyright 2006-2008 Freescale Semiconductor Inc. + * + * 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 +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include + +extern volatile unsigned long __secondary_hold_acknowledge; +extern void __early_start(void); + +#define BOOT_ENTRY_ADDR_UPPER 0 +#define BOOT_ENTRY_ADDR_LOWER 1 +#define BOOT_ENTRY_R3_UPPER2 +#define BOOT_ENTRY_R3_LO
Re: [PATCH] powerpc: Fix bogus cache flushing on all 40x and BookE processors
On Dec 1, 2008, at 12:01 AM, Benjamin Herrenschmidt wrote: We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all these processors. The result is that update_mmu_cache() would flush the cache for all pages mapped to userspace which is totally unnecessary on those processors since we already handle flushing on execute in the page fault path. This should provide a nice speed up ;-) Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/cputable.h | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) --- linux-work.orig/arch/powerpc/include/asm/cputable.h 2008-12-01 16:55:53.0 +1100 +++ linux-work/arch/powerpc/include/asm/cputable.h 2008-12-01 16:56:32.0 +1100 @@ -366,19 +366,20 @@ extern const char *powerpc_base_platform #define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | \ CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE) #define CPU_FTRS_8XX(CPU_FTR_USE_TB) -#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN) -#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN) +#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) +#define CPU_FTRS_44X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E200 (CPU_FTR_USE_TB | CPU_FTR_SPE_COMP | \ CPU_FTR_NODSISRALIGN | CPU_FTR_COHERENT_ICACHE | \ - CPU_FTR_UNIFIED_ID_CACHE) + CPU_FTR_UNIFIED_ID_CACHE | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ - CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN) + CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN \ Added a '|' at the end of the line before the escape + CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500_2 (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ CPU_FTR_SPE_COMP | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_BIG_PHYS | \ - CPU_FTR_NODSISRALIGN) + CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE) #define CPU_FTRS_E500MC (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \ CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_BIG_PHYS | CPU_FTR_NODSISRALIGN | \ - CPU_FTR_L2CSR | CPU_FTR_LWSYNC) + CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE) #define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add_460SX_Initial_Framework
On Mon, Dec 01, 2008 at 03:37:15PM -0800, [EMAIL PROTECTED] wrote:
>From: Madhulika Madishetty <[EMAIL PROTECTED]>
>
>This patch contains the initial framework for AMCC Redwood board.
>
>Signed-off-by: Madhulika Madishetty <[EMAIL PROTECTED]>, Tirumala Reddy
>Marri <[EMAIL PROTECTED]>,
>Feng Kan <[EMAIL PROTECTED]>, Vidhyananth Venkatasamy <[EMAIL PROTECTED]>,
>Preetesh Parekh <[EMAIL PROTECTED]>
>Acked-by: Loc Ho <[EMAIL PROTECTED]>, Feng Kan <[EMAIL PROTECTED]>
One Signed-off-by: per person, per line please. Don't use a single
with multiple names.
>---
> arch/powerpc/boot/dts/redwood_amcc.dts | 247 +++
> arch/powerpc/configs/44x/redwood_defconfig | 1082
>
Parts of your patch are word-wrapped.
>diff --git a/arch/powerpc/boot/dts/redwood_amcc.dts
>b/arch/powerpc/boot/dts/redwood_amcc.dts
>new file mode 100644
>index 000..e4f5efd
>--- /dev/null
>+++ b/arch/powerpc/boot/dts/redwood_amcc.dts
Any particular reason you chose to call this redwood_amcc.dts? None
of the other boards do that.
Also, what possessed AMCC to create an entirely new board called
Redwood when there is already a 4xx board called Redwood? I realize
this isn't really something you can control, and the old board isn't
supported any longer, but still... yell at your marketing people or
something :).
>@@ -0,0 +1,247 @@
>+/*
>+ * Device Tree Source for AMCC Redwood(460SX)
>+ *
>+ * Copyright 2008 AMCC <[EMAIL PROTECTED]>
>+ *
>+ * This file is licensed under the terms of the GNU General Public
>+ * License version 2. This program is licensed "as is" without
>+ * any warranty of any kind, whether express or implied.
>+ */
>+
>+/dts-v1/;
If this is really a dts-v1, I would expect all the values here to
look differently. See below.
>+
>+/ {
>+ #address-cells = <2>;
>+ #size-cells = <1>;
>+ model = "amcc,redwood";
>+ compatible = "amcc,redwood";
>+ dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
>+
>+ aliases {
>+ ethernet0 = &EMAC0;
>+ serial0 = &UART0;
>+ };
>+
>+ cpus {
>+ #address-cells = <1>;
>+ #size-cells = <0>;
>+
>+ [EMAIL PROTECTED] {
>+ device_type = "cpu";
>+ model = "PowerPC,460SX";
>+ reg = <0>;
>+ clock-frequency = <0>; /* Filled in by U-Boot */
>+ timebase-frequency = <0>; /* Filled in by U-Boot */
>+ i-cache-line-size = <20>;
>+ d-cache-line-size = <20>;
Here. You have a i/d-cache line size of 20 bytes? That's odd...
>+ i-cache-size = <8000>;
>+ d-cache-size = <8000>;
And you have a cache size of 8000 bytes? Also odd. I would expect these
lines to look like:
i-cache-line-size = <0x20>;
i-cache-size = <0x8000>;
or
i-cache-line-size = <32>;
i-cache-size = <32768>;
Please go through and verify all the values are properly filled out. I'm
not even sure how this works with newer dtc versions.
>+ dcr-controller;
>+ dcr-access-method = "native";
>+ };
>+ };
>+
>+ memory {
>+ device_type = "memory";
>+ reg = <0 0 0>; /* Filled in by U-Boot */
>+ };
>+
>+ UIC0: interrupt-controller0 {
>+ compatible = "ibm,uic-460sx","ibm,uic";
>+ interrupt-controller;
>+ cell-index = <0>;
>+ dcr-reg = <0c0 009>;
>+ #address-cells = <0>;
>+ #size-cells = <0>;
>+ #interrupt-cells = <2>;
>+ };
>+
>+ UIC1: interrupt-controller1 {
>+ compatible = "ibm,uic-460sx","ibm,uic";
>+ interrupt-controller;
>+ cell-index = <1>;
>+ dcr-reg = <0d0 009>;
>+ #address-cells = <0>;
>+ #size-cells = <0>;
>+ #interrupt-cells = <2>;
>+ interrupts = <1e 4 1f 4>; /* cascade */
>+ interrupt-parent = <&UIC0>;
>+ };
>+
>+ UIC2: interrupt-controller2 {
>+ compatible = "ibm,uic-460sx","ibm,uic";
>+ interrupt-controller;
>+ cell-index = <2>;
>+ dcr-reg = <0e0 009>;
>+ #address-cells = <0>;
>+ #size-cells = <0>;
>+ #interrupt-cells = <2>;
>+ interrupts = ; /* cascade */
>+ interrupt-parent = <&UIC0>;
>+ };
>+
>+ UIC3: interrupt-controller3 {
>+ compatible = "ibm,uic-460sx","ibm,uic";
>+ interrupt-controller;
>+ cell-index = <3>;
>+ dcr-reg = <0f0 009>;
>+ #address-cells = <0>;
>+ #size-cells = <0>;
>+ #interrupt-cells = <2>;
>+ interrupts = <10 4 11 4>; /* cascade */
>+ interrupt-par
Re: [Cbe-oss-dev] [Patch 1/3] User OProfile support for the IBM CELL processor SPU event profiling
On Mon, 2008-12-01 at 16:18 -0800, Carl Love wrote: > This patch adds the SPU event profiling support for the IBM Cell > processor to the list of available events. The opcontrol script > patches include a test to see if there is a new cell specific file > in the kernel oprofile file system. If the file exists, then the > kernel supports SPU event profiling. > > Signed-off-by: Carl Love <[EMAIL PROTECTED]> > > Index: oprofile-cvs/doc/oprofile.xml > === > --- oprofile-cvs.orig/doc/oprofile.xml > +++ oprofile-cvs/doc/oprofile.xml > @@ -123,6 +123,10 @@ For information on how to use OProfile's > of 2.6.22 or more recent. Additionally, full support > of SPE profiling requires a BFD library > from binutils code dated January 2007 or later. To > ensure the proper BFD support exists, run > the configure utility with > --with-target=cell-be. > + > +Profiling the Cell Broadband Engine using SPU events > requires a kernel version of 2.6.TBD or ^^^ Not sure if you missed that, or it's still TBD, but careful it doesn't get merged like that. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Erratic MPC8248 CPM2 I2C behaviour
(replying to myself again) I wrote: > But the key difference is that we see a persistent failure, while the > erratum only mentions a problem with "the next transaction". I think the timeout recovery code is not adequate for these CPM errors, and that is why a transient error becomes a persistent one. The function cpm_i2c_force_close in i2c-cpm.c sends a CPM_CR_CLOSE_RX_BD command, which will abort any receive transaction in progress, but if it's the transmit phase that got the CPM hung up, there is no code to abort that (and there does not exist a CP command to do so, as far as I can tell). So the I2C disable/enable seems to be an appropriate fix for the persistent failure part of the problem. Again, this doesn't explain how it gets hung up the first time. -=] Mike [=- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Patch 3/3] Kernel patch, IBM CELL processor add OProfile SPU event profiling support
This patch adds the SPU event based profiling funcitonality for the
IBM Cell processor. Previously, the CELL OProfile kernel code supported
PPU event, PPU cycle profiling and SPU cycle profiling. The addition of
SPU event profiling allows the users to identify where in their SPU code
various SPU evnets are occuring. This should help users further identify
issues with their code. Note, SPU profiling has some limitations due to HW
constraints. Only one event at a time can be used for profiling and SPU event
profiling must be time sliced across all of the SPUs in a node.
The patch adds a new arch specific file to the OProfile file system. The
file has bit 0 set to indicate that the kernel supports SPU event profiling.
The user tool must check this file/bit to make sure the kernel supports
SPU event profiling before trying to do SPU event profiling. The user tool
check is part of the user tool patch for SPU event profiling.
Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Index: Cell_kernel_11_10_2008-new-patches/arch/powerpc/oprofile/op_model_cell.c
===
---
Cell_kernel_11_10_2008-new-patches.orig/arch/powerpc/oprofile/op_model_cell.c
+++ Cell_kernel_11_10_2008-new-patches/arch/powerpc/oprofile/op_model_cell.c
@@ -44,6 +44,12 @@
#define SPU_PROFILING_CYCLES 1
#define SPU_PROFILING_EVENTS 2
+#define SPU_EVENT_NUM_START 4100
+#define SPU_EVENT_NUM_STOP 4399
+#define SPU_PROFILE_EVENT_ADDR 4363 /* spu, address trace, decimal */
+#define SPU_PROFILE_EVENT_ADDR_MASK_A 0x146 /* sub unit set to zero */
+#define SPU_PROFILE_EVENT_ADDR_MASK_B 0x186 /* sub unit set to zero */
+
#define NUM_SPUS_PER_NODE8
#define SPU_CYCLES_EVENT_NUM 2 /* event number for SPU_CYCLES */
@@ -61,6 +67,12 @@
#define MAX_SPU_COUNT 0xFF /* maximum 24 bit LFSR value */
+/* Minumum HW interval timer setting to send value to trace buffer is 10 cycle.
+ * To configure counter to send value every N cycles set counter to
+ * 2^32 - 1 - N.
+ */
+#define NUM_INTERVAL_CYC 0x - 10
+
/*
* spu_cycle_reset is the number of cycles between samples.
* This variable is used for SPU profiling and should ONLY be set
@@ -68,6 +80,7 @@
*/
static unsigned int spu_cycle_reset;
static unsigned int profiling_mode;
+static int spu_evnt_phys_spu_indx;
struct pmc_cntrl_data {
unsigned long vcntr;
@@ -108,6 +121,8 @@ struct pm_cntrl {
u16 trace_mode;
u16 freeze;
u16 count_mode;
+ u16 spu_addr_trace;
+ u8 trace_buf_ovflw;
};
static struct {
@@ -125,6 +140,7 @@ static struct {
#define GET_INPUT_CONTROL(x) ((x & 0x0004) >> 2)
static DEFINE_PER_CPU(unsigned long[NR_PHYS_CTRS], pmc_values);
+static unsigned long spu_pm_cnt[MAX_NUMNODES * NUM_SPUS_PER_NODE];
static struct pmc_cntrl_data pmc_cntrl[NUM_THREADS][NR_PHYS_CTRS];
/*
@@ -154,6 +170,7 @@ static u32 hdw_thread;
static u32 virt_cntr_inter_mask;
static struct timer_list timer_virt_cntr;
+static struct timer_list timer_spu_event_swap;
/*
* pm_signal needs to be global since it is initialized in
@@ -372,9 +389,13 @@ static void write_pm_cntrl(int cpu)
if (pm_regs.pm_cntrl.trace_mode != 0)
val |= CBE_PM_TRACE_MODE_SET(pm_regs.pm_cntrl.trace_mode);
+ if (pm_regs.pm_cntrl.trace_buf_ovflw == 1)
+ val |= CBE_PM_TRACE_BUF_OVFLW(pm_regs.pm_cntrl.trace_buf_ovflw);
if (pm_regs.pm_cntrl.freeze == 1)
val |= CBE_PM_FREEZE_ALL_CTRS;
+ val |= CBE_PM_SPU_ADDR_TRACE_SET(pm_regs.pm_cntrl.spu_addr_trace);
+
/*
* Routine set_count_mode must be called previously to set
* the count mode based on the user selection of user and kernel.
@@ -563,9 +584,184 @@ static int cell_reg_setup_spu_cycles(str
return 0;
}
+/* Unfortunately, the hardware will only support event profiling
+ * on one SPU per node at a time. Therefore, we must time slice
+ * the profiling across all SPUs in the node. Note, we do this
+ * in parallel for each node. The following routine is called
+ * periodically based on kernel timer to switch which SPU is
+ * being monitored in a round robbin fashion.
+ */
+static void spu_evnt_swap(unsigned long data)
+{
+ int node;
+ int cur_phys_spu, nxt_phys_spu, cur_spu_evnt_phys_spu_indx;
+ unsigned long flags;
+ int cpu;
+ int ret;
+ u32 interrupt_mask;
+
+
+ /* enable interrupts on cntr 0 */
+ interrupt_mask = CBE_PM_CTR_OVERFLOW_INTR(0);
+
+ hdw_thread = 0;
+
+ /* Make sure spu event interrupt handler and spu event swap
+* don't access the counters simultaneously.
+*/
+ spin_lock_irqsave(&cntr_lock, flags);
+
+ cur_spu_evnt_phys_spu_indx = spu_evnt_phys_spu_indx;
+
+ if (++(spu_evnt_phys_spu_indx) == NUM_SPUS_PER_NODE)
+ spu_evnt_phys_spu_indx = 0;
+
+ pm_signal[0].sub_unit = spu_evnt_phys_sp
[Patch 2/3] Kernel patch, IBM CELL processor OProfile cleanup and restructuring
This patch restructures and cleans up the code a bit to make it
easier to add new functionality later. The patch makes no
functional changes to the existing code.
Signed-off-by: Carl Love <[EMAIL PROTECTED]>
Index: Cell_kernel_11_10_2008/arch/powerpc/oprofile/op_model_cell.c
===
--- Cell_kernel_11_10_2008.orig/arch/powerpc/oprofile/op_model_cell.c
+++ Cell_kernel_11_10_2008/arch/powerpc/oprofile/op_model_cell.c
@@ -40,14 +40,9 @@
#include "../platforms/cell/interrupt.h"
#include "cell/pr_util.h"
-static void cell_global_stop_spu(void);
-
-/*
- * spu_cycle_reset is the number of cycles between samples.
- * This variable is used for SPU profiling and should ONLY be set
- * at the beginning of cell_reg_setup; otherwise, it's read-only.
- */
-static unsigned int spu_cycle_reset;
+#define PPU_PROFILING0
+#define SPU_PROFILING_CYCLES 1
+#define SPU_PROFILING_EVENTS 2
#define NUM_SPUS_PER_NODE8
#define SPU_CYCLES_EVENT_NUM 2 /* event number for SPU_CYCLES */
@@ -66,6 +61,14 @@ static unsigned int spu_cycle_reset;
#define MAX_SPU_COUNT 0xFF /* maximum 24 bit LFSR value */
+/*
+ * spu_cycle_reset is the number of cycles between samples.
+ * This variable is used for SPU profiling and should ONLY be set
+ * at the beginning of cell_reg_setup; otherwise, it's read-only.
+ */
+static unsigned int spu_cycle_reset;
+static unsigned int profiling_mode;
+
struct pmc_cntrl_data {
unsigned long vcntr;
unsigned long evnts;
@@ -122,7 +125,6 @@ static struct {
#define GET_INPUT_CONTROL(x) ((x & 0x0004) >> 2)
static DEFINE_PER_CPU(unsigned long[NR_PHYS_CTRS], pmc_values);
-
static struct pmc_cntrl_data pmc_cntrl[NUM_THREADS][NR_PHYS_CTRS];
/*
@@ -165,7 +167,7 @@ static int spu_rtas_token; /* token fo
static u32 reset_value[NR_PHYS_CTRS];
static int num_counters;
static int oprofile_running;
-static DEFINE_SPINLOCK(virt_cntr_lock);
+static DEFINE_SPINLOCK(cntr_lock);
static u32 ctr_enabled;
@@ -367,7 +369,7 @@ static void write_pm_cntrl(int cpu)
if (pm_regs.pm_cntrl.stop_at_max == 1)
val |= CBE_PM_STOP_AT_MAX;
- if (pm_regs.pm_cntrl.trace_mode == 1)
+ if (pm_regs.pm_cntrl.trace_mode != 0)
val |= CBE_PM_TRACE_MODE_SET(pm_regs.pm_cntrl.trace_mode);
if (pm_regs.pm_cntrl.freeze == 1)
@@ -441,7 +443,7 @@ static void cell_virtual_cntr(unsigned l
* not both playing with the counters on the same node.
*/
- spin_lock_irqsave(&virt_cntr_lock, flags);
+ spin_lock_irqsave(&cntr_lock, flags);
prev_hdw_thread = hdw_thread;
@@ -527,7 +529,7 @@ static void cell_virtual_cntr(unsigned l
cbe_enable_pm(cpu);
}
- spin_unlock_irqrestore(&virt_cntr_lock, flags);
+ spin_unlock_irqrestore(&cntr_lock, flags);
mod_timer(&timer_virt_cntr, jiffies + HZ / 10);
}
@@ -541,44 +543,30 @@ static void start_virt_cntrs(void)
add_timer(&timer_virt_cntr);
}
-/* This function is called once for all cpus combined */
-static int cell_reg_setup(struct op_counter_config *ctr,
+static int cell_reg_setup_spu_cycles(struct op_counter_config *ctr,
struct op_system_config *sys, int num_ctrs)
{
- int i, j, cpu;
- spu_cycle_reset = 0;
-
- if (ctr[0].event == SPU_CYCLES_EVENT_NUM) {
- spu_cycle_reset = ctr[0].count;
-
- /*
-* Each node will need to make the rtas call to start
-* and stop SPU profiling. Get the token once and store it.
-*/
- spu_rtas_token = rtas_token("ibm,cbe-spu-perftools");
-
- if (unlikely(spu_rtas_token == RTAS_UNKNOWN_SERVICE)) {
- printk(KERN_ERR
- "%s: rtas token ibm,cbe-spu-perftools unknown\n",
- __func__);
- return -EIO;
- }
- }
-
- pm_rtas_token = rtas_token("ibm,cbe-perftools");
+ spu_cycle_reset = ctr[0].count;
/*
-* For all events excetp PPU CYCLEs, each node will need to make
-* the rtas cbe-perftools call to setup and reset the debug bus.
-* Make the token lookup call once and store it in the global
-* variable pm_rtas_token.
+* Each node will need to make the rtas call to start
+* and stop SPU profiling. Get the token once and store it.
*/
- if (unlikely(pm_rtas_token == RTAS_UNKNOWN_SERVICE)) {
+ spu_rtas_token = rtas_token("ibm,cbe-spu-perftools");
+
+ if (unlikely(spu_rtas_token == RTAS_UNKNOWN_SERVICE)) {
printk(KERN_ERR
- "%s: rtas token ibm,cbe-perftools unknown\n",
+ "%s: rtas token ibm,cbe-spu-perftools unknown\n",
__func__);
return -EIO;
}
+ return 0;
+
[Patch 1/3] User OProfile support for the IBM CELL processor SPU event profiling
This patch adds the SPU event profiling support for the IBM Cell processor to the list of available events. The opcontrol script patches include a test to see if there is a new cell specific file in the kernel oprofile file system. If the file exists, then the kernel supports SPU event profiling. Signed-off-by: Carl Love <[EMAIL PROTECTED]> Index: oprofile-cvs/events/ppc64/cell-be/events === --- oprofile-cvs.orig/events/ppc64/cell-be/events +++ oprofile-cvs/events/ppc64/cell-be/events @@ -108,12 +108,42 @@ event:0xdbe counters:0,1,2,3 um:PPU_0_cy event:0xdbf counters:0,1,2,3 um:PPU_0_cycles minimum:1 name:stb_not_empty : At least one store gather buffer not empty. # Cell BE Island 4 - Synergistic Processor Unit (SPU) - +# +# OPROFILE FOR CELL ONLY SUPPORTS PROFILING ON ONE SPU EVENT AT A TIME +# # CBE Signal Group 41 - SPU (NClk) +event:0x1004 counters:0 um:SPU_02_cycles minimum:1 name:dual_instrctn_commit : Dual instruction committed. +event:0x1005 counters:0 um:SPU_02_cycles minimum:1 name:sngl_instrctn_commit : Single instruction committed. +event:0x1006 counters:0 um:SPU_02_cycles minimum:1 name:ppln0_instrctn_commit : Pipeline 0 instruction committed. +event:0x1007 counters:0 um:SPU_02_cycles minimum:1 name:ppln1_instrctn_commit : Pipeline 1 instruction committed. +event:0x1008 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:instrctn_ftch_stll : Instruction fetch stall. +event:0x1009 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:lcl_strg_bsy : Local storage busy. +event:0x100A counters:0 um:SPU_02_cycles minimum:1 name:dma_cnflct_ld_st : DMA may conflict with load or store. +event:0x100B counters:0 um:SPU_02_cycles minimum:1 name:str_to_lcl_strg: Store instruction to local storage issued. +event:0x100C counters:0 um:SPU_02_cycles minimum:1 name:ld_frm_lcl_strg: Load intruction from local storage issued. +event:0x100D counters:0 um:SPU_02_cycles minimum:1 name:fpu_exctn : Floating-Point Unit (FPU) exception. +event:0x100E counters:0 um:SPU_02_cycles minimum:1 name:brnch_instrctn_commit : Branch instruction committed. +event:0x100F counters:0 um:SPU_02_cycles minimum:1 name:change_of_flow : Non-sequential change of the SPU program counter, which can be caused by branch, asynchronous interrupt, stalled wait on channel, error correction code (ECC) error, and so forth. +event:0x1010 counters:0 um:SPU_02_cycles minimum:1 name:brnch_not_tkn : Branch not taken. +event:0x1011 counters:0 um:SPU_02_cycles minimum:1 name:brnch_mss_prdctn : Branch miss prediction; not exact. Certain other code sequences can cause additional pulses on this signal (see Note 2). +event:0x1012 counters:0 um:SPU_02_cycles minimum:1 name:brnch_hnt_mss_prdctn : Branch hint miss prediction; not exact. Certain other code sequences can cause additional pulses on this signal (see Note 2). +event:0x1013 counters:0 um:SPU_02_cycles minimum:1 name:instrctn_seqnc_err : Instruction sequence error. +event:0x1015 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl_wrt : Stalled waiting on any blocking channel write (see Note 3). +event:0x1016 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl0: Stalled waiting on External Event Status (Channel 0) (see Note 3). +event:0x1017 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl3: Stalled waiting on Signal Notification 1 (Channel 3) (see Note 3). +event:0x1018 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl4: Stalled waiting on Signal Notification 2 (Channel 4) (see Note 3). +event:0x1019 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl21 : Stalled waiting on DMA Command Opcode or ClassID Register (Channel 21) (see Note 3). +event:0x101A counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl24 : Stalled waiting on Tag Group Status (Channel 24) (see Note 3). +event:0x101B counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl25 : Stalled waiting on List Stall-and-Notify Tag Status (Channel 25) (see Note 3). +event:0x101C counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl28 : Stalled waiting on PPU Mailbox (Channel 28) (see Note 3). +event:0x1022 counters:0 um:SPU_02_cycles_or_edges minimum:1 name:stlld_wait_on_chnl29 : Stalled waiting on SPU Mailbox (Channel 29) (see
[Patch 0/3] Overview, OProfile SPU event profiling support for IBM Cell processor
This is a rework of the previously posted set of patches. Patch 1 is the user level patch to add the SPU events to the user OProfile tool. Patch 2 is a kernel patch to do code clean up and restructuring to make it easier to add the new SPU event profiling support. This patch makes no functional changes. Patch 3 is a kernel patch to add the SPU event profiling support. Carl Love ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, 2008-12-01 at 17:06 -0600, Hollis Blanchard wrote: > Ben, you had some comments on the previous version of this patch. Have > those been addressed to your satisfaction? If so, could you please > queue this for 2.6.29? > >From the description, they have, however I haven't had a chance to look in details at the code yet. I would like to see these in 2.6.29 too though, I'll have a look asap. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Add_460SX_Initial_Framework
From: Madhulika Madishetty <[EMAIL PROTECTED]>
This patch contains the initial framework for AMCC Redwood board.
Signed-off-by: Madhulika Madishetty <[EMAIL PROTECTED]>, Tirumala Reddy
Marri <[EMAIL PROTECTED]>,
Feng Kan <[EMAIL PROTECTED]>, Vidhyananth Venkatasamy <[EMAIL PROTECTED]>,
Preetesh Parekh <[EMAIL PROTECTED]>
Acked-by: Loc Ho <[EMAIL PROTECTED]>, Feng Kan <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/redwood_amcc.dts | 247 +++
arch/powerpc/configs/44x/redwood_defconfig | 1082
arch/powerpc/kernel/cpu_setup_44x.S|2 +
arch/powerpc/kernel/cputable.c | 13 +
arch/powerpc/platforms/44x/Kconfig | 22 +-
arch/powerpc/platforms/44x/Makefile|1 +
arch/powerpc/platforms/44x/ppc44x_simple.c |2 +
arch/powerpc/platforms/44x/redwood.c | 103 +++
8 files changed, 1470 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/boot/dts/redwood_amcc.dts
create mode 100644 arch/powerpc/configs/44x/redwood_defconfig
create mode 100644 arch/powerpc/platforms/44x/redwood.c
diff --git a/arch/powerpc/boot/dts/redwood_amcc.dts
b/arch/powerpc/boot/dts/redwood_amcc.dts
new file mode 100644
index 000..e4f5efd
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood_amcc.dts
@@ -0,0 +1,247 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,redwood";
+ compatible = "amcc,redwood";
+ dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "cpu";
+ model = "PowerPC,460SX";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = ; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460sx";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460sx";
+ dcr-reg = <00c 002>;
+ };
+ plb {
+ compatible = "ibm,plb-460sx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460sx", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+
Re: Erratic MPC8248 CPM2 I2C behaviour
I wrote: > Our production equipment is using Linux 2.6 with the out-of-tree > i2c-algo-8260.c by Dan Malek and Brad Parker. Oops, I meant to say Linux 2.4.20 (MontaVista). -=] Mike [=- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Erratic MPC8248 CPM2 I2C behaviour
Laurent Pinchart <[EMAIL PROTECTED]> wrote: > Transmission timeout after one second. The first TX buffer descriptor status > hasn't been modified by the CPM. The CPM state dump shows that processing of ... This sounds very similar to a problem I have seen on MPC8247 and MPC8248. It could be a variation of the CPM bug documented by Freescale as erratum CPM98. But the key difference is that we see a persistent failure, while the erratum only mentions a problem with "the next transaction". What we see is that once the I2C engine gets confused by some anomaly on the SCL signal, it stops processing buffer descriptors entirely until it is turned off and back on. You can observe this bug by momentarily grounding the SCL line (it's an open-collector bus) with a jumper while you attempt an I/O. Our production equipment is using Linux 2.6 with the out-of-tree i2c-algo-8260.c by Dan Malek and Brad Parker. I modified this driver to shut off the I2C controller and turn it back on when it hits this problem, and now it can recover from this condition. However, this does not explain how the controller gets into the frozen state in the first place. We see it very rarely in production units and have not been able to identify the cause. If it is similar to erratum CPM98 then it could be noise on the SCL signal or perhaps an I2C device that doesn't conform to the protocol perfectly. Also beware, if you are using some kind of multiplexer, that you don't direct the multiplexer to switch to a different bus (segment) while a transaction is in progress. In testing with the current (2.6.27) i2c-cpm.c driver, I found that it is sufficient to #define I2C_CHIP_ERRATA to allow it to recover from the CPM I2C freeze. However, I don't know if I like this approach because it turns off the I2C engine after every transfer, even successful ones, and I don't know if this will affect reliability or performance. And I don't know if this will actually prevent the freeze from happening, although I presume that it would protect the I2C engine from getting confused by a glitch that happens while no transfer is in progress. I am not aware of any documentation for what exactly the I2C_CHIP_ERRATA conditional code in i2c-cpm.c is meant to work around. The comment mentions "earlier than rev D4" but I'm not aware of any such rev for 8260 or 8272 chip families, and if it is related to erratum CPM98, Freescale seems to say that this erratum is in all revs of these chips and has no plan to fix it, so it seems that the workaround should be enabled by default. -=] Mike [=- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Mon, Dec 01, 2008 at 05:06:03PM -0600, Hollis Blanchard wrote: >On Thu, Nov 27, 2008 at 5:44 PM, Ilya Yanok <[EMAIL PROTECTED]> wrote: >> This patch adds support for page sizes bigger than 4K (16K/64K) on >> PPC 44x. >> PGDIR table is much smaller than page in case of 16K/64K pages (512 >> and 32 bytes resp.) so we allocate PGDIR with kzalloc() instead of >> __get_free_pages(). >> PTE table covers rather big memory area in case of 16K/64K pages >> (32MB and 512MB resp.) so we can easily put FIXMAP and PKMAP in >> area covered by one PTE table. > >Ben, you had some comments on the previous version of this patch. Have >those been addressed to your satisfaction? If so, could you please >queue this for 2.6.29? Milton had some comments too. And I'd also like to review it and add and Acked-by since I'll be the one getting bug reports if it's broken :). I've been sick for the past few days, but this is the first thing to review on my list tomorrow. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: The Linux code could use current-speed to know if it should program the registers. I.e., if current-speed is present and non-zero, then leave the frequency registers alone. Otherwise u-boot or whatever might not have programmed the I2C controller and the driver can do what it's doing now. I suppose. I was thinking that Linux could just check to see whether the current divider value appears to be valid, but it seems that all values including zero can be valid. :-( When does the guest really care what the specific i2c bus frequency is, if it's not going to change it? I don't know of a real reason. Maybe an I2C device where the clock speed makes a difference? Maximum polling rate or something? Is there reason the CPU clock and the CCB frequency need to be in the device tree? I'm fine with including it for informational purposes, it just doesn't seem quite as necessary. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Thu, Nov 27, 2008 at 5:44 PM, Ilya Yanok <[EMAIL PROTECTED]> wrote: > This patch adds support for page sizes bigger than 4K (16K/64K) on > PPC 44x. > PGDIR table is much smaller than page in case of 16K/64K pages (512 > and 32 bytes resp.) so we allocate PGDIR with kzalloc() instead of > __get_free_pages(). > PTE table covers rather big memory area in case of 16K/64K pages > (32MB and 512MB resp.) so we can easily put FIXMAP and PKMAP in > area covered by one PTE table. Ben, you had some comments on the previous version of this patch. Have those been addressed to your satisfaction? If so, could you please queue this for 2.6.29? -Hollis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [v4] ppc: force memory size to be a multiple of PAGE_SIZE
On Wed, Nov 26, 2008 at 10:19 AM, Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> Ensure that total memory size is page-aligned, because otherwise
> mark_bootmem() gets upset.
>
> This error case was triggered by using 64 KiB pages in the kernel while
> arch/powerpc/boot/4xx.c arbitrarily reduced the amount of memory by 4096 (to
> work around a chip bug that affects the last 256 bytes of physical memory).
>
> Signed-off-by: Hollis Blanchard <[EMAIL PROTECTED]>
> ---
> Changes from v3:
> - No need to call lmb_enforce_memory_limit() with limit=lmb_phys_mem_size().
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -1160,6 +1160,8 @@ static inline void __init phyp_dump_rese
>
> void __init early_init_devtree(void *params)
> {
> + unsigned long limit;
> +
>DBG(" -> early_init_devtree(%p)\n", params);
>
>/* Setup flat device-tree pointer */
> @@ -1200,7 +1202,19 @@ void __init early_init_devtree(void *par
>early_reserve_mem();
>phyp_dump_reserve_mem();
>
> - lmb_enforce_memory_limit(memory_limit);
> + limit = memory_limit;
> + if (! limit) {
> + unsigned long memsize;
> +
> + /* Ensure that total memory size is page-aligned, because
> +* otherwise mark_bootmem() gets upset. */
> + lmb_analyze();
> + memsize = lmb_phys_mem_size();
> + if ((memsize & PAGE_MASK) != memsize)
> + limit = memsize & PAGE_MASK;
> + }
> + lmb_enforce_memory_limit(limit);
> +
>lmb_analyze();
>
>DBG("Phys. mem: %lx\n", lmb_phys_mem_size());
Paul or Ben: since there have been no further comments on this, would
you queue it up for 2.6.29? Thanks.
-Hollis
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: > For a bus device like an i2c controller, you really have two clocks. The > input clock the controller runs from and the speed it runs the bus at. One > could say that one clock is for the device node and the other clock is for > the device's sub-nodes. We could add a property to each I2C device nodes that lists the maximum speed that this supports. Then the I2C driver could find the smallest of these speeds, and program the I2C controller for that speed. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
On Mon, 1 Dec 2008, Scott Wood wrote: > Trent Piepho wrote: >> U-boot could pass in "bus-frequency" to let software know the speed of the >> I2C bus from Linux. Seems like a standard property for bus nodes. > > clock-frequency is standard, though it should probably be the input frequency > rather than the bus frequency, in case the OS really does want to change it > (maybe making the bus run faster when accessing faster devices). For a bus device like an i2c controller, you really have two clocks. The input clock the controller runs from and the speed it runs the bus at. One could say that one clock is for the device node and the other clock is for the device's sub-nodes. Linux doesn't have an API for setting I2C bus speed. If it did, then adding support for it to i2c-mpc if there was demand would really be another patch. Right now the problem is that Linux programs the I2C controller stupidly and undoes u-boot's (better) settings. >> There could be a "current-speed" property that tells linux to keep the >> registers the same, > > That would be a bit different from the way it's used in serial nodes, where > current-speed is simply a description of the baud rate that corresponds to > the current divider setting. I'm not sure that it makes as much sense for > i2c, as you don't have the shared state on the other end that depends on > maintaining the exact same speed. The Linux code could use current-speed to know if it should program the registers. I.e., if current-speed is present and non-zero, then leave the frequency registers alone. Otherwise u-boot or whatever might not have programmed the I2C controller and the driver can do what it's doing now. > When does the guest really care what the specific i2c bus frequency is, if > it's not going to change it? I don't know of a real reason. Maybe an I2C device where the clock speed makes a difference? Maximum polling rate or something? Is there reason the CPU clock and the CCB frequency need to be in the device tree? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: U-boot could pass in "bus-frequency" to let software know the speed of the I2C bus from Linux. Seems like a standard property for bus nodes. clock-frequency is standard, though it should probably be the input frequency rather than the bus frequency, in case the OS really does want to change it (maybe making the bus run faster when accessing faster devices). There could be a "current-speed" property that tells linux to keep the registers the same, That would be a bit different from the way it's used in serial nodes, where current-speed is simply a description of the baud rate that corresponds to the current divider setting. I'm not sure that it makes as much sense for i2c, as you don't have the shared state on the other end that depends on maintaining the exact same speed. When does the guest really care what the specific i2c bus frequency is, if it's not going to change it? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/1] arch/powerpc: eliminate NULL test and memset after alloc_bootmem
From: Julia Lawall <[EMAIL PROTECTED]>
As noted by Akinobu Mita in patch b1fceac2b9e04d278316b2faddf276015fc06e3b,
alloc_bootmem and related functions never return NULL and always return a
zeroed region of memory. Thus a NULL test or memset after calls to these
functions is unnecessary.
This was fixed using the following semantic patch.
(http://www.emn.fr/x-info/coccinelle/)
//
@@
expression E;
statement S;
@@
E =
\(alloc_bootmem\|alloc_bootmem_low\|alloc_bootmem_pages\|alloc_bootmem_low_pages\|alloc_bootmem_node\|alloc_bootmem_low_pages_node\|alloc_bootmem_pages_node\)(...)
... when != E
(
- BUG_ON (E == NULL);
|
- if (E == NULL) S
)
@@
expression E,E1;
@@
E =
\(alloc_bootmem\|alloc_bootmem_low\|alloc_bootmem_pages\|alloc_bootmem_low_pages\|alloc_bootmem_node\|alloc_bootmem_low_pages_node\|alloc_bootmem_pages_node\)(...)
... when != E
- memset(E,0,E1);
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/setup_64.c |2 --
1 file changed, 2 deletions(-)
diff -puN
arch/powerpc/kernel/setup_64.c~arch-powerpc-eliminate-null-test-and-memset-after-alloc_bootmem
arch/powerpc/kernel/setup_64.c
---
a/arch/powerpc/kernel/setup_64.c~arch-powerpc-eliminate-null-test-and-memset-after-alloc_bootmem
+++ a/arch/powerpc/kernel/setup_64.c
@@ -606,8 +606,6 @@ void __init setup_per_cpu_areas(void)
for_each_possible_cpu(i) {
ptr = alloc_bootmem_pages_node(NODE_DATA(cpu_to_node(i)), size);
- if (!ptr)
- panic("Cannot allocate cpu data for CPU %d\n", i);
paca[i].data_offset = ptr - __per_cpu_start;
memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
On Mon, 1 Dec 2008, Andr? Schwarz wrote: > Timur Tabi wrote: >> Trent Piepho wrote: >> >> >> > Seems like it should keep the clock registers at what u-boot set them >> > too. >> > >> >> Or we could have U-Boot put the i2c clock frequency into the I2C node, and >> let >> the driver program the hardware again. That would keep the ugliness in >> U-Boot. >> >> > Wouldn't it be easier to omit frequency re-programming at all ? > Maybe configurable for non U-Boot users ... That's what I'm thinking too. Calculating the settings for a given bus frequency, even with the system specific source clock provided by u-boot, involves either a complex algorithm or a big ugly black box table that's even larger than the algorithm. I also think it's different for 8xxx and 52xx. On the other hand just keeping the clock the same doesn't require any code at all. U-boot could pass in "bus-frequency" to let software know the speed of the I2C bus from Linux. Seems like a standard property for bus nodes. There could be a "current-speed" property that tells linux to keep the registers the same, in case we have to worry about u-boot not programming the i2c clock. I think the serial drivers have something like this.___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: __cpu_up vs. start_secondary race?
On Mon, 2008-12-01 at 15:30 -0600, Nathan Lynch wrote: > Hi, > > I think there may be a plausible issue here. If not, maybe I'll get > an education :) > > cpu_callin_map is used during secondary CPU bootstrap to notify the > waiting CPU that the new CPU is coming up. __cpu_up clears > cpu_callin_map[cpu] and then polls the same location, waiting for > start_secondary to set it to 1. But I'm wondering how safe the > current implementation is -- start_secondary doesn't have an explicit > sync following cpu_callin_map[cpu] = 1, and __cpu_up has no > synchronization instructions in its polling loop, so how can we be > sure that the waiting cpu will see the update to that location in > time? I think it works because there's no big ordering problem (though we should still probably stick a few barriers here for safety) so it's really just a problem of how long it takes for the store to be visible, and the duration of the waiting loop is such that in practice, it will end up being visible way before we timeout. IE. It's not like stores get buffered for ever due to absence of barriers. They ultimately get out to the bus. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
__cpu_up vs. start_secondary race?
Hi,
I think there may be a plausible issue here. If not, maybe I'll get
an education :)
cpu_callin_map is used during secondary CPU bootstrap to notify the
waiting CPU that the new CPU is coming up. __cpu_up clears
cpu_callin_map[cpu] and then polls the same location, waiting for
start_secondary to set it to 1. But I'm wondering how safe the
current implementation is -- start_secondary doesn't have an explicit
sync following cpu_callin_map[cpu] = 1, and __cpu_up has no
synchronization instructions in its polling loop, so how can we be
sure that the waiting cpu will see the update to that location in
time?
Compare with the prom_hold_cpus/__secondary_hold_acknowledge code,
which is doing a very similar task, but it has the mb and sync (in
head_64.S at least) that seem to be missing from the case above.
Since we're not buried in "Processor X is stuck" bug reports, I must
be missing something, or there's some incidental factor that makes it
okay in practice...
Relevant code from arch/powerpc/kernel/smp.c:
static volatile unsigned int cpu_callin_map[NR_CPUS];
int __cpuinit __cpu_up(unsigned int cpu)
{
int c;
secondary_ti = current_set[cpu];
if (!cpu_enable(cpu))
return 0;
if (smp_ops == NULL ||
(smp_ops->cpu_bootable && !smp_ops->cpu_bootable(cpu)))
return -EINVAL;
/* Make sure callin-map entry is 0 (can be leftover a CPU
* hotplug
*/
cpu_callin_map[cpu] = 0;
/* The information for processor bringup must
* be written out to main store before we release
* the processor.
*/
smp_mb();
/* wake up cpus */
DBG("smp: kicking cpu %d\n", cpu);
smp_ops->kick_cpu(cpu);
/*
* wait to see if the cpu made a callin (is actually up).
* use this value that I found through experimentation.
* -- Cort
*/
if (system_state < SYSTEM_RUNNING)
for (c = 5; c && !cpu_callin_map[cpu]; c--)
udelay(100);
#ifdef CONFIG_HOTPLUG_CPU
else
/*
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
for (c = 25; c && !cpu_callin_map[cpu]; c--) {
msleep(200);
}
#endif
if (!cpu_callin_map[cpu]) {
printk("Processor %u is stuck.\n", cpu);
return -ENOENT;
}
printk("Processor %u found.\n", cpu);
if (smp_ops->give_timebase)
smp_ops->give_timebase();
/* Wait until cpu puts itself in the online map */
while (!cpu_online(cpu))
cpu_relax();
return 0;
}
int __devinit start_secondary(void *unused)
{
unsigned int cpu = smp_processor_id();
struct device_node *l2_cache;
int i, base;
atomic_inc(&init_mm.mm_count);
current->active_mm = &init_mm;
smp_store_cpu_info(cpu);
set_dec(tb_ticks_per_jiffy);
preempt_disable();
cpu_callin_map[cpu] = 1;
smp_ops->setup_cpu(cpu);
if (smp_ops->take_timebase)
smp_ops->take_timebase();
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: minor head_fsl_booke.S cleanup
Removed unused branch labels Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/kernel/head_fsl_booke.S |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 8942d7a..2b57605 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -751,7 +751,7 @@ finish_tlb_load: iseleq r12, r12, r10 #ifdef CONFIG_PTE_64BIT -2: rlwimi r12, r13, 24, 0, 7 /* grab RPN[32:39] */ + rlwimi r12, r13, 24, 0, 7 /* grab RPN[32:39] */ rlwimi r12, r11, 24, 8, 19 /* grab RPN[40:51] */ mtspr SPRN_MAS3, r12 BEGIN_FTR_SECTION @@ -759,7 +759,7 @@ BEGIN_FTR_SECTION mtspr SPRN_MAS7, r10 END_FTR_SECTION_IFSET(CPU_FTR_BIG_PHYS) #else -2: rlwimi r11, r12, 0, 20, 31 /* Extract RPN from PTE and merge with perms */ + rlwimi r11, r12, 0, 20, 31 /* Extract RPN from PTE and merge with perms */ mtspr SPRN_MAS3, r11 #endif #ifdef CONFIG_E200 -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
André Schwarz wrote: > Wouldn't it be easier to omit frequency re-programming at all ? > Maybe configurable for non U-Boot users ... Well, the real problem is that Linux is ignoring what the boot loader has done. This is bad, regardless as to which boot loader you're using. The question is, do we give Linux the capability to program the I2C bus speed, or is this something that the boot loader should do? Unfortunately, the current Linux code means that this issue is not properly architected. You mentioned people who don't use U-Boot. Do they use some other boot loader? Or no boot loader at all? Do other boot loaders program the I2C bus speed? The reason I ask is that I want to know whether it's okay for Linux to ignore the FDR and DFSRR registers. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [U-Boot] ppc4xx: u-boot sees PCIe endpoint, linux does not.
On Monday 01 December 2008, Leon Woestenberg wrote: > >> Now, if I re-program the end-point FPGA during the u-boot boot > >> time-out, Linux will recognize the end-point. > > > > It's possible that either the reset in between goes bonkers or something > > else causes your FPGA to stop responding. It looks like a programming > > problem with the FPGA to me. > > I have verified that the end point does not receive any kind of reset. > > Also, this problem only happens on the Canyonlands board; on x86 and > powerpc MPC8315E it remains properly working after soft/hard resets, > u-boot init etc. This could be because only the 4xx Linux PCI(e) driver really resets the endpoint (PHY reset). But you seem to have analyzed this already. > Could it be u-boot overwrites a too large payload into the config > space or something similar, which makes subsequent accesses fail? Not sure. I suggest that you disable the PCI(e) support in U-Boot to see if Linux behaves differently on a non-pre-initialized endpoint. 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: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Timur Tabi wrote: Trent Piepho wrote: Seems like it should keep the clock registers at what u-boot set them too. Or we could have U-Boot put the i2c clock frequency into the I2C node, and let the driver program the hardware again. That would keep the ugliness in U-Boot. Wouldn't it be easier to omit frequency re-programming at all ? Maybe configurable for non U-Boot users ... MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc4xx: u-boot sees PCIe endpoint, linux does not.
Hello all, On Mon, Dec 1, 2008 at 9:12 AM, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Fri, 2008-11-28 at 13:50 +0100, Leon Woestenberg wrote: >> >> AMCC PPC460EX canyonlands board with an FPGA PCIe end point: >> >> u-boot sees the end point, but Linux does not: >> >> U-Boot 1.3.3-00249-ga524e11 (Jun 30 2008 - 16:05:51) >> CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) >> <...> >> Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 >> <...> >> PCIE1: successfully set as root-complex >> 02 00 2071 2071 00ff 00 >> >> Now, if I re-program the end-point FPGA during the u-boot boot >> time-out, Linux will recognize the end-point. >> > It's possible that either the reset in between goes bonkers or something > else causes your FPGA to stop responding. It looks like a programming > problem with the FPGA to me. > I have verified that the end point does not receive any kind of reset. Also, this problem only happens on the Canyonlands board; on x86 and powerpc MPC8315E it remains properly working after soft/hard resets, u-boot init etc. Could it be u-boot overwrites a too large payload into the config space or something similar, which makes subsequent accesses fail? Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] powerpc: ftrace updates to previous patch series
On Fri, 28 Nov 2008, Ingo Molnar wrote: > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > On Wed, 26 Nov 2008, Steven Rostedt wrote: > > > > > Paul, > > > > > > This patch series addresses the issues you brought up as well as > > > adds some more enhancements and fixes. This series is added on > > > top of the previous patch series. > > > > > > The new patches are: (and are posted now) > > > 5987225... powerpc/ppc32: static ftrace fixes for PPC32 > > > > The new commit id with the fix in Author and SoB is: > > fd90db4bdc1ccf71927365cd634188cec4d7b151 > > powerpc/ppc32: static ftrace fixes for > > Steve, you rebased the previous commits, and that's a no-no. I sorted it > all out, find below the stable URI for stuff that we'd like Paul to pull > shortly before the merge window. Sorry, I rebased to edit the change log where I mispelled Paul's name. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DMA from memory to local bus
On Fri, Nov 28, 2008 at 03:04:04PM +0100, Hommel, Thomas (GE EntSol, Intelligent Platforms) wrote: > > Hi all, > I'm currently developing a driver and want to make use of the DMA > offload engine. Data has to be transferred from memory to a device on > the local bus and vice versa. > At a first look, the function dma_async_memcpy_buf_to_buf() seemed to be > suitable, but it does not translate addresses correctly. Both addresses > are treated as if they were in memory. > In my configuration, the buffer is located in memory, but the device's > I/O space is mapped into vmalloc space via ioremap(). How can I access > the I/O space corectly from the DMA controller? I also checked the > return of virt_to_phys() and this does not deliver the correct physical > address. > The board is based on MPC8641D and I'm using the on-chip DMA engine. > Check out my PCINet driver, posted here previously. It does something similar. It uses the PowerPC DMA controller to transfer all of the data around. You probably need to use dma_map_single() to get the physical address of your memory to give it to the DMA controller. Ira ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] of/gpio: Implement of_get_gpio_flags()
This function is alike to the simple of_get_gpio(), but accepts new
argument: flags. This new function will be used by the drivers that
need to retrieve additional GPIO information, such as active-low flag.
Also, the patch changes default ("simple") .xlate routine to warn about
bogus (< 2) #gpio-cells usage: the second cell should always be present
for GPIO flags.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
v1 -> v2:
- Commit message mentions .xlate behaviour change;
- enum of_gpio_flags also defined for !CONFIG_OF_GPIO case.
drivers/of/gpio.c | 36 +---
include/linux/of_gpio.h | 38 ++
2 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 7cd7301..a4ba217 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -19,14 +19,17 @@
#include
/**
- * of_get_gpio - Get a GPIO number from the device tree to use with GPIO API
+ * of_get_gpio_flags - Get a GPIO number and flags to use with GPIO API
* @np:device node to get GPIO from
* @index: index of the GPIO
+ * @flags: a flags pointer to fill in
*
* Returns GPIO number to use with Linux generic GPIO API, or one of the errno
- * value on the error condition.
+ * value on the error condition. If @flags is not NULL the function also fills
+ * in flags for the GPIO.
*/
-int of_get_gpio(struct device_node *np, int index)
+int of_get_gpio_flags(struct device_node *np, int index,
+ enum of_gpio_flags *flags)
{
int ret;
struct device_node *gc;
@@ -59,7 +62,11 @@ int of_get_gpio(struct device_node *np, int index)
goto err1;
}
- ret = of_gc->xlate(of_gc, np, gpio_spec);
+ /* .xlate might decide to not fill in the flags, so clear it. */
+ if (flags)
+ *flags = 0;
+
+ ret = of_gc->xlate(of_gc, np, gpio_spec, flags);
if (ret < 0)
goto err1;
@@ -70,26 +77,41 @@ err0:
pr_debug("%s exited with status %d\n", __func__, ret);
return ret;
}
-EXPORT_SYMBOL(of_get_gpio);
+EXPORT_SYMBOL(of_get_gpio_flags);
/**
- * of_gpio_simple_xlate - translate gpio_spec to the GPIO number
+ * of_gpio_simple_xlate - translate gpio_spec to the GPIO number and flags
* @of_gc: pointer to the of_gpio_chip structure
* @np:device node of the GPIO chip
* @gpio_spec: gpio specifier as found in the device tree
+ * @flags: a flags pointer to fill in
*
* This is simple translation function, suitable for the most 1:1 mapped
* gpio chips. This function performs only one sanity check: whether gpio
* is less than ngpios (that is specified in the gpio_chip).
*/
int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
-const void *gpio_spec)
+const void *gpio_spec, enum of_gpio_flags *flags)
{
const u32 *gpio = gpio_spec;
+ /*
+* We're discouraging gpio_cells < 2, since that way you'll have to
+* write your own xlate function (that will have to retrive the GPIO
+* number and the flags from a single gpio cell -- this is possible,
+* but not recommended).
+*/
+ if (of_gc->gpio_cells < 2) {
+ WARN_ON(1);
+ return -EINVAL;
+ }
+
if (*gpio > of_gc->gc.ngpio)
return -EINVAL;
+ if (flags)
+ *flags = gpio[1];
+
return *gpio;
}
EXPORT_SYMBOL(of_gpio_simple_xlate);
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 67db101..e25abf6 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -14,9 +14,22 @@
#ifndef __LINUX_OF_GPIO_H
#define __LINUX_OF_GPIO_H
+#include
+#include
#include
#include
+struct device_node;
+
+/*
+ * This is Linux-specific flags. By default controllers' and Linux' mapping
+ * match, but GPIO controllers are free to translate their own flags to
+ * Linux-specific in their .xlate callback. Though, 1:1 mapping is recommended.
+ */
+enum of_gpio_flags {
+ OF_GPIO_ACTIVE_LOW = 0x1,
+};
+
#ifdef CONFIG_OF_GPIO
/*
@@ -26,7 +39,7 @@ struct of_gpio_chip {
struct gpio_chip gc;
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
-const void *gpio_spec);
+const void *gpio_spec, enum of_gpio_flags *flags);
};
static inline struct of_gpio_chip *to_of_gpio_chip(struct gpio_chip *gc)
@@ -50,20 +63,37 @@ static inline struct of_mm_gpio_chip
*to_of_mm_gpio_chip(struct gpio_chip *gc)
return container_of(of_gc, struct of_mm_gpio_chip, of_gc);
}
-extern int of_get_gpio(struct device_node *np, int index);
+extern int of_get_gpio_flags(struct device_node *np, int index,
+enum of_gpio_flags *flags);
+
extern int of_mm_gpiochip_add(struct device_node *np,
Re: [PATCH] powerpc: Fix dma_map_sg() cache flushing on non coherent platforms
On Nov 30, 2008, at 10:53 PM, Benjamin Herrenschmidt wrote:
On PowerPC 4xx or other non cache coherent platforms, we lost the
appropriate cache flushing in dma_map_sg() when merging the 32
and 64-bit DMA code.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: Becky Bruce <[EMAIL PROTECTED]>
Sins of omission are always the hardest to catch. My apologies,
and thanks!
-B
---
Oops .. nobody spotted that when Becky patches went in !
Paul: This is a 2.6.28 regression and should be merged asap
arch/powerpc/kernel/dma.c |1 +
1 file changed, 1 insertion(+)
--- linux-work.orig/arch/powerpc/kernel/dma.c 2008-12-01
15:44:55.0 +1100
+++ linux-work/arch/powerpc/kernel/dma.c 2008-12-01
15:45:13.0 +1100
@@ -75,6 +75,7 @@ static int dma_direct_map_sg(struct devi
for_each_sg(sgl, sg, nents, i) {
sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
sg->dma_length = sg->length;
+ __dma_sync_page(sg_page(sg), sg->offset, sg->length, direction);
}
return nents;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: i2c-mpc clocking scheme
Trent Piepho wrote: > Seems like it should keep the clock registers at what u-boot set them too. Or we could have U-Boot put the i2c clock frequency into the I2C node, and let the driver program the hardware again. That would keep the ugliness in U-Boot. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: fix problem with flush work completions
This fix enables ehca device driver to generate flush workcompletions even if
the application don't request work completions for all work requests. The
current implementation of ehca will generate flush work completions for
the wrong work requests if an application uses non signaled work completions.
Signed-off-by: root <[EMAIL PROTECTED]>
---
The patch will cleanly apply on top of 2.6.28-rc6.
Roland, please apply this for 2.6.28 if possible.
regards Stefan
drivers/infiniband/hw/ehca/ehca_classes.h |4 ++-
drivers/infiniband/hw/ehca/ehca_qp.c | 26 +++---
drivers/infiniband/hw/ehca/ehca_reqs.c| 51 +
3 files changed, 53 insertions(+), 28 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 4df887a..7fc35cf 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -163,7 +163,8 @@ struct ehca_mod_qp_parm {
/* struct for tracking if cqes have been reported to the application */
struct ehca_qmap_entry {
u16 app_wr_id;
- u16 reported;
+ u8 reported;
+ u8 cqe_req;
};
struct ehca_queue_map {
@@ -171,6 +172,7 @@ struct ehca_queue_map {
unsigned int entries;
unsigned int tail;
unsigned int left_to_poll;
+ unsigned int next_wqe_idx; /* Idx to first wqe to be flushed */
};
struct ehca_qp {
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index 9e05ee2..cadbf0c 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -435,9 +435,13 @@ static void reset_queue_map(struct ehca_queue_map *qmap)
{
int i;
- qmap->tail = 0;
- for (i = 0; i < qmap->entries; i++)
+ qmap->tail = qmap->entries - 1;
+ qmap->left_to_poll = 0;
+ qmap->next_wqe_idx = 0;
+ for (i = 0; i < qmap->entries; i++) {
qmap->map[i].reported = 1;
+ qmap->map[i].cqe_req = 0;
+ }
}
/*
@@ -1121,6 +1125,7 @@ static int calc_left_cqes(u64 wqe_p, struct ipz_queue
*ipz_queue,
void *wqe_v;
u64 q_ofs;
u32 wqe_idx;
+ unsigned int tail_idx;
/* convert real to abs address */
wqe_p = wqe_p & (~(1UL << 63));
@@ -1133,12 +1138,17 @@ static int calc_left_cqes(u64 wqe_p, struct ipz_queue
*ipz_queue,
return -EFAULT;
}
+ tail_idx = (qmap->tail + 1) % qmap->entries;
wqe_idx = q_ofs / ipz_queue->qe_size;
- if (wqe_idx < qmap->tail)
- qmap->left_to_poll = (qmap->entries - qmap->tail) + wqe_idx;
- else
- qmap->left_to_poll = wqe_idx - qmap->tail;
+ /* check all processed wqes, whether a cqe is requested or not */
+ while (tail_idx != wqe_idx) {
+ if (qmap->map[tail_idx].cqe_req)
+ qmap->left_to_poll++;
+ tail_idx = (tail_idx + 1) % qmap->entries;
+ }
+ /* save index in queue, where we have to start flushing */
+ qmap->next_wqe_idx = wqe_idx;
return 0;
}
@@ -1185,10 +1195,14 @@ static int check_for_left_cqes(struct ehca_qp *my_qp,
struct ehca_shca *shca)
} else {
spin_lock_irqsave(&my_qp->send_cq->spinlock, flags);
my_qp->sq_map.left_to_poll = 0;
+ my_qp->sq_map.next_wqe_idx = (my_qp->sq_map.tail + 1) %
+ my_qp->sq_map.entries;
spin_unlock_irqrestore(&my_qp->send_cq->spinlock, flags);
spin_lock_irqsave(&my_qp->recv_cq->spinlock, flags);
my_qp->rq_map.left_to_poll = 0;
+ my_qp->rq_map.next_wqe_idx = (my_qp->rq_map.tail + 1) %
+ my_qp->rq_map.entries;
spin_unlock_irqrestore(&my_qp->recv_cq->spinlock, flags);
}
diff --git a/drivers/infiniband/hw/ehca/ehca_reqs.c
b/drivers/infiniband/hw/ehca/ehca_reqs.c
index 6492807..00a648f 100644
--- a/drivers/infiniband/hw/ehca/ehca_reqs.c
+++ b/drivers/infiniband/hw/ehca/ehca_reqs.c
@@ -179,6 +179,7 @@ static inline int ehca_write_swqe(struct ehca_qp *qp,
qmap_entry->app_wr_id = get_app_wr_id(send_wr->wr_id);
qmap_entry->reported = 0;
+ qmap_entry->cqe_req = 0;
switch (send_wr->opcode) {
case IB_WR_SEND:
@@ -203,8 +204,10 @@ static inline int ehca_write_swqe(struct ehca_qp *qp,
if ((send_wr->send_flags & IB_SEND_SIGNALED ||
qp->init_attr.sq_sig_type == IB_SIGNAL_ALL_WR)
- && !hidden)
+ && !hidden) {
wqe_p->wr_flag |= WQE_WRFLAG_REQ_SIGNAL_COM;
+ qmap_entry->cqe_req = 1;
+ }
if (send_wr->opcode == IB_WR_SEND_WITH_IMM ||
send_wr->opcode == IB_WR_RDMA_WRITE_WITH_IMM) {
@@ -569,6 +572,7 @@ static int internal_post_recv(struct ehca_qp *my_qp,
qmap
Re: [PATCH v2] mmc: Add mmc_vddrange_to_ocrmask() helper function
On Sun, Nov 30, 2008 at 09:06:48PM +0100, Pierre Ossman wrote: > On Wed, 26 Nov 2008 22:54:17 +0300 > Anton Vorontsov <[EMAIL PROTECTED]> wrote: > > > This function sets the OCR mask bits according to provided voltage > > ranges. Will be used by the mmc_spi OpenFirmware bindings. > > > > Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> > > --- > > > > Hi Pierre, > > > > Sorry for the delay. > > > > This looks perfect. Just tell me when you want me to queue it up. I plan resend the series (OF MMC SPI) some time between 2.6.28-rc0 and -rc1, that is, when all needed powerpc patches will be merged into the Linus' tree. Though, the $subject patch could be merged anytime as it doesn't depend on anything else. So, if you'll merge it earlier, that will make things a bit easier: -1 patch to resend. ;-) Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Erratic MPC8248 CPM2 I2C behaviour
On Saturday 29 November 2008 06:41:53 Wolfram Sang wrote: > Hello Laurent, > > > After switching to the powerpc architecture and Jochen Friedrich's > > driver, I've experienced erratic transfer timeouts. Quite frequent at > > first (2.6.26), the problems disappeared on the road to 2.6.27 and have > > now resurfaced. > > Now == current linus.git? Now = both 2.6.27 and 2.6.28-rc8. Best regards, -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Consolidating the lists
Hi all, I am told that after some discussion it has been decided that there is really no longer any need for a separate linuxppc-embedded mailing list. So I will do the following shortly: remove the [EMAIL PROTECTED] mailinglist (the archives will still be available). redirect [EMAIL PROTECTED] to linuxppc-dev@ozlabs.org (this will cease after some random amount of time). Does this sound like a sensible plan? Would it be better to just have email to [EMAIL PROTECTED] bounce with an error pointing to linuxppc-dev? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgptCs9fqZXu2.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc4xx: u-boot sees PCIe endpoint, linux does not.
On Fri, 2008-11-28 at 13:50 +0100, Leon Woestenberg wrote: > Hello, > > AMCC PPC460EX canyonlands board with an FPGA PCIe end point: > > u-boot sees the end point, but Linux does not: > > U-Boot 1.3.3-00249-ga524e11 (Jun 30 2008 - 16:05:51) > CPU: AMCC PowerPC 460EX Rev. A at 800 MHz (PLB=200, OPB=100, EBC=100 MHz) > <...> > Board: Canyonlands - AMCC PPC460EX Evaluation Board, 2*PCIe, Rev. 16 > <...> > PCIE1: successfully set as root-complex > 02 00 2071 2071 00ff 00 > > > Now, if I re-program the end-point FPGA during the u-boot boot > time-out, Linux will recognize the end-point. > > Any takers on what I should start looking for? It's possible that either the reset in between goes bonkers or something else causes your FPGA to stop responding. It looks like a programming problem with the FPGA to me. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: AMCC PPC460EX Canyonlands does not see PCIe end point with only non-prefetchable memory (both 2.6.27.7 and -next)
On Fri, 2008-11-28 at 11:54 +0100, Leon Woestenberg wrote: > > I found out that re-programming the end point FPGA again *just* after > *uboot* read it, and before Linux kernel has started, makes the end > point appear properly. > > Either u-boot leaves the end point in bad state, or the root complex > reset also requires an end point reset. (or a third option I could not > think of yet). I think you are getting a reset yes, maybe your FPGA loses its programming or something similar ? > I'll pick this up on ppc and u-boot mailing list with new info, > especially with the ppc4xx maintainers. > CC me, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
