linux-next: origin tree build failure
Hi all, Today's linux-next build (powerpc64, gcc 4.1.3) failed like this: drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a section type conflict Caused by commit ae52bb2384f721562f15f719de1acb8e934733cb (fbdev: move logo externs to header file) but probably really a compiler bug as gcc 4.3 and 4.4 do not get this error. I have reverted that commit for today, but we really need some workaround as gcc 4.1.3 is not uncommon. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgp7BCbJXPkKh.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
comment :
This feature is needed on our home made board to program an onboard
fpga.
The fpga needs some special pin toggling to put it in programming mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index 0fd0ec4..3a367ce 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -666,9 +666,12 @@ static void mpc8xxx_spi_cs_control(struct spi_device *spi,
bool on)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev-platform_data);
u16 cs = spi-chip_select;
int gpio = pinfo-gpios[cs];
- bool alow = pinfo-alow_flags[cs];
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo-alow_flags[cs];
+
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +710,31 @@ static int of_mpc8xxx_spi_get_chipselects(struct device
*dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, can't request gpio #%d: %d\n,
+i, ret);
+ goto err_loop;
+ }
+
+ pinfo-gpios[i] = gpio;
+ pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo-gpios[i],
+ pinfo-alow_flags[i]);
+ if (ret) {
+ dev_err(dev, can't set output direction for
+ gpio #%d: %d\n,
+ i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo-gpios[i] = -EEXIST;
+ } else {
dev_err(dev, invalid gpio #%d: %d\n, i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, can't request gpio #%d: %d\n, i, ret);
- goto err_loop;
- }
-
- pinfo-gpios[i] = gpio;
- pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo-gpios[i],
- pinfo-alow_flags[i]);
- if (ret) {
- dev_err(dev, can't set output direction for gpio
- #%d: %d\n, i, ret);
- goto err_loop;
- }
}
pdata-max_chipselect = ngpios;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
On Jun 19, 2009, at 2:26 AM, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
comment :
This feature is needed on our home made board to program an onboard
fpga.
The fpga needs some special pin toggling to put it in programming
mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
Which FSL chip are you using?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add irqtrace support for 32-bit powerpc (v2)
On Jun 17, 2009, at 10:43 PM, Benjamin Herrenschmidt wrote: Based on initial work from: Dale Farnsworth d...@farnsworth.org Add the low level irq tracing hooks for 32-bit powerpc needed to enable full lockdep functionality. The approach taken to deal with the code in entry_32.S is that we don't trace all the transitions of MSR:EE when we just turn it off to peek at TI_FLAGS without races. Only when we are calling into C code or returning from exceptions with a state that have changed from what lockdep thinks. There's a little bugger though: If we take an exception that keeps interrupts enabled (such as an alignment exception) while interrupts are enabled, we will call trace_hardirqs_on() on the way back spurriously. Not a big deal, but to get rid of it would require remembering in pt_regs that the exception was one of the type that kept interrupts enabled which we don't know at this stage. (Well, we could test all cases for regs-trap but that sucks too much). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- This one fixes a bug, trace_hardirqs_on was too late in the restore: code path and would clobber things. This boots fine now on a PowerBook. Tested-by: Kumar Gala ga...@kernel.crashing.org on SMP e500 based system (8572) - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix mpic alloc warning
Since we can use kmalloc earlier we are getting the following since the mpic_alloc() code calls alloc_bootmem(). Move to using kzalloc() to remove the warning. [ cut here ] Badness at c0583248 [verbose debug info unavailable] NIP: c0583248 LR: c0583210 CTR: 0004 REGS: c0741de0 TRAP: 0700 Not tainted (2.6.30-06736-g12a31df) MSR: 00021000 ME,CE CR: 22024024 XER: TASK = c070d3b8[0] 'swapper' THREAD: c074 CPU: 0 6GPR00: 0001 c0741e90 c070d3b8 0001 0210 0020 3fff 6GPR08: c0c85700 c04f8c40 002d 22044022 1004a388 7ffd9400 6GPR16: 7ffcd100 7ffcd100 7ffcd100 c04f8c40 c059f62c c075a0c0 6GPR24: c059f648 000f 0210 0020 3fff 0210 NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80 LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80 Call Trace: [c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable) [c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108 [c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50 [c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710 [c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8 [c0741f90] [c057633c] init_IRQ+0x24/0x34 [c0741fa0] [c05738b8] start_kernel+0x260/0x3dc [c0741ff0] [c3c8] skpinv+0x2e0/0x31c Instruction dump: 409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8 39295700 80090004 7c34 5400d97e 0f00 2f80 409e001c 3880 Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/sysdev/mpic.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c index 9c3af50..9e81157 100644 --- a/arch/powerpc/sysdev/mpic.c +++ b/arch/powerpc/sysdev/mpic.c @@ -1052,11 +1052,10 @@ struct mpic * __init mpic_alloc(struct device_node *node, int intvec_top; u64 paddr = phys_addr; - mpic = alloc_bootmem(sizeof(struct mpic)); + mpic = kzalloc(sizeof(struct mpic), GFP_NOWAIT); if (mpic == NULL) return NULL; - - memset(mpic, 0, sizeof(struct mpic)); + mpic-name = name; mpic-hc_irq = mpic_irq_chip; -- 1.6.0.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
Ingo Molnar writes: Note, i left out this bit from the commit - we need to find a better solution than to allow ugly warnings on PowerPC. Could we use the kernel's u64 type directly perhaps? That would allow us to change all __u64 to u64 in all of tools/perf/ which is a nice clean-up in any case. This is userspace, we can use u64 however we like. :) I'll cook up a patch to add typedef unsigned long long u64 and change __u64 to u64. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of_serial: Add UPF_FIXED_TYPE flag
On Tue, 2009-06-09 at 18:39 -0500, Dave Mitchell wrote: This patch adds the UPF_FIXED_TYPE flag which will bypass the 8250's autoconfig probe for uart type. The uart type identified by the of_serial's parse of the flat device tree will be utilized as defined. Signed-off-by: Dave Mitchell dmitch...@amcc.com --- drivers/serial/of_serial.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c index 14f8fa9..3f2027c 100644 --- a/drivers/serial/of_serial.c +++ b/drivers/serial/of_serial.c @@ -67,7 +67,7 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, port-type = type; port-uartclk = *clk; port-flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP - | UPF_FIXED_PORT; + | UPF_FIXED_PORT | UPF_FIXED_TYPE; I think we /probably/ want a similar change in legacy_serial.c, for soc ports at least. Or do people have things that are compatible ns16550 but aren't? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix output from show_regs
For some reason we've had an explicit KERN_INFO for GPR dumps. With
recent changes we get output like:
6GPR00: ef855eb0 ef858000 0001 00d0 f100 ffbc8000
The KERN_INFO is causing the 6. Don't see any reason to keep it
around.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/kernel/process.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3e7135b..892a9f2 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -528,7 +528,7 @@ void show_regs(struct pt_regs * regs)
for (i = 0; i 32; i++) {
if ((i % REGS_PER_LINE) == 0)
- printk(\n KERN_INFO GPR%02d: , i);
+ printk(\nGPR%02d: , i);
printk(REG , regs-gpr[i]);
if (i == LAST_VOLATILE !FULL_REGS(regs))
break;
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: killing use of ppc_md.init
Original-Nachricht Datum: Thu, 18 Jun 2009 09:38:50 -0500 Von: Kumar Gala ga...@kernel.crashing.org An: Gerhard Pircher gerhard_pirc...@gmx.net, Benjamin Herrenschmidt b...@kernel.crashing.org CC: linuxppc-dev list linuxppc-...@ozlabs.org Betreff: killing use of ppc_md.init ppc_md.init only exists on ppc32 and seems like its pretty useless today. The users seem to fall into two classes: 1. called to do of_platform_bus_probe() - most platforms use machine_device_initcall() for this 2. some platform init code which seems like it could move into setup_arch(). The second one seems to only be on amigaone and chrp. Anyone know if there is any harm in moving the amigaone_init() into amigaone_setup_arch() and similarly on chrp chrp_init2() into chrp_setup_arch(). I guess converting amigaone_init() to a machine_device_initcall() is the easiest approach. I'll send a patch soon. Gerhard -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Fix issue found by lockdep trace in smp_85xx_kick_cpu
lockdep trace found the following:
[ cut here ]
Badness at c007baf0 [verbose debug info unavailable]
NIP: c007baf0 LR: c007bad8 CTR:
REGS: ef855e00 TRAP: 0700 Tainted: GW
(2.6.30-06736-g12a31df-dirty)
MSR: 00021000 ME,CE CR: 24044022 XER: 2000
TASK = ef858000[1] 'swapper' THREAD: ef854000 CPU: 0
GPR00: ef855eb0 ef858000 0001 00d0 f100 ffbc8000
GPR08: 00d0 c076 c071 0007 2fff 1004a388 7ffd9400
GPR16: 7ffcd100 7ffcd100 7ffcd100 c059cd78 c075c498 c057da7c
GPR24: ffbc8000 f100 0001 c00bf8b0 c07595d4 00d0 00021000 00d0
NIP [c007baf0] lockdep_trace_alloc+0xc0/0xf0
LR [c007bad8] lockdep_trace_alloc+0xa8/0xf0
Call Trace:
[ef855eb0] [c007ba60] lockdep_trace_alloc+0x30/0xf0 (unreliable)
[ef855ec0] [c00cb3ac] kmem_cache_alloc+0x2c/0xf0
[ef855ee0] [c00bf8b0] __get_vm_area_node+0x80/0x1c0
[ef855f10] [c0017580] __ioremap_caller+0x1d0/0x1e0
[ef855f40] [c057da7c] smp_85xx_kick_cpu+0x64/0x124
[ef855f60] [c0599180] __cpu_up+0xd0/0x1a4
[ef855f80] [c05997c4] cpu_up+0x14c/0x1e0
[ef855fc0] [c05732a0] kernel_init+0x100/0x1c4
[ef855ff0] [c0011524] kernel_thread+0x4c/0x68
Instruction dump:
8009c174 2f80 409e0048 73c08000 40820040 4818980d 2f83 419effa0
3d20c076 8009c388 2f80 409eff90 0fe0 4b88 6000 6000
We were calling ioremap after we local_irq_restore(flags). A simple
reorder fixes the problem.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/85xx/smp.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index cc0b0db..62c592e 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -52,20 +52,19 @@ smp_85xx_kick_cpu(int nr)
pr_debug(smp_85xx_kick_cpu: kick CPU #%d\n, nr);
- local_irq_save(flags);
-
np = of_get_cpu_node(nr, NULL);
cpu_rel_addr = of_get_property(np, cpu-release-addr, NULL);
if (cpu_rel_addr == NULL) {
printk(KERN_ERR No cpu-release-addr for cpu %d\n, nr);
- local_irq_restore(flags);
return;
}
/* Map the spin table */
bptr_vaddr = ioremap(*cpu_rel_addr, SIZE_BOOT_ENTRY);
+ local_irq_save(flags);
+
out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
@@ -73,10 +72,10 @@ smp_85xx_kick_cpu(int nr)
while ((__secondary_hold_acknowledge != nr) (++n 1000))
mdelay(1);
- iounmap(bptr_vaddr);
-
local_irq_restore(flags);
+ iounmap(bptr_vaddr);
+
pr_debug(waited %d msecs for CPU #%d.\n, n, nr);
}
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pmac: Fix issues with PowerMac PowerSurge SMP
The old PowerSurge SMP (ie, dual or quad 604 machines) code has
numerous issues in modern world.
One is cpu_possible_map is set too late (the device-tree is bogus)
so we fail to allocate the interrupt stacks and crash. Another
problem is the fact the timebase is frozen by the bringup of the
second CPU so the delays in the generic code will hang, we need
to move some of the calling procedure to inside the powermac code.
This makes it boot again for me
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/smp.c |3
arch/powerpc/platforms/powermac/setup.c | 41 +--
arch/powerpc/platforms/powermac/smp.c | 166 +++-
3 files changed, 112 insertions(+), 98 deletions(-)
--- linux-work.orig/arch/powerpc/platforms/powermac/setup.c 2009-06-19
17:11:28.0 +1000
+++ linux-work/arch/powerpc/platforms/powermac/setup.c 2009-06-19
17:12:28.0 +1000
@@ -103,11 +103,6 @@ unsigned long smu_cmdbuf_abs;
EXPORT_SYMBOL(smu_cmdbuf_abs);
#endif
-#ifdef CONFIG_SMP
-extern struct smp_ops_t psurge_smp_ops;
-extern struct smp_ops_t core99_smp_ops;
-#endif /* CONFIG_SMP */
-
static void pmac_show_cpuinfo(struct seq_file *m)
{
struct device_node *np;
@@ -341,34 +336,6 @@ static void __init pmac_setup_arch(void)
ROOT_DEV = DEFAULT_ROOT_DEVICE;
#endif
-#ifdef CONFIG_SMP
- /* Check for Core99 */
- ic = of_find_node_by_name(NULL, uni-n);
- if (!ic)
- ic = of_find_node_by_name(NULL, u3);
- if (!ic)
- ic = of_find_node_by_name(NULL, u4);
- if (ic) {
- of_node_put(ic);
- smp_ops = core99_smp_ops;
- }
-#ifdef CONFIG_PPC32
- else {
- /*
-* We have to set bits in cpu_possible_map here since the
-* secondary CPU(s) aren't in the device tree, and
-* setup_per_cpu_areas only allocates per-cpu data for
-* CPUs in the cpu_possible_map.
-*/
- int cpu;
-
- for (cpu = 1; cpu 4 cpu NR_CPUS; ++cpu)
- cpu_set(cpu, cpu_possible_map);
- smp_ops = psurge_smp_ops;
- }
-#endif
-#endif /* CONFIG_SMP */
-
#ifdef CONFIG_ADB
if (strstr(cmd_line, adb_sync)) {
extern int __adb_probe_sync;
@@ -512,6 +479,14 @@ static void __init pmac_init_early(void)
#ifdef CONFIG_PPC64
iommu_init_early_dart();
#endif
+
+ /* SMP Init has to be done early as we need to patch up
+* cpu_possible_map before interrupt stacks are allocated
+* or kaboom...
+*/
+#ifdef CONFIG_SMP
+ pmac_setup_smp();
+#endif
}
static int __init pmac_declare_of_platform_devices(void)
Index: linux-work/arch/powerpc/platforms/powermac/smp.c
===
--- linux-work.orig/arch/powerpc/platforms/powermac/smp.c 2009-06-19
17:11:28.0 +1000
+++ linux-work/arch/powerpc/platforms/powermac/smp.c2009-06-19
19:27:33.0 +1000
@@ -64,10 +64,11 @@
extern void __secondary_start_pmac_0(void);
extern int pmac_pfunc_base_install(void);
-#ifdef CONFIG_PPC32
+static void (*pmac_tb_freeze)(int freeze);
+static u64 timebase;
+static int tb_req;
-/* Sync flag for HW tb sync */
-static volatile int sec_tb_reset = 0;
+#ifdef CONFIG_PPC32
/*
* Powersurge (old powermac SMP) support.
@@ -294,6 +295,9 @@ static int __init smp_psurge_probe(void)
psurge_quad_init();
/* All released cards using this HW design have 4 CPUs */
ncpus = 4;
+ /* No sure how timebase sync works on those, let's use SW */
+ smp_ops-give_timebase = smp_generic_give_timebase;
+ smp_ops-take_timebase = smp_generic_take_timebase;
} else {
iounmap(quad_base);
if ((in_8(hhead_base + HHEAD_CONFIG) 0x02) == 0) {
@@ -308,18 +312,15 @@ static int __init smp_psurge_probe(void)
psurge_start = ioremap(PSURGE_START, 4);
psurge_pri_intr = ioremap(PSURGE_PRI_INTR, 4);
- /*
-* This is necessary because OF doesn't know about the
+ /* This is necessary because OF doesn't know about the
* secondary cpu(s), and thus there aren't nodes in the
* device tree for them, and smp_setup_cpu_maps hasn't
-* set their bits in cpu_possible_map and cpu_present_map.
+* set their bits in cpu_present_map.
*/
if (ncpus NR_CPUS)
ncpus = NR_CPUS;
- for (i = 1; i ncpus ; ++i) {
+ for (i = 1; i ncpus ; ++i)
cpu_set(i, cpu_present_map);
- set_hard_smp_processor_id(i, i);
- }
if (ppc_md.progress) ppc_md.progress(smp_psurge_probe - done, 0x352);
@@ -329,8 +330,14 @@ static int __init smp_psurge_probe(void)
static void __init
Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
On Jun 19, 2009, at 2:26 AM, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
comment :
This feature is needed on our home made board to program an
onboard fpga.
The fpga needs some special pin toggling to put it in programming
mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
Which FSL chip are you using?
We use the MPC8377E
Rini
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Rini van Zetten
Senior Software Engineer
-
ARVOO Engineering B.V.
Tasveld 13
3417 XS Montfoort
The Netherlands
E-mail : mailto:r...@arvoo.com Rini van Zetten
Web : www.arvoo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
Hello, On Thu, Jun 18, 2009 at 4:04 PM, Kumar Galaga...@kernel.crashing.org wrote: On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote: On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote: This patch adds the possibility to have a spi device without a cs. That is a good question. What HW is this for (I don't think its for eSPI but I could be wrong). We need SPI without CS too on our MPC8313E design. In our case having a CS line to each slave (18 of them) is too expensive and we use a chip select which piggy backs on another signal. Once the slave is selected, SPI is used to send large amounts of data. Regards, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
kilauea/405ex external interrupts
Hi,
I'm writing a linux driver that uses an external interrupt (ppc 405ex). I'm
using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of the
virtual interrupt stuff, so I added a new node to my device tree in order to
get proper virtual IRQ number. This node describes an external event and its
connection to UIC via the mentioned ext. int. Here is a sample of the
divce-tree:
...
UIC1: interrupt-controller1 {
compatible = ibm,uic-405ex,ibm,uic;
interrupt-controller;
cell-index = 1;
dcr-reg = 0x0d0 0x009;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
interrupt-parent = UIC0;
};
EXTEVENT: external_event {
device_type = external;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x1;
interrupt-parent = UIC1;
};
...
Then I use function irq_of_parse_and_map() which returns the virtual IRQ
number 22. So, request_irq() seems to be satisfied with this number. I can
see this interrupt in the /proc/interrupts. But! When I connect a signal
source to the pin 30, nothing happens - the interrupt service routine isn't
called.
Am I suppose to configure anything else? (e. g. pin multiplexing, further
device-tree tuning...) Thank you!
Best regards,
Ladi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
On Fri, Jun 19, 2009 at 01:45:46PM +0200, Leon Woestenberg wrote:
Hello,
On Thu, Jun 18, 2009 at 4:04 PM, Kumar Galaga...@kernel.crashing.org wrote:
On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote:
On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
That is a good question. What HW is this for (I don't think its for eSPI
but I could be wrong).
We need SPI without CS too on our MPC8313E design.
We do support SPI without CS, but only for one slave device. If
there is no CS, technically you can address only one device on a
SPI bus.
And apparently Rini's case is not for addressing multiple chips
w/o CS lines, it's just some chip-selects need quirks.
In our case having a CS line to each slave (18 of them) is too
expensive and we use a chip select which piggy backs on another
signal.
Once the slave is selected, SPI is used to send large amounts of data.
Can you describe it a little bit more? Have you patched the SPI
driver to work with your setup?
If you can address 18 slaves w/o chip-select line, I quess
you have a CS demuxing bridge somewhere, i.e.
spi-controller {
/*
* no chip-selects from the controller, it can only talk to
* one device: the cs demuxing bridge, it is always selected.
*/
spi-cs-demuxing-bridge {
/*
* knows how to manage chip-selects (or demux
* one chip select line for several slaves)
*/
spi-slave {
reg = 0;
};
...
spi-slave {
reg = 17;
};
};
};
Surely we can hide the bridge into the SPI controller driver,
but I think it would be beneficial to factor-out it to a
stand-alone entity, so that other SPI controllers could work
with this setup without any modifications (oh and btw, we could
also create a bridge called gpio-chipselects-bridge, and
factor out all GPIO stuff from the drivers).
There are two options of how we can factor out chip-select
machines... the bad and the ugly. :-) No, the first one is bad,
but the second should be OK.
1. We can create full-fledged SPI master bridge drivers, the
drivers will just pass-through all SPI IO, but will manage
chip-selects. The bad part is that these drivers could degrade
performance since they'll have to manage SPI IO, which is
unneeded for the pure CS machines.
2. Another option (which I like more), is to create SPI chip-
select machine driver framework, so we could (finally)
separate two SPI entities: SPI IO and SPI chip-select machine.
CS machines of different flavours: GPIO, built-in, and
board-specific (!) with a lot of demuxing magic.
(1) can be implemented trivially, while (2) is a lot of work.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
On Fri, Jun 19, 2009 at 09:26:08AM +0200, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
comment :
This feature is needed on our home made board to program an onboard
fpga.
The fpga needs some special pin toggling to put it in programming mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
Cool, thanks for the explanation. You may want to put it
into the commit message.
[...]
+ ret = gpio_direction_output(pinfo-gpios[i],
+ pinfo-alow_flags[i]);
+ if (ret) {
+ dev_err(dev, can't set output direction for
+ gpio #%d: %d\n,
+ i, ret);
There is no space between 'for' and 'gpio' words.
(also the whole dev_err() may fit into two lines, no need to
split it into three lines).
Otherwise looks great. On the next resend feel free to add my
Acked-by: Anton Vorontsov avoront...@ru.mvista.com
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm v4][POWERPC] mpc8xxx : allow SPI without cs.
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
This feature is needed on our home made board to program an onboard fpga.
The fpga needs some special pin toggling to put it in programming mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
Signed-off-by: Rini van Zetten r...@arvoo.nl
Acked-by: Anton Vorontsov avoront...@ru.mvista.com
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
v4 :
missing space in error text added
splitted lines combined
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index 0fd0ec4..de95790 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -666,9 +666,12 @@ static void mpc8xxx_spi_cs_control(struct spi_device *spi,
bool on)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev-platform_data);
u16 cs = spi-chip_select;
int gpio = pinfo-gpios[cs];
- bool alow = pinfo-alow_flags[cs];
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo-alow_flags[cs];
+
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -678,7 +681,7 @@ static int of_mpc8xxx_spi_get_chipselects(struct device
*dev)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(pdata);
unsigned int ngpios;
int i = 0;
- int ret;
+ int ret = 0;
ngpios = of_gpio_count(np);
if (!ngpios) {
@@ -707,27 +710,30 @@ static int of_mpc8xxx_spi_get_chipselects(struct device
*dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, can't request gpio #%d: %d\n,
+i, ret);
+ goto err_loop;
+ }
+
+ pinfo-gpios[i] = gpio;
+ pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo-gpios[i],
+ pinfo-alow_flags[i]);
+ if (ret) {
+ dev_err(dev, can't set output direction for
+ gpio #%d: %d\n, i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo-gpios[i] = -EEXIST;
+ } else {
dev_err(dev, invalid gpio #%d: %d\n, i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, can't request gpio #%d: %d\n, i, ret);
- goto err_loop;
- }
-
- pinfo-gpios[i] = gpio;
- pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo-gpios[i],
- pinfo-alow_flags[i]);
- if (ret) {
- dev_err(dev, can't set output direction for gpio
- #%d: %d\n, i, ret);
- goto err_loop;
- }
}
pdata-max_chipselect = ngpios;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
On Fri, Jun 19, 2009 at 7:25 AM, Anton Vorontsovavoront...@ru.mvista.com wrote: Surely we can hide the bridge into the SPI controller driver, but I think it would be beneficial to factor-out it to a stand-alone entity, so that other SPI controllers could work with this setup without any modifications (oh and btw, we could also create a bridge called gpio-chipselects-bridge, and factor out all GPIO stuff from the drivers). There are two options of how we can factor out chip-select machines... the bad and the ugly. :-) No, the first one is bad, but the second should be OK. [...] 2. Another option (which I like more), is to create SPI chip- select machine driver framework, so we could (finally) separate two SPI entities: SPI IO and SPI chip-select machine. CS machines of different flavours: GPIO, built-in, and board-specific (!) with a lot of demuxing magic. I agree, I think your option 2 is the way to go. It would probably need to be implemented as some form of logical bridge so that SPI requests don't go straight to the IO driver, but first go through the CS machine so that the CS driver can do funky stuff like inserting or modifying SPI requests before they go to the hardware. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
On Thu, Jun 18, 2009 at 09:25:46PM -0500, Kumar Gala wrote: On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote: For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards, so make 1-bit mode default. When we resolve the issue, u-boot will remove sdhci,1-bit-only property from the device tree, while SDHCI will still work with older u-boots. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8569mds.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Did I miss the patch that adds this property defn. to our docs? Yep. ;-) http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073394.html Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
On Jun 19, 2009, at 10:31 AM, Anton Vorontsov wrote: On Thu, Jun 18, 2009 at 09:25:46PM -0500, Kumar Gala wrote: On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote: For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards, so make 1-bit mode default. When we resolve the issue, u-boot will remove sdhci,1-bit-only property from the device tree, while SDHCI will still work with older u-boots. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8569mds.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Did I miss the patch that adds this property defn. to our docs? Yep. ;-) http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073394.html Ok. I'll wait for Pierre to ack or pick up that patch before pulling in the .dts change. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
* Paul Mackerras pau...@samba.org wrote: Ingo Molnar writes: Note, i left out this bit from the commit - we need to find a better solution than to allow ugly warnings on PowerPC. Could we use the kernel's u64 type directly perhaps? That would allow us to change all __u64 to u64 in all of tools/perf/ which is a nice clean-up in any case. This is userspace, we can use u64 however we like. :) I'll cook up a patch to add typedef unsigned long long u64 and change __u64 to u64. Thanks, i've applied the patch. Note, it crossed with a few changes from Peter - i fixed up the conflicts - please double check whether it's still fine on PowerPC too. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
Sachin Sant wrote: 2.6.30-git14 (0732f87761dbe417cb6e084b712d07e879e876ef) fails to boot on various PowerPC machines. Here are last few boot messages from a Power6 box. SNIP I will go back and check what changes between git10 and git11 could have caused this boot failure. The offending commit seems to be c868d550115b9ccc0027c67265b9520790f05601. mm: Move pgtable_cache_init() earlier If i revert this commit, the machine boots fine. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
Could you please try the following patch, I am quite sure that checking
for 4 was accidentially done within io.c instead of = 4 as if it's 4
we still can copy a 32-bit word. Some hardware might not be happy about
8-bit accesses...
Index: 2.6.30-source/arch/powerpc/kernel/io.c
===
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c
@@ -162,5 +162,5 @@
n--;
}
-while(n 4) {
+while(n = 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
@@ -191,5 +191,5 @@
n--;
}
-while(n 4) {
+while(n = 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
Fahd Abidi wrote:
Hello,
I am trying to debug a crash during memcpy while copying data from the
FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
through my BDI3000 to see that the entire contents of the fcm buffer I
want moved are actually moved off to memory location I specify. The
crash comes after it memcpy finishes copying and performs the
instruction 2: cmplwi 0,r5,4:
memcpy:
rlwinm. r7,r5,32-3,3,31 /* r0 = r5 3 */
addi r6,r3,-4
addi r4,r4,-4
beq 2f /* if less than 8 bytes to do */
andi. r0,r6,3 /* get dest word aligned */
mtctr r7
bne 5f
1: lwz r7,4(r4)
lwzu r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
bdnz 1b
andi. r5,r5,7
2: cmplwi 0,r5,4
contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
specified correctly finished. At this point I can check the memory
contents through my BDI and verify all the data is in the ddr as I
expect. Now the strange thing happens, if I execute the cmplwi 0,r5,4
the program takes an exception and eventually gets struck at exception
vector 0x700 which I saw from start.S is an Alignment exception. I am
not sure what this exception means, can someone help me understand what
is happening?
Does this exception somehow mean that memcpy did not move all the data?
Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
cmplwi instruction?
Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.
Your Single Source for Professional Development Tools and Embedded
Solutions
Ph: 978-455-3383 x255
Fx: 978-926-3091
Email: fab...@ultsol.com
Visit: http://www.ultsol.com http://www.ultsol.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
On Fri, Jun 19, 2009 at 07:06:18PM +0200, Lorenz Kolb wrote: Could you please try the following patch, I am quite sure that checking for 4 was accidentially done within io.c instead of = 4 as if it's 4 we still can copy a 32-bit word. Some hardware might not be happy about 8-bit accesses... There seems to be desire for this fix: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html If it works here, too, then you could maybe also ack it? BTW, I can't find the original patch in patchwork, maybe the patch was missed because of that? Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
Am 19.06.09 19:06 schrieb(en) Lorenz Kolb: Could you please try the following patch, I am quite sure that checking for 4 was accidentially done within io.c instead of = 4 as if it's 4 we still can copy a 32-bit word. Some hardware might not be happy about 8-bit accesses... I submitted the same patch a while ago, see http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html and http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073065.html, maybe you can add a tested/revied for it? If it is a problem with *byte* accesses, you might want to have a look at http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html. Best, Albrecht. pgp3SiMGPWYf4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem with memcpy on ppc8536
Could you please try the following patch, I am quite sure that checking
for 4 was accidentially done within io.c instead of = 4 as if it's 4
we still can copy a 32-bit word. Some hardware might not be happy about
8-bit accesses...
Index: 2.6.30-source/arch/powerpc/kernel/io.c
===
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c
@@ -162,5 +162,5 @@
n--;
}
-while(n 4) {
+while(n = 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
@@ -191,5 +191,5 @@
n--;
}
-while(n 4) {
+while(n = 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
Fahd Abidi wrote:
Hello,
I am trying to debug a crash during memcpy while copying data from the
FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
through my BDI3000 to see that the entire contents of the fcm buffer I
want moved are actually moved off to memory location I specify. The
crash comes after it memcpy finishes copying and performs the
instruction 2: cmplwi 0,r5,4:
memcpy:
rlwinm. r7,r5,32-3,3,31 /* r0 = r5 3 */
addi r6,r3,-4
addi r4,r4,-4
beq 2f /* if less than 8 bytes to do */
andi. r0,r6,3 /* get dest word aligned */
mtctr r7
bne 5f
1: lwz r7,4(r4)
lwzu r8,8(r4)
stw r7,4(r6)
stwu r8,8(r6)
bdnz 1b
andi. r5,r5,7
2: cmplwi 0,r5,4
contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
specified correctly finished. At this point I can check the memory
contents through my BDI and verify all the data is in the ddr as I
expect. Now the strange thing happens, if I execute the cmplwi 0,r5,4
the program takes an exception and eventually gets struck at exception
vector 0x700 which I saw from start.S is an Alignment exception. I am
not sure what this exception means, can someone help me understand what
is happening?
Does this exception somehow mean that memcpy did not move all the data?
Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
cmplwi instruction?
Fahd Abidi
Product Manager - Technical Tools and Development
Ultimate Solutions, Inc.
Your Single Source for Professional Development Tools and Embedded
Solutions
Ph: 978-455-3383 x255
Fx: 978-926-3091
Email: fab...@ultsol.com
Visit: http://www.ultsol.com http://www.ultsol.com/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] fsldma: Add DMA_SLAVE support
On Thu, Jun 18, 2009 at 03:53:45PM -0700, Ira Snyder wrote: Use the DMA_SLAVE capability of the DMAEngine API to copy/from a scatterlist into an arbitrary list of hardware address/length pairs. This allows a single DMA transaction to copy data from several different devices into a scatterlist at the same time. This also adds support to enable some controller-specific features such as external start and external pause for a DMA transaction. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- After discussion with Dan Williams, this is the second version of the DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily with both drivers I have written against this API, an FPGA programmer and an FPGA data grabber. Kumar, Dan asked me to add you to the CC list, so you can have a look at this patch before he adds it to his tree. The other two small patches I posted earlier are very helpful in testing this functionality. They make the fsldma driver leave the BWC (bandwidth control) bits alone on the 83xx controller, as well as making the external start feature available on 83xx. In order for the external start/pause features to be useful, the bandwidth control bits (in the mode register) need to be set before attempting to use the controller. I could spin a v3 of this patch that adds a field to struct fsl_dma_slave to set the bits appropriately. Or I could send another patch for that. Thoughts? Many thanks to all that have participated in the discussion about this patch. v1 - v2: * move fsldma.h from include/linux to arch/powerpc/include/asm * add kerneldoc documentation [snip] + + /* Enable extra controller features */ + if (fsl_chan-set_src_loop_size) + fsl_chan-set_src_loop_size(fsl_chan, slave-src_loop_size); + + if (fsl_chan-set_dest_loop_size) + fsl_chan-set_dest_loop_size(fsl_chan, slave-dst_loop_size); + + if (fsl_chan-toggle_ext_start) + fsl_chan-toggle_ext_start(fsl_chan, slave-external_start); + + if (fsl_chan-toggle_ext_pause) + fsl_chan-toggle_ext_pause(fsl_chan, slave-external_pause); I just noticed that I got this wrong for external pause. It takes a size, not a boolean enable/disable. I'll split the size out from the external pause feature, and send another patch. + + return first-async_tx; + ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
Albrecht Dreß wrote:
This trivial patch changes memcpy_(to|from)io as to transfer as many
32-bit words as possible in 32-bit accesses (in the current solution,
the last 32-bit word was transferred as 4 byte accesses).
Signed-off-by: Albrecht Dreß albrecht.dr...@arcor.de
---
diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff
linux-2.6.29.1.orig/arch/powerpc/kernel/io.c
linux-2.6.29.1/arch/powerpc/kernel/io.c
--- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c2009-04-02
22:55:27.0 +0200
+++ linux-2.6.29.1/arch/powerpc/kernel/io.c2009-05-27
11:36:09.0 +0200
@@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
dest++;
n--;
}
-while(n 4) {
+while(n = 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
vsrc += 4;
@@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
vdest++;
n--;
}
-while(n 4) {
+while(n = 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
vdest += 4;
Works for me (and some custom hardware I created [quite a while ago,
when I was young ;-)] that is not very tolerant to Byte-by-Byte-Transfers).
Thus:
Acked
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
On Thu, 18 Jun 2009 00:14:08 +0400 Anton Vorontsov avoront...@ru.mvista.com wrote: Some hosts (hardware configurations, or particular SD/MMC slots) may not support 4-bit bus. For example, on MPC8569E-MDS boards we can switch between serial (1-bit only) and nibble (4-bit) modes, thought we have to disable more peripherals to work in 4-bit mode. Along with some small core changes, this patch modifies sdhci-of driver, so that now it looks for sdhci,1-bit-only property in the device-tree, and if specified we enable a proper quirk. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- Patch merged. Rgds -- -- Pierre Ossman WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] fsldma: split apart external pause and request count features
When using the Freescale DMA controller in external control mode, both the
request count and external pause bits need to be setup correctly. This was
being done with the same function.
The 83xx controller lacks the external pause feature, but has a similar
feature called external start. This feature requires that the request count
bits be setup correctly.
Split the function into two parts, to make it possible to use the external
start feature on the 83xx controller.
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
This patch splits apart the external pause feature from the request
count feature, to make it possible to use the external start feature on
the 83xx controller without writing the register directly after the
driver has been initialized.
The DMA_SLAVE patch depends on this patch.
drivers/dma/fsldma.c | 45 +
drivers/dma/fsldma.h |3 ++-
2 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 6e60c77..dd9d4d6 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -280,28 +280,40 @@ static void fsl_chan_set_dest_loop_size(struct
fsl_dma_chan *fsl_chan, int size)
}
/**
- * fsl_chan_toggle_ext_pause - Toggle channel external pause status
+ * fsl_chan_set_request_count - Set DMA Request Count for external control
* @fsl_chan : Freescale DMA channel
- * @size : Pause control size, 0 for disable external pause control.
- * The maximum is 1024.
+ * @size : Number of bytes to transfer in a single request
+ *
+ * The Freescale DMA channel can be controlled by the external signal DREQ#.
+ * The DMA request count is how many bytes are allowed to transfer before
+ * pausing the channel, after which a new assertion of DREQ# resumes channel
+ * operation.
*
- * The Freescale DMA channel can be controlled by the external
- * signal DREQ#. The pause control size is how many bytes are allowed
- * to transfer before pausing the channel, after which a new assertion
- * of DREQ# resumes channel operation.
+ * A size of 0 disables external pause control. The maximum size is 1024.
*/
-static void fsl_chan_toggle_ext_pause(struct fsl_dma_chan *fsl_chan, int size)
+static void fsl_chan_set_request_count(struct fsl_dma_chan *fsl_chan, int size)
{
- if (size 1024)
- return;
+ BUG_ON(size 1024);
+ DMA_OUT(fsl_chan, fsl_chan-reg_base-mr,
+ DMA_IN(fsl_chan, fsl_chan-reg_base-mr, 32)
+ | ((__ilog2(size) 24) 0x0f00),
+ 32);
+}
- if (size) {
- DMA_OUT(fsl_chan, fsl_chan-reg_base-mr,
- DMA_IN(fsl_chan, fsl_chan-reg_base-mr, 32)
- | ((__ilog2(size) 24) 0x0f00),
- 32);
+/**
+ * fsl_chan_toggle_ext_pause - Toggle channel external pause status
+ * @fsl_chan : Freescale DMA channel
+ * @enable : 0 is disabled, 1 is enabled.
+ *
+ * The Freescale DMA channel can be controlled by the external signal DREQ#.
+ * The DMA Request Count feature should be used in addition to this feature
+ * to set the number of bytes to transfer before pausing the channel.
+ */
+static void fsl_chan_toggle_ext_pause(struct fsl_dma_chan *fsl_chan, int
enable)
+{
+ if (enable)
fsl_chan-feature |= FSL_DMA_CHAN_PAUSE_EXT;
- } else
+ else
fsl_chan-feature = ~FSL_DMA_CHAN_PAUSE_EXT;
}
@@ -883,6 +895,7 @@ static int __devinit fsl_dma_chan_probe(struct
fsl_dma_device *fdev,
new_fsl_chan-toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan-set_src_loop_size = fsl_chan_set_src_loop_size;
new_fsl_chan-set_dest_loop_size = fsl_chan_set_dest_loop_size;
+ new_fsl_chan-set_request_count = fsl_chan_set_request_count;
}
spin_lock_init(new_fsl_chan-desc_lock);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index dc7f268..462208d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -143,10 +143,11 @@ struct fsl_dma_chan {
struct tasklet_struct tasklet;
u32 feature;
- void (*toggle_ext_pause)(struct fsl_dma_chan *fsl_chan, int size);
+ void (*toggle_ext_pause)(struct fsl_dma_chan *fsl_chan, int enable);
void (*toggle_ext_start)(struct fsl_dma_chan *fsl_chan, int enable);
void (*set_src_loop_size)(struct fsl_dma_chan *fsl_chan, int size);
void (*set_dest_loop_size)(struct fsl_dma_chan *fsl_chan, int size);
+ void (*set_request_count)(struct fsl_dma_chan *fsl_chan, int size);
};
#define to_fsl_chan(chan) container_of(chan, struct fsl_dma_chan, common)
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3 2/2] fsldma: Add DMA_SLAVE support
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some controller-specific features such as
external start and external pause for a DMA transaction.
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
This patch depends on the fsldma: split apart external pause and
request count features patch.
After discussion with Dan Williams, this is the third version of the
DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
with both drivers I have written against this API, an FPGA programmer
and an FPGA data grabber.
Kumar, Dan asked me to add you to the CC list, so you can have a look at
this patch before he adds it to his tree.
The other two small patches I posted earlier are very helpful in testing
this functionality. They make the fsldma driver leave the BWC (bandwidth
control) bits alone on the 83xx controller, as well as making the
external start feature available on 83xx.
v2 - v3:
* add support for setting DMA request count
v1 - v2:
* move fsldma.h from include/linux to arch/powerpc/include/asm
* add kerneldoc documentation
arch/powerpc/include/asm/fsldma.h | 136 ++
drivers/dma/fsldma.c | 227 +
2 files changed, 363 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
diff --git a/arch/powerpc/include/asm/fsldma.h
b/arch/powerpc/include/asm/fsldma.h
new file mode 100644
index 000..a67aeed
--- /dev/null
+++ b/arch/powerpc/include/asm/fsldma.h
@@ -0,0 +1,136 @@
+/*
+ * Freescale MPC83XX / MPC85XX DMA Controller
+ *
+ * Copyright (c) 2009 Ira W. Snyder i...@ovro.caltech.edu
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_POWERPC_ASM_FSLDMA_H__
+#define __ARCH_POWERPC_ASM_FSLDMA_H__
+
+#include linux/dmaengine.h
+
+/*
+ * Definitions for the Freescale DMA controller's DMA_SLAVE implemention
+ *
+ * The Freescale DMA_SLAVE implementation was designed to handle many-to-many
+ * transfers. An example usage would be an accelerated copy between two
+ * scatterlists. Another example use would be an accelerated copy from
+ * multiple non-contiguous device buffers into a single scatterlist.
+ *
+ * A DMA_SLAVE transaction is defined by a struct fsl_dma_slave. This
+ * structure contains a list of hardware addresses that should be copied
+ * to/from the scatterlist passed into device_prep_slave_sg(). The structure
+ * also has some fields to enable hardware-specific features.
+ */
+
+/**
+ * struct fsl_dma_hw_addr
+ * @entry: linked list entry
+ * @address: the hardware address
+ * @length: length to transfer
+ *
+ * Holds a single physical hardware address / length pair for use
+ * with the DMAEngine DMA_SLAVE API.
+ */
+struct fsl_dma_hw_addr {
+ struct list_head entry;
+
+ dma_addr_t address;
+ size_t length;
+};
+
+/**
+ * struct fsl_dma_slave
+ * @addresses: a linked list of struct fsl_dma_hw_addr structures
+ * @request_count: value for DMA request count
+ * @src_loop_size: setup and enable constant source-address DMA transfers
+ * @dst_loop_size: setup and enable constant destination address DMA transfers
+ * @external_start: enable externally started DMA transfers
+ * @external_pause: enable externally paused DMA transfers
+ *
+ * Holds a list of address / length pairs for use with the DMAEngine
+ * DMA_SLAVE API implementation for the Freescale DMA controller.
+ */
+struct fsl_dma_slave {
+
+ /* List of hardware address/length pairs */
+ struct list_head addresses;
+
+ /* Support for extra controller features */
+ unsigned int request_count;
+ unsigned int src_loop_size;
+ unsigned int dst_loop_size;
+ bool external_start;
+ bool external_pause;
+};
+
+/**
+ * fsl_dma_slave_append - add an address/length pair to a struct fsl_dma_slave
+ * @slave: the struct fsl_dma_slave to add to
+ * @address: the hardware address to add
+ * @length: the length of bytes to transfer from @address
+ *
+ * Add a hardware address/length pair to a struct fsl_dma_slave. Returns 0 on
+ * success, -ERRNO otherwise.
+ */
+static inline int fsl_dma_slave_append(struct fsl_dma_slave *slave,
+ dma_addr_t address, size_t length)
+{
+ struct fsl_dma_hw_addr *addr;
+
+ addr = kzalloc(sizeof(*addr), GFP_ATOMIC);
+ if (!addr)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(addr-entry);
+ addr-address = address;
+ addr-length = length;
+
+ list_add_tail(addr-entry, slave-addresses);
+ return 0;
+}
+
+/**
+ * fsl_dma_slave_free - free a struct fsl_dma_slave
+ *
RE: kilauea/405ex external interrupts
You will have to program GPIO's to select appropriate external IRQ as
they are shared .
From: linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc@lists.ozlabs.org] On Behalf
Of Lada Podivin
Sent: Friday, June 19, 2009 1:01 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: kilauea/405ex external interrupts
Hi,
I'm writing a linux driver that uses an external interrupt (ppc 405ex).
I'm using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of
the virtual interrupt stuff, so I added a new node to my device tree in
order to get proper virtual IRQ number. This node describes an external
event and its connection to UIC via the mentioned ext. int. Here is a
sample of the divce-tree:
..
UIC1: interrupt-controller1 {
compatible = ibm,uic-405ex,ibm,uic;
interrupt-controller;
cell-index = 1;
dcr-reg = 0x0d0 0x009;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
interrupt-parent = UIC0;
};
EXTEVENT: external_event {
device_type = external;
#address-cells = 0;
#size-cells = 0;
#interrupt-cells = 2;
interrupts = 0x1e 0x1;
interrupt-parent = UIC1;
};
...
Then I use function irq_of_parse_and_map() which returns the virtual
IRQ number 22. So, request_irq() seems to be satisfied with this
number. I can see this interrupt in the /proc/interrupts. But! When I
connect a signal source to the pin 30, nothing happens - the interrupt
service routine isn't called.
Am I suppose to configure anything else? (e. g. pin multiplexing,
further device-tree tuning...) Thank you!
Best regards,
Ladi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/amigaone: Convert amigaone_init() to a machine_device_initcall()
This allows to remove the ppc_md.init() hook in the setup code.
Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net
---
arch/powerpc/platforms/amigaone/setup.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/amigaone/setup.c
b/arch/powerpc/platforms/amigaone/setup.c
index e8bea5e..ca65d86 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -111,13 +111,16 @@ void __init amigaone_init_IRQ(void)
irq_set_default_host(i8259_get_host());
}
-void __init amigaone_init(void)
+static int __init request_isa_regions(void)
{
request_region(0x00, 0x20, dma1);
request_region(0x40, 0x20, timer);
request_region(0x80, 0x10, dma page reg);
request_region(0xc0, 0x20, dma2);
+
+ return 0;
}
+machine_device_initcall(amigaone, request_isa_regions);
void amigaone_restart(char *cmd)
{
@@ -162,7 +165,6 @@ define_machine(amigaone) {
.name = AmigaOne,
.probe = amigaone_probe,
.setup_arch = amigaone_setup_arch,
- .init = amigaone_init,
.show_cpuinfo = amigaone_show_cpuinfo,
.init_IRQ = amigaone_init_IRQ,
.restart= amigaone_restart,
--
1.5.6.5
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/amigaone: Limit ISA I/O range to 4k in the device tree
The kernel reserves the I/O address space from 0x0 to 0xfff for legacy ISA devices. Change the ranges property for the PCI2ISA bridge to match the kernels behavior, even if the ranges property isn't used for now. Signed-off-by: Gerhard Pircher gerhard_pirc...@gmx.net --- arch/powerpc/boot/dts/amigaone.dts |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/dts/amigaone.dts b/arch/powerpc/boot/dts/amigaone.dts index 26549fc..49ac36b 100644 --- a/arch/powerpc/boot/dts/amigaone.dts +++ b/arch/powerpc/boot/dts/amigaone.dts @@ -70,8 +70,8 @@ devsel-speed = 0x0001; min-grant = 0; max-latency = 0; - /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */ - ranges = 0x0001 0 0x0100 0 0x 0x0001; + /* First 4k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */ + ranges = 0x0001 0 0x0100 0 0x 0x1000; interrupt-parent = i8259; #interrupt-cells = 2; #address-cells = 2; -- 1.5.6.5 -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
On Fri, 2009-06-19 at 22:36 +0530, Sachin Sant wrote: The offending commit seems to be c868d550115b9ccc0027c67265b9520790f05601. mm: Move pgtable_cache_init() earlier If i revert this commit, the machine boots fine. That is strange. If I revert that commit, I get breakages on machines here. It would be interesting to understand what the problem is here, as we -do- use that kmem cache for allocating page tables, so we do need it initialized that early. (IE, we can't allow vmalloc for example to be called before the page table caches are initialized). This will need more debugging and understanding as to why it hangs. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of_serial: Add UPF_FIXED_TYPE flag
On Fri, 2009-06-19 at 18:24 +1000, Michael Ellerman wrote: I think we /probably/ want a similar change in legacy_serial.c, for soc ports at least. Or do people have things that are compatible ns16550 but aren't? Do we really want to keep of_serial.c ? I fail to see the point in keeping -both- the of_serial (of_device variant) and the legacy serial stuff which shims the device-tree into platform devices. They tend to clash with each other too, which is annoying. Cheers, Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: warp platform fix for i2c change
A change to the i2c subsystem breaks the warp platform code. The patch
is cleaner anyway, the old way was a bit crufty.
For those with keen eyes, the gratuitous change in the string from
PIKA to Warp is just so the logs look a bit nicer. The following two
lines tend to be printed one after another.
Warp POST OK
Warp DTM thread running.
Yeah, this will be the third patch to warp.c submitted in this
release
Cheers,
Sean
The i2c_client struct changed, breaking the code that looked for the ad7414
chip. Use the new of_find_i2c_device_by_node function added in 2.6.29.
Signed-off-by: Sean MacLennan smaclen...@pikatech.com
---
diff --git a/arch/powerpc/platforms/44x/warp.c
b/arch/powerpc/platforms/44x/warp.c
index 42e09a9..0362c88 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -16,6 +16,7 @@
#include linux/interrupt.h
#include linux/delay.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
#include asm/machdep.h
#include asm/prom.h
@@ -65,7 +66,6 @@ define_machine(warp) {
static u32 post_info;
-/* I am not sure this is the best place for this... */
static int __init warp_post_info(void)
{
struct device_node *np;
@@ -194,9 +194,9 @@ static int pika_setup_leds(void)
return 0;
}
-static void pika_setup_critical_temp(struct i2c_client *client)
+static void pika_setup_critical_temp(struct device_node *np,
+struct i2c_client *client)
{
- struct device_node *np;
int irq, rc;
/* Do this before enabling critical temp interrupt since we
@@ -208,14 +208,7 @@ static void pika_setup_critical_temp(struct i2c_client
*client)
i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
i2c_smbus_write_byte_data(client, 3, 0); /* Tlow */
- np = of_find_compatible_node(NULL, NULL, adi,ad7414);
- if (np == NULL) {
- printk(KERN_ERR __FILE__ : Unable to find ad7414\n);
- return;
- }
-
irq = irq_of_parse_and_map(np, 0);
- of_node_put(np);
if (irq == NO_IRQ) {
printk(KERN_ERR __FILE__ : Unable to get ad7414 irq\n);
return;
@@ -244,32 +237,24 @@ static inline void pika_dtm_check_fan(void __iomem *fpga)
static int pika_dtm_thread(void __iomem *fpga)
{
- struct i2c_adapter *adap;
+ struct device_node *np;
struct i2c_client *client;
- /* We loop in case either driver was compiled as a module and
-* has not been insmoded yet.
-*/
- while (!(adap = i2c_get_adapter(0))) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(HZ);
- }
-
- while (1) {
- list_for_each_entry(client, adap-clients, list)
- if (client-addr == 0x4a)
- goto found_it;
+ np = of_find_compatible_node(NULL, NULL, adi,ad7414);
+ if (np == NULL)
+ return -ENOENT;
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(HZ);
+ client = of_find_i2c_device_by_node(np);
+ if (client == NULL) {
+ of_node_put(np);
+ return -ENOENT;
}
-found_it:
- pika_setup_critical_temp(client);
+ pika_setup_critical_temp(np, client);
- i2c_put_adapter(adap);
+ of_node_put(np);
- printk(KERN_INFO PIKA DTM thread running.\n);
+ printk(KERN_INFO Warp DTM thread running.\n);
while (!kthread_should_stop()) {
int val;
@@ -291,7 +276,6 @@ found_it:
return 0;
}
-
static int __init pika_dtm_start(void)
{
struct task_struct *dtm_thread;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
