Re: [PATCH 3/3] powerpc: Use form 1 affinity to setup node distance
On Fri, 2010-04-30 at 14:43 +1000, Anton Blanchard wrote:
> Form 1 affinity allows multiple entries in ibm,associativity-reference-points
> which represent affinity domains in decreasing order of importance. The
> Linux concept of a node is always the first entry, but using the other
> values as an input to node_distance() allows the memory allocator to make
> better decisions on which node to go first when local memory has been
> exhausted.
>
> We keep things simple and create an array indexed by NUMA node, capped at
> 4 entries. Each time we lookup an associativity property we initialise
> the array which is overkill, but since we should only hit this path during
> boot it didn't seem worth adding a per node valid bit.
Ok, so pls dbl check my -next branch (I'm pushing a new one out today
hopefully) and respin :-) 1 and 2 seem to be already there and 3 doesn't
apply (non-trivial).
Thanks !
Cheers,
Ben.
> Signed-off-by: Anton Blanchard
> ---
>
> Index: linux-2.6/arch/powerpc/include/asm/topology.h
> ===
> --- linux-2.6.orig/arch/powerpc/include/asm/topology.h2010-04-29
> 15:58:58.0 +1000
> +++ linux-2.6/arch/powerpc/include/asm/topology.h 2010-04-29
> 15:59:00.0 +1000
> @@ -77,6 +77,9 @@ static inline int pcibus_to_node(struct
> .balance_interval = 1,\
> }
>
> +extern int __node_distance(int, int);
> +#define node_distance(a, b) __node_distance(a, b)
> +
> extern void __init dump_numa_cpu_topology(void);
>
> extern int sysfs_add_device_to_node(struct sys_device *dev, int nid);
> Index: linux-2.6/arch/powerpc/mm/numa.c
> ===
> --- linux-2.6.orig/arch/powerpc/mm/numa.c 2010-04-29 15:58:59.0
> +1000
> +++ linux-2.6/arch/powerpc/mm/numa.c 2010-04-29 22:05:24.0 +1000
> @@ -42,6 +42,12 @@ EXPORT_SYMBOL(node_data);
>
> static int min_common_depth;
> static int n_mem_addr_cells, n_mem_size_cells;
> +static int form1_affinity;
> +
> +#define MAX_DISTANCE_REF_POINTS 4
> +static int distance_ref_points_depth;
> +static const unsigned int *distance_ref_points;
> +static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
>
> static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> unsigned int *nid)
> @@ -179,6 +185,39 @@ static const u32 *of_get_usable_memory(s
> return prop;
> }
>
> +int __node_distance(int a, int b)
> +{
> + int i;
> + int distance = LOCAL_DISTANCE;
> +
> + if (!form1_affinity)
> + return distance;
> +
> + for (i = 0; i < distance_ref_points_depth; i++) {
> + if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
> + break;
> +
> + /* Double the distance for each NUMA level */
> + distance *= 2;
> + }
> +
> + return distance;
> +}
> +
> +static void initialize_distance_lookup_table(int nid,
> + const unsigned int *associativity)
> +{
> + int i;
> +
> + if (!form1_affinity)
> + return;
> +
> + for (i = 0; i < distance_ref_points_depth; i++) {
> + distance_lookup_table[nid][i] =
> + associativity[distance_ref_points[i]];
> + }
> +}
> +
> /* Returns nid in the range [0..MAX_NUMNODES-1], or -1 if no useful numa
> * info is found.
> */
> @@ -200,6 +239,10 @@ static int of_node_to_nid_single(struct
> /* POWER4 LPAR uses 0x as invalid node */
> if (nid == 0x || nid >= MAX_NUMNODES)
> nid = -1;
> +
> + if (nid > 0 && tmp[0] >= distance_ref_points_depth)
> + initialize_distance_lookup_table(nid, tmp);
> +
> out:
> return nid;
> }
> @@ -226,26 +269,10 @@ int of_node_to_nid(struct device_node *d
> }
> EXPORT_SYMBOL_GPL(of_node_to_nid);
>
> -/*
> - * In theory, the "ibm,associativity" property may contain multiple
> - * associativity lists because a resource may be multiply connected
> - * into the machine. This resource then has different associativity
> - * characteristics relative to its multiple connections. We ignore
> - * this for now. We also assume that all cpu and memory sets have
> - * their distances represented at a common level. This won't be
> - * true for hierarchical NUMA.
> - *
> - * In any case the ibm,associativity-reference-points should give
> - * the correct depth for a normal NUMA system.
> - *
> - * - Dave Hansen
> - */
> static int __init find_min_common_depth(void)
> {
> - int depth, index;
> - const unsigned int *ref_points;
> + int depth;
> struct device_node *rtas_root;
> - unsigned int len;
> struct device_node *options;
>
> rtas_root = of_find_node_by_path("/rtas");
> @@ -254,35 +281,62 @@ static int __init find_min_common_depth(
> return -1;
>
> /*
>
Re: [PATCH resend] mpc5121_nfc: Changed SVR check to allow MPC5123.
On Wed, 2010-05-05 at 13:48 -0500, Steve Deiters wrote:
> The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
> revision 2.
>
> Signed-off-by: Steve Deiters
> ---
> drivers/mtd/nand/mpc5121_nfc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/nand/mpc5121_nfc.c
> b/drivers/mtd/nand/mpc5121_nfc.c
> index 191bf99..dc04d74 100644
> --- a/drivers/mtd/nand/mpc5121_nfc.c
> +++ b/drivers/mtd/nand/mpc5121_nfc.c
> @@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
> of_device *op,
>
> /*
>* Check SoC revision. This driver supports only NFC
> - * in MPC5121 revision 2.
> + * in MPC5121 revision 2 and MPC5123 revision 3.
>*/
> rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
> - if (rev != 2) {
> + if ((rev != 2) && (rev != 3)) {
> dev_err(dev, "SoC revision %u is not supported!\n",
> rev);
> return -ENXIO;
> }
Now your patch is line-wrapped. But I fixed it and pushed to
l2-mtd-2.6.git / master.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Page fault on vmalloc'ed memory
On Wed, May 5, 2010 at 7:51 PM, Timur Tabi wrote:
> On Wed, May 5, 2010 at 12:19 AM, Li Yang-R58472 wrote:
>> I got a weird page fault oops on vmalloc'ed area. Digging into the powerpc
>> do_page_fault(), I found there is no handling of address in kernel space
>> unlike the x86 counter part. Does any one know how we deal with the
>> vmalloc'ed area on powerpc? Thanks a lot.
>
> Can you be more specific? Post the oops message, and tell us the
> specific x86 code that you think is missing.
I was doing some preliminary studying before posting it.
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf938d040
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2 P2020 DS
Modules linked in: e1000e(+)
NIP: f938d040 LR: f938d040 CTR: c026d894
REGS: ef94de30 TRAP: 0400 Not tainted (2.6.32-00165-g9e2ec9e-dirty)
MSR: 00029000 CR: 24000422 XER: 2000
TASK = ef91b440[2276] 'insmod' THREAD: ef94c000 CPU: 0
GPR00: f938d040 ef94dee0 ef91b440 0039 00021000 c026e330 706f7261
GPR08: c066789c 5b34 0001 24000422 10018dd0 10096470 10077bd4
GPR16: 100b93fc 100925d4 100bb02c 100b9410 100c6808 1bb4
GPR24: 1bb8 1bdc 001d2ec9 f938d000 c066 ef94c000 f9386e00
NIP [f938d040] e1000_init_module+0x40/0xb8 [e1000e]
LR [f938d040] e1000_init_module+0x40/0xb8 [e1000e]
Call Trace:
[ef94dee0] [f938d040] e1000_init_module+0x40/0xb8 [e1000e] (unreliable)
[ef94def0] [c0001db4] do_one_initcall+0x3c/0x1e0
[ef94df20] [c007db4c] sys_init_module+0xf8/0x21c
[ef94df40] [c0010318] ret_from_syscall+0x0/0x3c
Instruction dump:
3fe0f938 3bff6e00 3c60f938 90010014 38a54b70 7fe4fb78 38635700 486d
3c60f938 7fe4fb78 38635730 485d <3c80f938> 3ca0f938 3c60f938 38846e08
---[ end trace 047b8203944b6a38 ]---
Segmentation fault
The root cause of this oops might not be related with the vmalloc'ed
area processing in Instruction Storage Interrupt. But x86 does have
the code for processing it while we don't. Is it because we have
nothing to do with the vmalloc'ed ISI on PowerPC architecture?
In arch/x86/mm/fault.c:
/*
* We fault-in kernel-space virtual memory on-demand. The
* 'reference' page table is init_mm.pgd.
*
* NOTE! We MUST NOT take any locks for this case. We may
* be in an interrupt or a critical region, and should
* only copy the information from the master page table,
* nothing more.
*
* This verifies that the fault happens in kernel space
* (error_code & 4) == 0, and that the fault was not a
* protection error (error_code & 9) == 0.
*/
if (unlikely(fault_in_kernel_space(address))) {
if (!(error_code & (PF_RSVD | PF_USER | PF_PROT))) {
if (vmalloc_fault(address) >= 0)
return;
if (kmemcheck_fault(regs, address, error_code))
return;
}
/* Can handle a stale RO->RW TLB: */
if (spurious_fault(error_code, address))
return;
/* kprobes don't want to hook the spurious faults: */
if (notify_page_fault(regs))
return;
/*
* Don't take the mm semaphore here. If we fixup a prefetch
* fault we could otherwise deadlock:
*/
bad_area_nosemaphore(regs, error_code, address);
return;
}
In arch/powerpc/mm/fault.c, we do:
/* On a kernel SLB miss we can only check for a valid exception entry */
if (!user_mode(regs) && (address >= TASK_SIZE))
return SIGSEGV;
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Disable CONFIG_SYSFS_DEPRECATED
CONFIG_SYSFS_DEPRECATED can cause issues with newer distros and should not be required for any distro in the last 3 or 4 years, so disable it. Signed-off-by: Anton Blanchard --- diff --git a/arch/powerpc/configs/40x/acadia_defconfig b/arch/powerpc/configs/40x/acadia_defconfig index 8e95f8d..4aa17b6 100644 --- a/arch/powerpc/configs/40x/acadia_defconfig +++ b/arch/powerpc/configs/40x/acadia_defconfig @@ -98,8 +98,7 @@ CONFIG_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/40x/ep405_defconfig b/arch/powerpc/configs/40x/ep405_defconfig index 918f23f..9a5f1ab 100644 --- a/arch/powerpc/configs/40x/ep405_defconfig +++ b/arch/powerpc/configs/40x/ep405_defconfig @@ -98,8 +98,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/40x/hcu4_defconfig b/arch/powerpc/configs/40x/hcu4_defconfig index f87ef03..0b45213 100644 --- a/arch/powerpc/configs/40x/hcu4_defconfig +++ b/arch/powerpc/configs/40x/hcu4_defconfig @@ -98,8 +98,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/40x/kilauea_defconfig b/arch/powerpc/configs/40x/kilauea_defconfig index 19fbcb0..4d2de0b 100644 --- a/arch/powerpc/configs/40x/kilauea_defconfig +++ b/arch/powerpc/configs/40x/kilauea_defconfig @@ -98,8 +98,7 @@ CONFIG_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/40x/makalu_defconfig b/arch/powerpc/configs/40x/makalu_defconfig index eb41cd6..a1f3f50 100644 --- a/arch/powerpc/configs/40x/makalu_defconfig +++ b/arch/powerpc/configs/40x/makalu_defconfig @@ -98,8 +98,7 @@ CONFIG_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/40x/virtex_defconfig b/arch/powerpc/configs/40x/virtex_defconfig index 416e79a..c763135 100644 --- a/arch/powerpc/configs/40x/virtex_defconfig +++ b/arch/powerpc/configs/40x/virtex_defconfig @@ -77,8 +77,7 @@ CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set diff --git a/arch/powerpc/configs/40x/walnut_defconfig b/arch/powerpc/configs/40x/walnut_defconfig index bfff0ea..6597b2f 100644 --- a/arch/powerpc/configs/40x/walnut_defconfig +++ b/arch/powerpc/configs/40x/walnut_defconfig @@ -98,8 +98,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/44x/arches_defconfig b/arch/powerpc/configs/44x/arches_defconfig index 1f6d049..2d3dfb5 100644 --- a/arch/powerpc/configs/44x/arches_defconfig +++ b/arch/powerpc/configs/44x/arches_defconfig @@ -98,8 +98,7 @@ CONFIG_RCU_FANOUT=32 CONFIG_LOG_BUF_SHIFT=14 # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerpc/configs/44x/bamboo_defconfig b/arch/powerpc/configs/44x/bamboo_defconfig index 788faac..51a00c4 100644 --- a/arch/powerpc/configs/44x/bamboo_defconfig +++ b/arch/powerpc/configs/44x/bamboo_defconfig @@ -102,8 +102,7 @@ CONFIG_FAIR_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set -CONFIG_SYSFS_DEPRECATED=y -CONFIG_SYSFS_DEPRECATED_V2=y +# CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y diff --git a/arch/powerp
Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
Randy Dunlap [randy.dun...@oracle.com] wrote: | > + base of the region allocated for stack. These architectures | > + must pass in the size of the stack-region in ->child_stack_size. | |stack region | | Seems unfortunate that different architectures use the fields differently. Yes and no. The field still has a single purpose, just that some architectures may not need it. We enforce that if unused on an architecture, the field must be 0. It looked like the easiest way to keep the API common across architectures. | | Is this example program meant to build only on i386? Yes. Will add a pointer to the clone*.[chS] and libeclone.a files in git://git.ncl.cs.columbia.edu/pub/git/user-cr.git for other architectures (currently x86_64, ppc, s390). Thanks for the review. Will fix the errors and repost. Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
On Wed, Feb 17, 2010 at 07:59:14PM +0100, Albrecht Dreà wrote:
> This patch improves the recovery of the MPC's I2C bus from errors like bus
> hangs resulting in timeouts:
> 1. make the bus timeout configurable, as it depends on the bus clock and
> the attached slave chip(s); default is still 1 second;
> 2. detect any of the cases indicated by the CF, BB and RXAK MSR flags if a
> timeout occurs, and add a missing (required) MAL reset;
> 3. use a more reliable method to fixup the bus if a hang has been detected.
> The sequence is sent 9 times which seems to be necessary if a slave
> "misses" more than one clock cycle. For 400 kHz bus speed, the fixup is
> also ~70us (81us vs. 150us) faster.
>
> Tested on a custom Lite5200b derived board, with a Dallas RTC, AD sensors
> and NXP IO expander chips attached to the i2c.
>
> Changes vs. v1:
> - use improved bus fixup sequence for all chips (not only the 5200)
> - calculate real clock from defaults if no clock is given in the device tree
> - better description (I hope) of the changes.
>
> I didn't split the changes in this file into three parts as recommended by
> Grant, as they actually belong together (i.e. they address one single
> problem, just in three places of one single source file).
>
> Signed-off-by: Albrecht DreÃ
>
> ---
>
> Note about the reset sequence: I verified the waveforms for 18.4kHz, 85.9kHz
> and 375kHz (drop me a note if you want to see scope screen shots). Not
> verified on other mpc chips yet.
> @Ira: thanks in advance for giving it a try on your box!
>
Did this series get forgotten about? I don't see it in bjdook's next-i2c
branch or in benh's next branch.
I've pulled these into my 2.6.31.13 kernel, and they seem to work fine.
You've got my Tested-by if you didn't get one from me already.
Ira
> --- linux-2.6.32-orig/drivers/i2c/busses/i2c-mpc.c2009-12-03
> 04:51:21.0 +0100
> +++ linux-2.6.32/drivers/i2c/busses/i2c-mpc.c 2010-02-17 16:23:11.0
> +0100
> @@ -59,6 +59,7 @@ struct mpc_i2c {
> wait_queue_head_t queue;
> struct i2c_adapter adap;
> int irq;
> + u32 real_clk;
> };
>
> struct mpc_i2c_divider {
> @@ -93,20 +94,23 @@ static irqreturn_t mpc_i2c_isr(int irq,
> /* Sometimes 9th clock pulse isn't generated, and slave doesn't release
>* the bus, because it wants to send ACK.
>* Following sequence of enabling/disabling and sending start/stop generates
> - * the pulse, so it's all OK.
> + * the 9 pulses, so it's all OK.
>*/
> static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> {
> - writeccr(i2c, 0);
> - udelay(30);
> - writeccr(i2c, CCR_MEN);
> - udelay(30);
> - writeccr(i2c, CCR_MSTA | CCR_MTX);
> - udelay(30);
> - writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> - udelay(30);
> - writeccr(i2c, CCR_MEN);
> - udelay(30);
> + int k;
> + u32 delay_val = 100 / i2c->real_clk + 1;
> +
> + if (delay_val < 2)
> + delay_val = 2;
> +
> + for (k = 9; k; k--) {
> + writeccr(i2c, 0);
> + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> + udelay(delay_val);
> + writeccr(i2c, CCR_MEN);
> + udelay(delay_val << 1);
> + }
> }
>
> static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> @@ -186,15 +190,19 @@ static const struct mpc_i2c_divider mpc_
> {10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
> };
>
> -int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler)
> +int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock, int prescaler,
> + u32 *real_clk)
> {
> const struct mpc_i2c_divider *div = NULL;
> unsigned int pvr = mfspr(SPRN_PVR);
> u32 divider;
> int i;
>
> - if (!clock)
> + if (!clock) {
> + /* see below - default fdr = 0x3f -> div = 2048 */
> + *real_clk = mpc5xxx_get_bus_frequency(node) / 2048;
> return -EINVAL;
> + }
>
> /* Determine divider value */
> divider = mpc5xxx_get_bus_frequency(node) / clock;
> @@ -212,7 +220,8 @@ int mpc_i2c_get_fdr_52xx(struct device_n
> break;
> }
>
> - return div ? (int)div->fdr : -EINVAL;
> + *real_clk = mpc5xxx_get_bus_frequency(node) / div->divider;
> + return (int)div->fdr;
> }
>
> static void mpc_i2c_setclock_52xx(struct device_node *node,
> @@ -221,13 +230,14 @@ static void mpc_i2c_setclock_52xx(struct
> {
> int ret, fdr;
>
> - ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler);
> + ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler, &i2c->real_clk);
> fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
>
> writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
>
> if (ret >= 0)
> - dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
> + dev_info(i2c->dev, "clock %u Hz (fdr=%d)\n", i2c->real_clk,
> +
Re: [PATCH v21 011/100] eclone (11/11): Document sys_eclone
On Sat, 1 May 2010 10:14:53 -0400 Oren Laadan wrote:
> From: Sukadev Bhattiprolu
>
> This gives a brief overview of the eclone() system call. We should
> eventually describe more details in existing clone(2) man page or in
> a new man page.
>
> Signed-off-by: Sukadev Bhattiprolu
> Acked-by: Serge E. Hallyn
> Acked-by: Oren Laadan
> ---
> Documentation/eclone | 348
> ++
> 1 files changed, 348 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/eclone
>
> diff --git a/Documentation/eclone b/Documentation/eclone
> new file mode 100644
> index 000..c2f1b4b
> --- /dev/null
> +++ b/Documentation/eclone
> @@ -0,0 +1,348 @@
> +
> +struct clone_args {
> + u64 clone_flags_high;
> + u64 child_stack;
> + u64 child_stack_size;
> + u64 parent_tid_ptr;
> + u64 child_tid_ptr;
> + u32 nr_pids;
> + u32 reserved0;
> +};
> +
> +
> +sys_eclone(u32 flags_low, struct clone_args * __user cargs, int cargs_size,
> + pid_t * __user pids)
> +
> + In addition to doing everything that clone() system call does, the
that the clone()
> + eclone() system call:
> +
> + - allows additional clone flags (31 of 32 bits in the flags
> + parameter to clone() are in use)
> +
> + - allows user to specify a pid for the child process in its
> + active and ancestor pid namespaces.
> +
> + This system call is meant to be used when restarting an application
> + from a checkpoint. Such restart requires that the processes in the
> + application have the same pids they had when the application was
> + checkpointed. When containers are nested, the processes within the
> + containers exist in multiple pid namespaces and hence have multiple
> + pids to specify during restart.
> +
> + The @flags_low parameter is identical to the 'clone_flags' parameter
> + in existing clone() system call.
in the existing
> +
> + The fields in 'struct clone_args' are meant to be used as follows:
> +
> + u64 clone_flags_high:
> +
> + When eclone() supports more than 32 flags, the additional bits
> + in the clone_flags should be specified in this field. This
> + field is currently unused and must be set to 0.
> +
> + u64 child_stack;
> + u64 child_stack_size;
> +
> + These two fields correspond to the 'child_stack' fields in
> + clone() and clone2() (on IA64) system calls. The usage of
> + these two fields depends on the processor architecture.
> +
> + Most architectures use ->child_stack to pass-in a stack-pointer
to pass in
> + itself and don't need the ->child_stack_size field. On these
> + architectures the ->child_stack_size field must be 0.
> +
> + Some architectures, eg IA64, use ->child_stack to pass-in the
e.g.to pass in
> + base of the region allocated for stack. These architectures
> + must pass in the size of the stack-region in ->child_stack_size.
stack region
Seems unfortunate that different architectures use the fields differently.
> +
> + u64 parent_tid_ptr;
> + u64 child_tid_ptr;
> +
> + These two fields correspond to the 'parent_tid_ptr' and
> + 'child_tid_ptr' fields in the clone() system call
system call.
> +
> + u32 nr_pids;
> +
> + nr_pids specifies the number of pids in the @pids array
> + parameter to eclone() (see below). nr_pids should not exceed
> + the current nesting level of the calling process (i.e if the
i.e.
> + process is in init_pid_ns, nr_pids must be 1, if process is
> + in a pid namespace that is a child of init-pid-ns, nr_pids
> + cannot exceed 2, and so on).
> +
> + u32 reserved0;
> + u64 reserved1;
> +
> + These fields are intended to extend the functionality of the
> + eclone() in the future, while preserving backward compatibility.
> + They must be set to 0 for now.
The struct does not have a reserved1 field AFAICT.
> + The @cargs_size parameter specifes the sizeof(struct clone_args) and
> + is intended to enable extending this structure in the future, while
> + preserving backward compatibility. For now, this field must be set
> + to the sizeof(struct clone_args) and this size must match the kernel's
> + view of the structure.
> +
> + The @pids parameter defines the set of pids that should be assigned to
> + the child process in its active and ancestor pid
[PATCH 2/3] virtio: console: Store each console's size in the console structure
With support for multiple consoles, just using one {rows,cols} pair in
the config space is not going to suffice.
Store each console's size as part of the console struct.
This changes the behaviour for one case when multiport is not enabled:
when notifier_add_vio() is called, the console size is taken from that
of the last config-space update instead of fetching it afresh from the
config space.
Also add a helper to update the size in the console struct as we'll need
to use the same code to update the size via control messages when
multiport support is enabled.
Signed-off-by: Amit Shah
CC: Christian Borntraeger
CC: linuxppc-...@ozlabs.org
CC: Kusanagi Kouichi
---
drivers/char/virtio_console.c | 43 +---
1 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index e2d05ea..ccfe68a 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -78,6 +78,9 @@ struct console {
/* The hvc device associated with this console port */
struct hvc_struct *hvc;
+ /* The size of the console */
+ struct winsize ws;
+
/*
* This number identifies the number that we used to register
* with hvc in hvc_instantiate() and hvc_alloc(); this is the
@@ -773,22 +776,14 @@ static int get_chars(u32 vtermno, char *buf, int count)
static void resize_console(struct port *port)
{
struct virtio_device *vdev;
- struct winsize ws;
/* The port could have been hot-unplugged */
- if (!port)
+ if (!port || !is_console_port(port))
return;
vdev = port->portdev->vdev;
- if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE)) {
- vdev->config->get(vdev,
- offsetof(struct virtio_console_config, cols),
- &ws.ws_col, sizeof(u16));
- vdev->config->get(vdev,
- offsetof(struct virtio_console_config, rows),
- &ws.ws_row, sizeof(u16));
- hvc_resize(port->cons.hvc, ws);
- }
+ if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_SIZE))
+ hvc_resize(port->cons.hvc, port->cons.ws);
}
/* We set the configuration at this point, since we now have a tty */
@@ -952,6 +947,15 @@ static const struct file_operations port_debugfs_ops = {
.read = debugfs_read,
};
+static void set_console_size(struct port *port, u16 rows, u16 cols)
+{
+ if (!port || !is_console_port(port))
+ return;
+
+ port->cons.ws.ws_row = rows;
+ port->cons.ws.ws_col = cols;
+}
+
static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
{
struct port_buffer *buf;
@@ -1000,6 +1004,8 @@ static int add_port(struct ports_device *portdev, u32 id)
port->inbuf = NULL;
port->cons.hvc = NULL;
+ port->cons.ws.ws_row = port->cons.ws.ws_col = 0;
+
port->host_connected = port->guest_connected = false;
port->outvq_full = false;
@@ -1320,6 +1326,19 @@ static void config_intr(struct virtio_device *vdev)
portdev = vdev->priv;
if (!use_multiport(portdev)) {
+ struct port *port;
+ u16 rows, cols;
+
+ vdev->config->get(vdev,
+ offsetof(struct virtio_console_config, cols),
+ &cols, sizeof(u16));
+ vdev->config->get(vdev,
+ offsetof(struct virtio_console_config, rows),
+ &rows, sizeof(u16));
+
+ port = find_port_by_id(portdev, 0);
+ set_console_size(port, rows, cols);
+
/*
* We'll use this way of resizing only for legacy
* support. For newer userspace
@@ -1327,7 +1346,7 @@ static void config_intr(struct virtio_device *vdev)
* to indicate console size changes so that it can be
* done per-port.
*/
- resize_console(find_port_by_id(portdev, 0));
+ resize_console(port);
}
}
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] virtio: console: Accept console size along with resize control message
The VIRTIO_CONSOLE_RESIZE control message sent to us by the host now
contains the new {rows, cols} values for the console. This ensures each
console port gets its own size, and we don't depend on the config-space
rows and cols values at all now.
Signed-off-by: Amit Shah
CC: Christian Borntraeger
CC: linuxppc-...@ozlabs.org
CC: Kusanagi Kouichi
---
drivers/char/virtio_console.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index ccfe68a..5cab839 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1194,12 +1194,23 @@ static void handle_control_message(struct ports_device
*portdev,
* have to notify the host first.
*/
break;
- case VIRTIO_CONSOLE_RESIZE:
+ case VIRTIO_CONSOLE_RESIZE: {
+ struct {
+ __u16 rows;
+ __u16 cols;
+ } size;
+
if (!is_console_port(port))
break;
+
+ memcpy(&size, buf->buf + buf->offset + sizeof(*cpkt),
+ sizeof(size));
+ set_console_size(port, size.rows, size.cols);
+
port->cons.hvc->irq_requested = 1;
resize_console(port);
break;
+ }
case VIRTIO_CONSOLE_PORT_OPEN:
port->host_connected = cpkt->value;
wake_up_interruptible(&port->waitqueue);
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] virtio: console: Resize console port 0 on config intr only if multiport is off
When using multiport, we'll use control messages. Ensure we don't
accidentally update port 0 size on config interrupts.
Signed-off-by: Amit Shah
CC: Christian Borntraeger
CC: linuxppc-...@ozlabs.org
CC: Kusanagi Kouichi
---
drivers/char/virtio_console.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index a64558f..e2d05ea 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1319,13 +1319,16 @@ static void config_intr(struct virtio_device *vdev)
portdev = vdev->priv;
- /*
-* We'll use this way of resizing only for legacy support.
-* For newer userspace (VIRTIO_CONSOLE_F_MULTPORT+), use
-* control messages to indicate console size changes so that
-* it can be done per-port
-*/
- resize_console(find_port_by_id(portdev, 0));
+ if (!use_multiport(portdev)) {
+ /*
+* We'll use this way of resizing only for legacy
+* support. For newer userspace
+* (VIRTIO_CONSOLE_F_MULTPORT+), use control messages
+* to indicate console size changes so that it can be
+* done per-port.
+*/
+ resize_console(find_port_by_id(portdev, 0));
+ }
}
static int init_vqs(struct ports_device *portdev)
--
1.6.2.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH resend] mpc5121_nfc: Changed SVR check to allow MPC5123.
The revision in SVR for MPC5123 is 3. The NFC is the same as MPC5121
revision 2.
Signed-off-by: Steve Deiters
---
drivers/mtd/nand/mpc5121_nfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/mpc5121_nfc.c
b/drivers/mtd/nand/mpc5121_nfc.c
index 191bf99..dc04d74 100644
--- a/drivers/mtd/nand/mpc5121_nfc.c
+++ b/drivers/mtd/nand/mpc5121_nfc.c
@@ -666,10 +666,10 @@ static int __devinit mpc5121_nfc_probe(struct
of_device *op,
/*
* Check SoC revision. This driver supports only NFC
-* in MPC5121 revision 2.
+* in MPC5121 revision 2 and MPC5123 revision 3.
*/
rev = (mfspr(SPRN_SVR) >> 4) & 0xF;
- if (rev != 2) {
+ if ((rev != 2) && (rev != 3)) {
dev_err(dev, "SoC revision %u is not supported!\n",
rev);
return -ENXIO;
}
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel errors at very early stage
On Wed, May 5, 2010 at 3:27 AM, Dunda, Matthias wrote: > Hi all- > > we've built a custom board with a FSL MPC8568EMDS CPU. > > U-Boot works so far - at least it is able to load a Linux kernel and a > flattened device tree via network and launch the kernel. > > I get no output on the serial console from the kernel, so my only chance is > to read out the __log_buf while in memory with my Abatron BDI 3000 debugger. > > The thing is, I cannot break into the code really, because it never stops > reliable at my break points... :-( > > Can anyone of you see a usual suspect in the attached log? > > Is there something wrong with the timing, maybe? Maybe a hardware issue? > > How can I check this? > > Cheers > Matthias > > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > from the log it seems your device tree has issue, also you may want to turn on verbose debug, turn off preempt, turn off no_hz and see how far it can go. if only log_buf is available to get some output, you may want to increase the buffer size to see more xianghua ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH]460EX on-chip SATA driver < resubmission >
This patch enables the on-chip DWC SATA controller of the AppliedMicro
processor 460EX.
Signed-off-by: Rupjyoti Sarmah
Signed-off-by: Mark Miesfeld
Signed-off-by: Prodyut Hazarika
---
arch/powerpc/boot/dts/canyonlands.dts |8 +
drivers/ata/Kconfig |9 +
drivers/ata/Makefile |1 +
drivers/ata/sata_dwc.c| 1827 +
4 files changed, 1845 insertions(+), 0 deletions(-)
create mode 100644 drivers/ata/sata_dwc.c
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index cd56bb5..d3b2c99 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -163,6 +163,14 @@
interrupts = <0x1e 4>;
};
+ SATA0: s...@bffd1000 {
+compatible = "amcc,sata-460ex";
+ reg = <4 0xbffd1000 0x800 4 0xbffd0800 0x400>;
+interrupt-parent = <&UIC3>;
+interrupts = <0x0 0x4 /* SATA */
+ 0x5 0x4>; /* AHBDMA */
+};
+
POB0: opb {
compatible = "ibm,opb-460ex", "ibm,opb";
#address-cells = <1>;
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 56c6374..bba7b8a 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -82,6 +82,15 @@ config SATA_FSL
If unsure, say N.
+config SATA_DWC
+ tristate "DesignWare Cores SATA support"
+ depends on 460EX
+ help
+ This option enables support for the on-chip SATA controller of the
+ AppliedMicro processor 460EX.
+
+ If unsure, say N.
+
config ATA_SFF
bool "ATA SFF support"
default y
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index fc936d4..0de7a33 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
obj-$(CONFIG_SATA_FSL) += sata_fsl.o
obj-$(CONFIG_PATA_MACIO) += pata_macio.o
+obj-$(CONFIG_SATA_DWC) += sata_dwc.o
obj-$(CONFIG_PATA_ALI) += pata_ali.o
obj-$(CONFIG_PATA_AMD) += pata_amd.o
diff --git a/drivers/ata/sata_dwc.c b/drivers/ata/sata_dwc.c
new file mode 100644
index 000..e499ac6
--- /dev/null
+++ b/drivers/ata/sata_dwc.c
@@ -0,0 +1,1827 @@
+/*
+ * drivers/ata/sata_dwc.c
+ *
+ * Synopsys DesignWare Cores (DWC) SATA host driver
+ *
+ * Author: Mark Miesfeld
+ *
+ * Ported from 2.6.19.2 to 2.6.25/26 by Stefan Roese
+ * Copyright 2008 DENX Software Engineering
+ *
+ * Based on versions provided by AMCC and Synopsys which are:
+ * Copyright 2006 Applied Micro Circuits Corporation
+ * COPYRIGHT (C) 2005 SYNOPSYS, INC. ALL RIGHTS RESERVED
+ *
+ * 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.
+ *
+ */
+
+#ifdef CONFIG_SATA_DWC_DEBUG
+#define DEBUG
+#endif
+
+#ifdef CONFIG_SATA_DWC_VDEBUG
+#define VERBOSE_DEBUG
+#define DEBUG_NCQ
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "libata.h"
+
+#include
+#include
+
+#define DRV_NAME"sata-dwc"
+#define DRV_VERSION "1.0"
+
+/* SATA DMA driver Globals */
+#define DMA_NUM_CHANS 1
+#define DMA_NUM_CHAN_REGS 8
+
+/* SATA DMA Register definitions */
+#define AHB_DMA_BRST_DFLT 64 /* 16 data items burst length*/
+
+struct dmareg {
+ u32 low;/* Low bits 0-31 */
+ u32 high; /* High bits 32-63 */
+};
+
+/* DMA Per Channel registers */
+
+struct dma_chan_regs {
+ struct dmareg sar; /* Source Address */
+ struct dmareg dar; /* Destination address */
+ struct dmareg llp; /* Linked List Pointer */
+ struct dmareg ctl; /* Control */
+ struct dmareg sstat;/* Source Status not implemented in core */
+ struct dmareg dstat;/* Destination Status not implemented in core*/
+ struct dmareg sstatar; /* Source Status Address not impl in core */
+ struct dmareg dstatar; /* Destination Status Address not implemente */
+ struct dmareg cfg; /* Config */
+ struct dmareg sgr; /* Source Gather */
+ struct dmareg dsr; /* Destination Scatter */
+};
+
+/* Generic Interrupt Registers */
+struct dma_interrupt_regs {
+ struct dmareg tfr; /* Transfer Interrupt */
+ struct dmareg block;/* Block Interrupt */
+ struct dmareg srctran; /* Source Transfer Interrupt */
+ struct dmareg dsttran; /* Dest Transfer Interrupt */
+ struct dmareg error;/* Error */
+};
+
+struct ahb_dma_regs {
+ struct dma_
Re: question about cpm_uart_cpm2.c "Section mismatch in reference from the function cpm_uart_allocbuf"
On Wed, May 05, 2010 at 07:19:18PM +0800, xiaokun wrote: > I am using MPC8272ADS_20080623-ltib.iso from freescale > > The Linux Kernel is 2.6.25. > > When I make uImage, the error message is : > > WARNING: vmlinux.o(.text+0x159450): Section mismatch in reference from the > function cpm_uart_allocbuf() to the function .init.text:__alloc_bootmem() > The function cpm_uart_allocbuf() references > the function __init __alloc_bootmem(). > This is often because cpm_uart_allocbuf lacks a __init > annotation or the annotation of __alloc_bootmem is wrong. That is expected, ignore it. The function is called early enough to need to use bootmem, and called again too late for __init. It determines which to use based on whether it was called to set up the console or not. Note that the problem no longer exists in current kernels because kmalloc is usable earlier. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Please pull 'next' branch of 4xx tree
Hi Ben, A late pull request for -next, so my apologies in advance. This contains the first 7 patches of the 476 series. I did a build/boot test on 440EPx for each patch individually and fixed up a few minor issues. The 440EPx seems to be running just fine for all of them. This also has the reset type patch from Stefan in it, as I've tested that as well. josh The following changes since commit cb694769f0d0c1f6fb8c9dc806c0a68da1056055: Benjamin Herrenschmidt (1): Revert "powerpc/mm: Bump SECTION_SIZE_BITS from 16MB to 256MB" are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git next Dave Kleikamp (5): powerpc/44x: break out cpu init code into stand-alone function powerpc/47x: Base ppc476 support powerpc/476: add machine check handler for 47x core powerpc/476: Add isync after loading mmu and debug spr's powerpc/47x: defconfig for 476 on the iss 4xx simulator Stefan Roese (1): powerpc/4xx: Add optional "reset_type" property to control reboot via dts Torez Smith (2): powerpc/booke: Add Stack Marking support to Booke Exception Prolog powerpc/4xx: Simple platform for the ISS 4xx simulator Documentation/powerpc/dts-bindings/4xx/reboot.txt | 18 + arch/powerpc/boot/Makefile|5 +- arch/powerpc/boot/dts/iss4xx-mpic.dts | 155 arch/powerpc/boot/dts/iss4xx.dts | 116 +++ arch/powerpc/boot/treeboot-iss4xx.c | 56 ++ arch/powerpc/boot/wrapper |3 + arch/powerpc/configs/44x/iss476-smp_defconfig | 1026 + arch/powerpc/include/asm/cache.h |6 +- arch/powerpc/include/asm/cputable.h |5 + arch/powerpc/include/asm/mmu-44x.h| 51 +- arch/powerpc/include/asm/mmu.h|1 + arch/powerpc/include/asm/reg.h|4 + arch/powerpc/include/asm/reg_booke.h | 24 + arch/powerpc/kernel/cputable.c| 29 + arch/powerpc/kernel/entry_32.S|5 + arch/powerpc/kernel/head_44x.S| 828 + arch/powerpc/kernel/head_booke.h |4 + arch/powerpc/kernel/kprobes.c |3 + arch/powerpc/kernel/misc_32.S |9 +- arch/powerpc/kernel/process.c |3 + arch/powerpc/kernel/smp.c |8 + arch/powerpc/kernel/traps.c | 40 + arch/powerpc/mm/44x_mmu.c | 144 +++- arch/powerpc/mm/mmu_context_nohash.c |8 + arch/powerpc/mm/mmu_decl.h|7 +- arch/powerpc/mm/tlb_nohash_low.S | 118 +++- arch/powerpc/platforms/44x/Kconfig| 20 + arch/powerpc/platforms/44x/Makefile |1 + arch/powerpc/platforms/44x/iss4xx.c | 167 arch/powerpc/platforms/Kconfig.cputype|5 +- arch/powerpc/sysdev/ppc4xx_soc.c | 24 +- 31 files changed, 2690 insertions(+), 203 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/4xx/reboot.txt create mode 100644 arch/powerpc/boot/dts/iss4xx-mpic.dts create mode 100644 arch/powerpc/boot/dts/iss4xx.dts create mode 100644 arch/powerpc/boot/treeboot-iss4xx.c create mode 100644 arch/powerpc/configs/44x/iss476-smp_defconfig create mode 100644 arch/powerpc/platforms/44x/iss4xx.c ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
Mark Brown wrote: > On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote: >> On Wed, May 5, 2010 at 6:22 AM, Mark Brown > >>> Just looking at the scheduling here with regard to the merge window and >>> the fact that this doesn't seem to hurt the existing drivers perhaps it >>> makes sense to merge this via the PowerPC tree immediately? > >> Aren't we a little late in the cycle for a patch that doesn't do anything? > > It seems to be safe enough for -next. Sure, -next is fine. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] media/IR: Add missing include file to rc-map.c
From: Peter Huewe This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe --- KernelVersion: linux-next-20100505 References: [1] http://kisskb.ellerman.id.au/kisskb/buildresult/2571452/ [2] http://kisskb.ellerman.id.au/kisskb/buildresult/2571188/ [3] http://kisskb.ellerman.id.au/kisskb/buildresult/2571479/ [4] http://kisskb.ellerman.id.au/kisskb/buildresult/2571429/ [5] http://kisskb.ellerman.id.au/kisskb/buildresult/2571432/ drivers/media/IR/rc-map.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/IR/rc-map.c b/drivers/media/IR/rc-map.c index caf6a27..46a8f15 100644 --- a/drivers/media/IR/rc-map.c +++ b/drivers/media/IR/rc-map.c @@ -14,6 +14,7 @@ #include #include +#include /* Used to handle IR raw handler extensions */ static LIST_HEAD(rc_map_list); -- 1.6.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v21 001/100] eclone (1/11): Factor out code to allocate pidmap page
Hi David, I suppose you are looking for more details than those found in the current patch-0 (http://lkml.org/lkml/2010/5/1/140). We omitted them for brevity sake; here is a link to patch-0 of a previous post of the patchset: http://lkml.org/lkml/2009/9/23/423 Thanks, Oren. David Howells wrote: With a huge patch series like this, can you post a cover note at the front (usually patch 0) saying what the point of the whole series is? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/13] powerpc/4xx: Simple platform for the ISS 4xx simulator
On Wed, 2010-05-05 at 11:11 -0400, Josh Boyer wrote:
> On Fri, Mar 05, 2010 at 01:45:54PM -0700, Dave Kleikamp wrote:
> >+config ISS4xx
> >+bool "ISS 4xx Simulator"
> >+depends on (44x || 40x)
> >+default n
> >+select 405GP if 40x
> >+select 440GP if 44x && !PPC_47x
> >+select PPC_FPU
> >+select OF_RTC
> >+help
> >+ This option enables support for the IBM ISS simulation environment
>
> This looks like how we want to do this, however...
>
> >+/* We can have either UICs or MPICs */
> >+static void __init iss4xx_init_irq(void)
> >+{
> >+struct device_node *np;
> >+
> >+/* Find top level interrupt controller */
> >+for_each_node_with_property(np, "interrupt-controller") {
> >+if (of_get_property(np, "interrupts", NULL) == NULL)
> >+break;
> >+}
> >+if (np == NULL)
> >+panic("Can't find top level interrupt controller");
> >+
> >+/* Check type and do appropriate initialization */
> >+if (of_device_is_compatible(np, "ibm,uic")) {
> >+uic_init_tree();
> >+ppc_md.get_irq = uic_get_irq;
> >+} else if (of_device_is_compatible(np, "chrp,open-pic")) {
> >+/* The MPIC driver will get everything it needs from the
> >+ * device-tree, just pass 0 to all arguments
> >+ */
> >+struct mpic *mpic = mpic_alloc(np, 0, MPIC_PRIMARY, 0, 0,
> >+ " MPIC ");
> >+BUG_ON(mpic == NULL);
> >+mpic_init(mpic);
> >+ppc_md.get_irq = mpic_get_irq;
> >+} else
> >+panic("Unrecognized top level interrupt controller");
> >+}
>
> .. on non-476 builds we get link errors:
>
> arch/powerpc/platforms/built-in.o: In function `as1_writeb':
> (.init.text+0x5d4): undefined reference to `mpic_alloc'
> arch/powerpc/platforms/built-in.o: In function `as1_writeb':
> (.init.text+0x5e4): undefined reference to `mpic_init'
> arch/powerpc/platforms/built-in.o: In function `as1_writeb':
> (.init.text+0x5ea): undefined reference to `mpic_get_irq'
> arch/powerpc/platforms/built-in.o: In function `as1_writeb':
> (.init.text+0x5ee): undefined reference to `mpic_get_irq'
> make: *** [.tmp_vmlinux1] Error 1
>
> because we don't have CONFIG_MPIC turned on for these. I'd suggest we guard
> the mpic else chunk in this file behind CONFIG_MPIC. Agreed?
Yeah. That's reasonable.
> I'm less worried about the mpic references that are already guarded behind the
> CONFIG_SMP sections. Nobody has been crazy enough to make an SMP 440 or 460
> SoC
> yet, so CONFIG_SMP should only get selected for 476, and that already selects
> MPIC in the Kconfig.
>
> josh
--
Dave Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 06/13] powerpc/4xx: Simple platform for the ISS 4xx simulator
On Fri, Mar 05, 2010 at 01:45:54PM -0700, Dave Kleikamp wrote:
>+config ISS4xx
>+ bool "ISS 4xx Simulator"
>+ depends on (44x || 40x)
>+ default n
>+ select 405GP if 40x
>+ select 440GP if 44x && !PPC_47x
>+ select PPC_FPU
>+ select OF_RTC
>+ help
>+This option enables support for the IBM ISS simulation environment
This looks like how we want to do this, however...
>+/* We can have either UICs or MPICs */
>+static void __init iss4xx_init_irq(void)
>+{
>+ struct device_node *np;
>+
>+ /* Find top level interrupt controller */
>+ for_each_node_with_property(np, "interrupt-controller") {
>+ if (of_get_property(np, "interrupts", NULL) == NULL)
>+ break;
>+ }
>+ if (np == NULL)
>+ panic("Can't find top level interrupt controller");
>+
>+ /* Check type and do appropriate initialization */
>+ if (of_device_is_compatible(np, "ibm,uic")) {
>+ uic_init_tree();
>+ ppc_md.get_irq = uic_get_irq;
>+ } else if (of_device_is_compatible(np, "chrp,open-pic")) {
>+ /* The MPIC driver will get everything it needs from the
>+ * device-tree, just pass 0 to all arguments
>+ */
>+ struct mpic *mpic = mpic_alloc(np, 0, MPIC_PRIMARY, 0, 0,
>+ " MPIC ");
>+ BUG_ON(mpic == NULL);
>+ mpic_init(mpic);
>+ ppc_md.get_irq = mpic_get_irq;
>+ } else
>+ panic("Unrecognized top level interrupt controller");
>+}
.. on non-476 builds we get link errors:
arch/powerpc/platforms/built-in.o: In function `as1_writeb':
(.init.text+0x5d4): undefined reference to `mpic_alloc'
arch/powerpc/platforms/built-in.o: In function `as1_writeb':
(.init.text+0x5e4): undefined reference to `mpic_init'
arch/powerpc/platforms/built-in.o: In function `as1_writeb':
(.init.text+0x5ea): undefined reference to `mpic_get_irq'
arch/powerpc/platforms/built-in.o: In function `as1_writeb':
(.init.text+0x5ee): undefined reference to `mpic_get_irq'
make: *** [.tmp_vmlinux1] Error 1
because we don't have CONFIG_MPIC turned on for these. I'd suggest we guard
the mpic else chunk in this file behind CONFIG_MPIC. Agreed?
I'm less worried about the mpic references that are already guarded behind the
CONFIG_SMP sections. Nobody has been crazy enough to make an SMP 440 or 460 SoC
yet, so CONFIG_SMP should only get selected for 476, and that already selects
MPIC in the Kconfig.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: question about cpm_uart_cpm2.c "Section mismatch in reference from the function cpm_uart_allocbuf"
On Wed, 5 May 2010 19:19:18 +0800 xiaokun wrote: > I am using MPC8272ADS_20080623-ltib.iso from freescale > > The Linux Kernel is 2.6.25. > > When I make uImage, the error message is : > > WARNING: vmlinux.o(.text+0x159450): Section mismatch in reference from the > function cpm_uart_allocbuf() to the function .init.text:__alloc_bootmem() > The function cpm_uart_allocbuf() references > the function __init __alloc_bootmem(). > This is often because cpm_uart_allocbuf lacks a __init > annotation or the annotation of __alloc_bootmem is wrong. > > > It seems that "drivers\serial\cpm_uart\cpm_uart_cpm2.c" needs to be patched. arg, the "\" heart my eyes!!! ;) > How to find the patch? Maybe do a git log on a recent kernel on this file (I have not checked the results) > How to search in the collection of prior postings to this mail list? Maybe try something like : http://www.google.com/#q=site%3Alists.ozlabs.org+cpm_uart_allocbuf (I have not checked the results) Cheers! Guillaume Knispel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
question about cpm_uart_cpm2.c "Section mismatch in reference from the function cpm_uart_allocbuf"
I am using MPC8272ADS_20080623-ltib.iso from freescale The Linux Kernel is 2.6.25. When I make uImage, the error message is : WARNING: vmlinux.o(.text+0x159450): Section mismatch in reference from the function cpm_uart_allocbuf() to the function .init.text:__alloc_bootmem() The function cpm_uart_allocbuf() references the function __init __alloc_bootmem(). This is often because cpm_uart_allocbuf lacks a __init annotation or the annotation of __alloc_bootmem is wrong. It seems that "drivers\serial\cpm_uart\cpm_uart_cpm2.c" needs to be patched. How to find the patch? How to search in the collection of prior postings to this mail list? I am a newbie. Thanks for help! 本电子邮件及附件都属机密文件，并且仅供标明地址的个人或团体使用。 如果本电子邮件与您无关，请删除全部原始信息（包括任何原始信息的备份），并通知发件人。 This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kexec-tools, ppc64: fix build error on ppc64
2010/5/5 Simon Horman > On Wed, May 05, 2010 at 01:35:21PM +1000, Michael Neuling wrote: > > > > > > In message <20100505023316.gf13...@verge.net.au> you wrote: > > > On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote: > > > > 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS > > > > improvements" broke pp64 as it turned on -Werror for all archs. > > > > > > > > This fixes the warning and hence ppc64 building. > > > > > > Thanks. > > > > > > While I'm very much in favour of using -Werror for testing > > > and these kind of patches are great, I think that -Werror > > > by default is rather silly. We can't control what will be > > > a warning in the future and sometimes fixing warnings isn't > > > appropriate - for instance there are warnings in fs2dt.c at > > > the moment, that is currently considered an upstream problem. > > > > > > In short, this patch is great. But I plan to also remove -Werror > > > as the default now that its been brought to my attention. > > > > Cool. My second patch should do this for all but MIPS. > > Unfortunately the second patch breaks make tarball. > For now I have committed the following: > > From 76beff0507360f3001e23c9b4c765ef56384d5d5 Mon Sep 17 00:00:00 2001 > From: Simon Horman > Date: Wed, 5 May 2010 13:33:21 +1000 > Subject: [PATCH] build: Don't modify CFLAGS in kexec/arch/mips/Makefile > > Revert this portion of recent MIPS changes as it actually effects the > CFLAGS for all architectures. Moreover I'm somewhat dubious about > defaulting to -Werror for any architecture. > > Signed-off-by: Simon Horman > --- > kexec/arch/mips/Makefile |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/kexec/arch/mips/Makefile b/kexec/arch/mips/Makefile > index 831b263..03bdb9a 100644 > --- a/kexec/arch/mips/Makefile > +++ b/kexec/arch/mips/Makefile > @@ -14,5 +14,3 @@ dist += kexec/arch/mips/Makefile $(mips_KEXEC_SRCS) > \ >kexec/arch/mips/kexec-mips.h\ >kexec/arch/mips/crashdump-mips.h\ >kexec/arch/mips/include/arch/options.h > - > -CFLAGS +=-Wall -Werror > -- > 1.7.1 > > Plan was to have -Werror only for mips. Thanks for fixes. -- Best regards, Maxim Uvarov ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/13] powerpc/476: add machine check handler for 47x core
On Wed, 2010-05-05 at 08:59 -0400, Josh Boyer wrote:
> On Wed, May 05, 2010 at 08:27:01AM -0400, Josh Boyer wrote:
> >>+int machine_check_47x(struct pt_regs *regs)
> >>+{
> >>+ unsigned long reason = get_mc_reason(regs);
> >>+ u32 mcsr;
> >>+
> >>+ printk(KERN_ERR "Machine check in kernel mode.\n");
> >>+ if (reason & ESR_IMCP) {
> >>+ printk(KERN_ERR
> >>+ "Instruction Synchronous Machine Check exception\n");
> >>+ mtspr(SPRN_ESR, reason & ~ESR_IMCP);
> >>+ return 0;
> >>+ }
> >>+ mcsr = mfspr(SPRN_MCSR);
> >>+ if (mcsr & MCSR_IB)
> >>+ printk(KERN_ERR "Instruction Read PLB Error\n");
> >>+ if (mcsr & MCSR_DRB)
> >>+ printk(KERN_ERR "Data Read PLB Error\n");
> >>+ if (mcsr & MCSR_DWB)
> >>+ printk(KERN_ERR "Data Write PLB Error\n");
> >>+ if (mcsr & MCSR_TLBP)
> >>+ printk(KERN_ERR "TLB Parity Error\n");
> >>+ if (mcsr & MCSR_ICP) {
> >>+ flush_instruction_cache();
> >>+ printk(KERN_ERR "I-Cache Parity Error\n");
> >>+ }
> >>+ if (mcsr & MCSR_DCSP)
> >>+ printk(KERN_ERR "D-Cache Search Parity Error\n");
> >>+ if (mcsr & PPC47x_MCSR_GPR)
> >>+ printk(KERN_ERR "GPR Parity Error\n");
> >>+ if (mcsr & PPC47x_MCSR_FPR)
> >>+ printk(KERN_ERR "FPR Parity Error\n");
> >>+ if (mcsr & PPC47x_MCSR_IPR)
> >>+ printk(KERN_ERR "Machine Check exception is imprecise\n");
> >
> >This function isn't guarded by CONFIG_PPC_47x, however the defines for
> >PPC47x_MCSR_* are in include/asm/reg_booke.h. They were added that way in
> >patch
> >4. As it stands, we get this when trying to build for plain 44x:
> >
> > CC arch/powerpc/kernel/traps.o
> >arch/powerpc/kernel/traps.c: In function 'machine_check_47x':
> >arch/powerpc/kernel/traps.c:411: error: 'PPC47x_MCSR_GPR' undeclared (first
> >use in this function)
> >arch/powerpc/kernel/traps.c:411: error: (Each undeclared identifier is
> >reported only once
> >arch/powerpc/kernel/traps.c:411: error: for each function it appears in.)
> >arch/powerpc/kernel/traps.c:413: error: 'PPC47x_MCSR_FPR' undeclared (first
> >use in this function)
> >arch/powerpc/kernel/traps.c:415: error: 'PPC47x_MCSR_IPR' undeclared (first
> >use in this function)
> >make[1]: *** [arch/powerpc/kernel/traps.o] Error 1
> >make: *** [arch/powerpc/kernel] Error 2
> >make: *** Waiting for unfinished jobs
> >
> >
> >We should probably guard this function behind CONFIG_PPC_47x, right? If so,
> >I
> >can fix that up locally quickly enough.
>
> Actually, that won't work unless we wrap the .machine_check addition in
> cputable
> as well. That looks ugly. I'm guessing the easiest and cleanest fix is to
> not guard the #defines for those regs in reg_booke.h. Anyone have problems
> with
> that?
I have no problems with that. Sorry for not being diligent and building
these patches with other configs.
Thanks,
Shaggy
--
Dave Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/13] powerpc/476: add machine check handler for 47x core
On Wed, May 05, 2010 at 08:27:01AM -0400, Josh Boyer wrote:
>>+int machine_check_47x(struct pt_regs *regs)
>>+{
>>+ unsigned long reason = get_mc_reason(regs);
>>+ u32 mcsr;
>>+
>>+ printk(KERN_ERR "Machine check in kernel mode.\n");
>>+ if (reason & ESR_IMCP) {
>>+ printk(KERN_ERR
>>+"Instruction Synchronous Machine Check exception\n");
>>+ mtspr(SPRN_ESR, reason & ~ESR_IMCP);
>>+ return 0;
>>+ }
>>+ mcsr = mfspr(SPRN_MCSR);
>>+ if (mcsr & MCSR_IB)
>>+ printk(KERN_ERR "Instruction Read PLB Error\n");
>>+ if (mcsr & MCSR_DRB)
>>+ printk(KERN_ERR "Data Read PLB Error\n");
>>+ if (mcsr & MCSR_DWB)
>>+ printk(KERN_ERR "Data Write PLB Error\n");
>>+ if (mcsr & MCSR_TLBP)
>>+ printk(KERN_ERR "TLB Parity Error\n");
>>+ if (mcsr & MCSR_ICP) {
>>+ flush_instruction_cache();
>>+ printk(KERN_ERR "I-Cache Parity Error\n");
>>+ }
>>+ if (mcsr & MCSR_DCSP)
>>+ printk(KERN_ERR "D-Cache Search Parity Error\n");
>>+ if (mcsr & PPC47x_MCSR_GPR)
>>+ printk(KERN_ERR "GPR Parity Error\n");
>>+ if (mcsr & PPC47x_MCSR_FPR)
>>+ printk(KERN_ERR "FPR Parity Error\n");
>>+ if (mcsr & PPC47x_MCSR_IPR)
>>+ printk(KERN_ERR "Machine Check exception is imprecise\n");
>
>This function isn't guarded by CONFIG_PPC_47x, however the defines for
>PPC47x_MCSR_* are in include/asm/reg_booke.h. They were added that way in
>patch
>4. As it stands, we get this when trying to build for plain 44x:
>
> CC arch/powerpc/kernel/traps.o
>arch/powerpc/kernel/traps.c: In function 'machine_check_47x':
>arch/powerpc/kernel/traps.c:411: error: 'PPC47x_MCSR_GPR' undeclared (first
>use in this function)
>arch/powerpc/kernel/traps.c:411: error: (Each undeclared identifier is
>reported only once
>arch/powerpc/kernel/traps.c:411: error: for each function it appears in.)
>arch/powerpc/kernel/traps.c:413: error: 'PPC47x_MCSR_FPR' undeclared (first
>use in this function)
>arch/powerpc/kernel/traps.c:415: error: 'PPC47x_MCSR_IPR' undeclared (first
>use in this function)
>make[1]: *** [arch/powerpc/kernel/traps.o] Error 1
>make: *** [arch/powerpc/kernel] Error 2
>make: *** Waiting for unfinished jobs
>
>
>We should probably guard this function behind CONFIG_PPC_47x, right? If so, I
>can fix that up locally quickly enough.
Actually, that won't work unless we wrap the .machine_check addition in cputable
as well. That looks ugly. I'm guessing the easiest and cleanest fix is to
not guard the #defines for those regs in reg_booke.h. Anyone have problems with
that?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] serial: mpc52xx_uart: fix null pointer dereference
On Tue, May 4, 2010 at 7:18 PM, Anatolij Gustschin wrote:
> Commit 6acc6833510db8f72b5ef343296d97480555fda9
> introduced NULL pointer dereference and kernel crash
> on ppc32 machines while booting. Fix this bug now.
>
> Reported-by: Leonardo Chiquitto
> Signed-off-by: Anatolij Gustschin
> ---
> drivers/serial/mpc52xx_uart.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
> index a176ab4..02469c3 100644
> --- a/drivers/serial/mpc52xx_uart.c
> +++ b/drivers/serial/mpc52xx_uart.c
> @@ -1467,7 +1467,7 @@ mpc52xx_uart_init(void)
> /*
> * Map the PSC FIFO Controller and init if on MPC512x.
> */
> - if (psc_ops->fifoc_init) {
> + if (psc_ops && psc_ops->fifoc_init) {
> ret = psc_ops->fifoc_init();
> if (ret)
> return ret;
> --
> 1.7.0.4
Thanks for the quick fix, Anatolij. I just tested it and confirm it resolves
the problem.
Leonardo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
On Wed, May 05, 2010 at 06:39:01AM -0500, Timur Tabi wrote: > On Wed, May 5, 2010 at 6:22 AM, Mark Brown > > Just looking at the scheduling here with regard to the merge window and > > the fact that this doesn't seem to hurt the existing drivers perhaps it > > makes sense to merge this via the PowerPC tree immediately? > Aren't we a little late in the cycle for a patch that doesn't do anything? It seems to be safe enough for -next. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 04/13] powerpc/476: add machine check handler for 47x core
On Fri, Mar 05, 2010 at 06:43:18AM -0700, Dave Kleikamp wrote:
>powerpc/476: add machine check handler for 47x core
>
>From: Dave Kleikamp
>
>The 47x core's MCSR varies from 44x, so it needs it's own machine check
>handler.
>
>Signed-off-by: Dave Kleikamp
>---
>
> arch/powerpc/include/asm/cputable.h |1 +
> arch/powerpc/kernel/cputable.c |1 +
> arch/powerpc/kernel/traps.c | 40 +++
> 3 files changed, 42 insertions(+), 0 deletions(-)
>
>
>diff --git a/arch/powerpc/include/asm/cputable.h
>b/arch/powerpc/include/asm/cputable.h
>index 75b774e..9fff628 100644
>--- a/arch/powerpc/include/asm/cputable.h
>+++ b/arch/powerpc/include/asm/cputable.h
>@@ -72,6 +72,7 @@ extern int machine_check_4xx(struct pt_regs *regs);
> extern int machine_check_440A(struct pt_regs *regs);
> extern int machine_check_e500(struct pt_regs *regs);
> extern int machine_check_e200(struct pt_regs *regs);
>+extern int machine_check_47x(struct pt_regs *regs);
>
> /* NOTE WELL: Update identify_cpu() if fields are added or removed! */
> struct cpu_spec {
>diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
>index 338ac47..7b2a67c 100644
>--- a/arch/powerpc/kernel/cputable.c
>+++ b/arch/powerpc/kernel/cputable.c
>@@ -1712,6 +1712,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
> MMU_FTR_USE_TLBIVAX_BCAST | MMU_FTR_LOCK_BCAST_INVAL,
> .icache_bsize = 32,
> .dcache_bsize = 128,
>+ .machine_check = machine_check_47x,
> .platform = "ppc470",
> },
> { /* default match */
>diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
>index d069ff8..21ed77b 100644
>--- a/arch/powerpc/kernel/traps.c
>+++ b/arch/powerpc/kernel/traps.c
>@@ -376,6 +376,46 @@ int machine_check_440A(struct pt_regs *regs)
> }
> return 0;
> }
>+
>+int machine_check_47x(struct pt_regs *regs)
>+{
>+ unsigned long reason = get_mc_reason(regs);
>+ u32 mcsr;
>+
>+ printk(KERN_ERR "Machine check in kernel mode.\n");
>+ if (reason & ESR_IMCP) {
>+ printk(KERN_ERR
>+ "Instruction Synchronous Machine Check exception\n");
>+ mtspr(SPRN_ESR, reason & ~ESR_IMCP);
>+ return 0;
>+ }
>+ mcsr = mfspr(SPRN_MCSR);
>+ if (mcsr & MCSR_IB)
>+ printk(KERN_ERR "Instruction Read PLB Error\n");
>+ if (mcsr & MCSR_DRB)
>+ printk(KERN_ERR "Data Read PLB Error\n");
>+ if (mcsr & MCSR_DWB)
>+ printk(KERN_ERR "Data Write PLB Error\n");
>+ if (mcsr & MCSR_TLBP)
>+ printk(KERN_ERR "TLB Parity Error\n");
>+ if (mcsr & MCSR_ICP) {
>+ flush_instruction_cache();
>+ printk(KERN_ERR "I-Cache Parity Error\n");
>+ }
>+ if (mcsr & MCSR_DCSP)
>+ printk(KERN_ERR "D-Cache Search Parity Error\n");
>+ if (mcsr & PPC47x_MCSR_GPR)
>+ printk(KERN_ERR "GPR Parity Error\n");
>+ if (mcsr & PPC47x_MCSR_FPR)
>+ printk(KERN_ERR "FPR Parity Error\n");
>+ if (mcsr & PPC47x_MCSR_IPR)
>+ printk(KERN_ERR "Machine Check exception is imprecise\n");
This function isn't guarded by CONFIG_PPC_47x, however the defines for
PPC47x_MCSR_* are in include/asm/reg_booke.h. They were added that way in patch
4. As it stands, we get this when trying to build for plain 44x:
CC arch/powerpc/kernel/traps.o
arch/powerpc/kernel/traps.c: In function 'machine_check_47x':
arch/powerpc/kernel/traps.c:411: error: 'PPC47x_MCSR_GPR' undeclared (first use
in this function)
arch/powerpc/kernel/traps.c:411: error: (Each undeclared identifier is reported
only once
arch/powerpc/kernel/traps.c:411: error: for each function it appears in.)
arch/powerpc/kernel/traps.c:413: error: 'PPC47x_MCSR_FPR' undeclared (first use
in this function)
arch/powerpc/kernel/traps.c:415: error: 'PPC47x_MCSR_IPR' undeclared (first use
in this function)
make[1]: *** [arch/powerpc/kernel/traps.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
make: *** Waiting for unfinished jobs
We should probably guard this function behind CONFIG_PPC_47x, right? If so, I
can fix that up locally quickly enough.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Page fault on vmalloc'ed memory
On Wed, May 5, 2010 at 12:19 AM, Li Yang-R58472 wrote: > I got a weird page fault oops on vmalloc'ed area. Digging into the powerpc > do_page_fault(), I found there is no handling of address in kernel space > unlike the x86 counter part. Does any one know how we deal with the > vmalloc'ed area on powerpc? Thanks a lot. Can you be more specific? Post the oops message, and tell us the specific x86 code that you think is missing. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
On Wed, May 5, 2010 at 6:22 AM, Mark Brown wrote: > Just looking at the scheduling here with regard to the merge window and > the fact that this doesn't seem to hurt the existing drivers perhaps it > makes sense to merge this via the PowerPC tree immediately? Aren't we a little late in the cycle for a patch that doesn't do anything? I was expecting this patch to go into Liam's tree. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/8610: add probing for individual DMA channels, not just DMA controllers
On Tue, May 04, 2010 at 12:20:13PM -0500, Kumar Gala wrote: > On May 3, 2010, at 4:54 PM, Timur Tabi wrote: > > A future version of the MPC8610 HPCD's ASoC DMA driver will probe on > > individual > > DMA channel nodes, so the DMA controller nodes' compatible string must be > > listed > > in mpc8610_ids[] for the probe to work. > > > > Also remove the "gianfar" compatible from mpc8610_ids[], since there is no > > gianfar (or any other networking device) on the 8610. > > > > Signed-off-by: Timur Tabi > Acked-by: Kumar Gala Just looking at the scheduling here with regard to the merge window and the fact that this doesn't seem to hurt the existing drivers perhaps it makes sense to merge this via the PowerPC tree immediately? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Kernel errors at very early stage
Hi all- we've built a custom board with a FSL MPC8568EMDS CPU. U-Boot works so far - at least it is able to load a Linux kernel and a flattened device tree via network and launch the kernel. I get no output on the serial console from the kernel, so my only chance is to read out the __log_buf while in memory with my Abatron BDI 3000 debugger. The thing is, I cannot break into the code really, because it never stops reliable at my break points... :-( Can anyone of you see a usual suspect in the attached log? Is there something wrong with the timing, maybe? Maybe a hardware issue? How can I check this? Cheers Matthias kernel-log.008 Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kexec-tools, ppc64: fix build error on ppc64
On Wed, May 05, 2010 at 11:46:25AM +0400, Maxim Uvarov wrote: > 2010/5/5 Simon Horman > > > On Wed, May 05, 2010 at 01:35:21PM +1000, Michael Neuling wrote: > > > > > > > > > In message <20100505023316.gf13...@verge.net.au> you wrote: > > > > On Wed, May 05, 2010 at 11:48:53AM +1000, Michael Neuling wrote: > > > > > 6adc05c6e3fdbc8b9f5d915af78ca05d0a09cb17 "some kexec MIPS > > > > > improvements" broke pp64 as it turned on -Werror for all archs. > > > > > > > > > > This fixes the warning and hence ppc64 building. > > > > > > > > Thanks. > > > > > > > > While I'm very much in favour of using -Werror for testing > > > > and these kind of patches are great, I think that -Werror > > > > by default is rather silly. We can't control what will be > > > > a warning in the future and sometimes fixing warnings isn't > > > > appropriate - for instance there are warnings in fs2dt.c at > > > > the moment, that is currently considered an upstream problem. > > > > > > > > In short, this patch is great. But I plan to also remove -Werror > > > > as the default now that its been brought to my attention. > > > > > > Cool. My second patch should do this for all but MIPS. > > > > Unfortunately the second patch breaks make tarball. > > For now I have committed the following: > > > > From 76beff0507360f3001e23c9b4c765ef56384d5d5 Mon Sep 17 00:00:00 2001 > > From: Simon Horman > > Date: Wed, 5 May 2010 13:33:21 +1000 > > Subject: [PATCH] build: Don't modify CFLAGS in kexec/arch/mips/Makefile > > > > Revert this portion of recent MIPS changes as it actually effects the > > CFLAGS for all architectures. Moreover I'm somewhat dubious about > > defaulting to -Werror for any architecture. > > > > Signed-off-by: Simon Horman > > --- > > kexec/arch/mips/Makefile |2 -- > > 1 files changed, 0 insertions(+), 2 deletions(-) > > > > diff --git a/kexec/arch/mips/Makefile b/kexec/arch/mips/Makefile > > index 831b263..03bdb9a 100644 > > --- a/kexec/arch/mips/Makefile > > +++ b/kexec/arch/mips/Makefile > > @@ -14,5 +14,3 @@ dist += kexec/arch/mips/Makefile $(mips_KEXEC_SRCS) > > \ > >kexec/arch/mips/kexec-mips.h\ > >kexec/arch/mips/crashdump-mips.h\ > >kexec/arch/mips/include/arch/options.h > > - > > -CFLAGS +=-Wall -Werror > > -- > > 1.7.1 > > > > > Plan was to have -Werror only for mips. Thanks for fixes. No problem, I should have noticed this earlier. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
