* Re: Initialize DBCR0 for PPC440 targets
From: David Gibson @ 2009-05-26 2:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: srikanth krishnakar, Linuxppc-dev
In-Reply-To: <1243235075.24376.60.camel@pasglop>
On Mon, May 25, 2009 at 05:04:35PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-05-20 at 16:00 +1000, David Gibson wrote:
> > On Wed, May 20, 2009 at 11:20:46AM +0530, srikanth krishnakar wrote:
> > > Hi David,
> > >
> > > I am not sure how the IDM behaves on few of PPC440 targets which don't
> > > have boot loaders. I have a reference for your question:
> > >
> > > http://www.nabble.com/Question-about-DBCR0-initialization-for-440-td23049044.html
> > >
> > > Without this fix (given patch) I am facing problems with GDB, and
> > > further target hangs while running gdbserver !
> >
> > That doesn't answer my question. It's not enough to say "this fixes a
> > problem" you need to explain *how* it fixes the problem.
> >
> > And I don't see why IDM would have any effect on *software*
> > breakpoints.
>
> No but gdb can use the DABR emulation and single step would be busted
> too. GDB internally heavily uses single step in places you wouldn't
> expect it to :-) Like I think when breaking on main, it sometimes single
> step the whole init process of the executable until it hits it. At least
> I've seen it do that when I was debugging the debug support for 64-bit
> Book3E.
Right, but I believe the kernel does turn on IDM when it turns on
single step, or the DAC event bit.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2 v8] powerpc: introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-26 3:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, smaclennan
In-Reply-To: <9e4733910905251046y5f7377f4y49ce72e775faef16@mail.gmail.com>
On Mon, May 25, 2009 at 12:46 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> I just tried using this. The !rc has the effect of making the error
> return be zero instead the normal not zero.
You're confused. It's not a "return code", it's a return value. I
guess I should have called the parameter "ret" instead of "rc", but I
didn't expect people to get confused.
'rc' is the value of the expression when the loop terminates. That's
what makes the most sense, because the developer will want to know
what that value is. If you're expression happens to rely on negative
logic (e.g. wait until a bit is cleared), then of course it's going to
appear "backwards" when you test it.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 3/5] AC97 driver for mpc5200
From: Timur Tabi @ 2009-05-26 3:41 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090525221511.21370.81405.stgit@terra>
On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> + =A0 =A0 =A0 spin_event_timeout(1, 3, 0, rc);
Ugh, don't do this. Just use udelay!
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Timur Tabi @ 2009-05-26 3:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <20090525221406.21370.30326.stgit@terra>
On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> =A0 =A0 =A0The macro spin_event_timeout() takes a condition and timeout v=
alue
My patch is already set to go through the powerpc tree, so there's no
need to repost it here. Please, you changed the title of the patch.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 3/5] AC97 driver for mpc5200
From: Grant Likely @ 2009-05-26 3:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <ed82fe3e0905252041u367cac2fk80c9316c0236e340@mail.gmail.com>
On Mon, May 25, 2009 at 9:41 PM, Timur Tabi <timur@freescale.com> wrote:
> On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> + =A0 =A0 =A0 spin_event_timeout(1, 3, 0, rc);
>
> Ugh, don't do this. =A0Just use udelay!
heh; indeed. My objection to udelay is that it burns cycles it the
test loop that could be used to decide whether or not the loop is
complete. Not an issue when the explicit goal is to burn a fixed
number of cycles.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-05-26 3:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's the first of two fixes for nasty brown paper bag bugs that went
in recently and are both my fault (I need to start buying those bags
in bulk I reckon...)
It's 2.6.30 material. I'll send the second one tomorrow or so after a
bit more review and testing happened as it's unfortunately more
invasive.
The following changes since commit b18f1e21993f73f072b1e0859f942fb11afddcb1:
Linus Torvalds (1):
Merge branch 'kvm-updates/2.6.30' of git://git.kernel.org/pub/scm/virt/kvm/kvm
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Hideo Saito (1):
powerpc/mm: Fix broken MMU PID stealing on !SMP
arch/powerpc/mm/mmu_context_nohash.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH] powerpc: Convert RTAS event scan from kernel thread to workqueue
From: Anton Blanchard @ 2009-05-26 6:25 UTC (permalink / raw)
To: linuxppc-dev
RTAS event scan has to run across all cpus. Right now we use a kernel
thread and set_cpus_allowed but in doing so we wake up the previous cpu
unnecessarily.
Some ftrace output shows this:
previous cpu (2):
[002] 7.022331: sched_switch: task swapper:0 [140] ==> rtasd:194 [120]
[002] 7.022338: sched_switch: task rtasd:194 [120] ==> migration/2:9 [0]
[002] 7.022344: sched_switch: task migration/2:9 [0] ==> swapper:0 [140]
next cpu (3):
[003] 7.022345: sched_switch: task swapper:0 [140] ==> rtasd:194 [120]
[003] 7.022371: sched_switch: task rtasd:194 [120] ==> swapper:0 [140]
We can use schedule_delayed_work_on and avoid the unnecessary wakeup.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-2.6/arch/powerpc/platforms/pseries/rtasd.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pseries/rtasd.c 2009-03-15 17:03:45.000000000 +1100
+++ linux-2.6/arch/powerpc/platforms/pseries/rtasd.c 2009-05-26 16:02:39.000000000 +1000
@@ -19,7 +19,7 @@
#include <linux/vmalloc.h>
#include <linux/spinlock.h>
#include <linux/cpu.h>
-#include <linux/delay.h>
+#include <linux/workqueue.h>
#include <asm/uaccess.h>
#include <asm/io.h>
@@ -387,36 +387,51 @@
} while(error == 0);
}
-static void do_event_scan_all_cpus(long delay)
+static void rtas_event_scan(struct work_struct *w);
+DECLARE_DELAYED_WORK(event_scan_work, rtas_event_scan);
+
+/*
+ * Delay should be at least one second since some machines have problems if
+ * we call event-scan too quickly.
+ */
+static unsigned long event_scan_delay = 1*HZ;
+static int first_pass = 1;
+
+static void rtas_event_scan(struct work_struct *w)
{
- int cpu;
+ unsigned int cpu;
+
+ do_event_scan();
get_online_cpus();
- cpu = first_cpu(cpu_online_map);
- for (;;) {
- set_cpus_allowed(current, cpumask_of_cpu(cpu));
- do_event_scan();
- set_cpus_allowed(current, CPU_MASK_ALL);
-
- /* Drop hotplug lock, and sleep for the specified delay */
- put_online_cpus();
- msleep_interruptible(delay);
- get_online_cpus();
- cpu = next_cpu(cpu, cpu_online_map);
- if (cpu == NR_CPUS)
- break;
+ cpu = next_cpu(smp_processor_id(), cpu_online_map);
+ if (cpu == NR_CPUS) {
+ cpu = first_cpu(cpu_online_map);
+
+ if (first_pass) {
+ first_pass = 0;
+ event_scan_delay = 30*HZ/rtas_event_scan_rate;
+
+ if (surveillance_timeout != -1) {
+ pr_debug("rtasd: enabling surveillance\n");
+ enable_surveillance(surveillance_timeout);
+ pr_debug("rtasd: surveillance enabled\n");
+ }
+ }
}
+
+ schedule_delayed_work_on(cpu, &event_scan_work,
+ __round_jiffies_relative(event_scan_delay, cpu));
+
put_online_cpus();
}
-static int rtasd(void *unused)
+static void start_event_scan(void)
{
unsigned int err_type;
int rc;
- daemonize("rtasd");
-
printk(KERN_DEBUG "RTAS daemon started\n");
pr_debug("rtasd: will sleep for %d milliseconds\n",
(30000 / rtas_event_scan_rate));
@@ -434,22 +449,8 @@
}
}
- /* First pass. */
- do_event_scan_all_cpus(1000);
-
- if (surveillance_timeout != -1) {
- pr_debug("rtasd: enabling surveillance\n");
- enable_surveillance(surveillance_timeout);
- pr_debug("rtasd: surveillance enabled\n");
- }
-
- /* Delay should be at least one second since some
- * machines have problems if we call event-scan too
- * quickly. */
- for (;;)
- do_event_scan_all_cpus(30000/rtas_event_scan_rate);
-
- return -EINVAL;
+ schedule_delayed_work_on(first_cpu(cpu_online_map), &event_scan_work,
+ event_scan_delay);
}
static int __init rtas_init(void)
@@ -487,8 +488,7 @@
if (!entry)
printk(KERN_ERR "Failed to create error_log proc entry\n");
- if (kernel_thread(rtasd, NULL, CLONE_FS) < 0)
- printk(KERN_ERR "Failed to start RTAS daemon\n");
+ start_event_scan();
return 0;
}
^ permalink raw reply
* Re: [PATCH resend4 2/3] itimers: fix periodic tics precision
From: Stanislaw Gruszka @ 2009-05-26 6:44 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Ingo, Peter Zijlstra, linuxppc-dev, linux-kernel@vger.kernel.org,
Nesterov, Oleg, Molnar, Andrew Morton
In-Reply-To: <20090525145132.03915e19@dhcp-lab-109.englab.brq.redhat.com>
On Mon, 25 May 2009 14:51:32 +0200
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Mon, 25 May 2009 14:32:14 +0200 (CEST)
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > On Mon, 25 May 2009, Stanislaw Gruszka wrote:
> > > @@ -904,6 +905,7 @@ void __init time_init(void)
> > > tb_ticks_per_usec = ppc_tb_freq / 1000000;
> > > tb_to_us = mulhwu_scale_factor(ppc_tb_freq, 1000000);
> > > calc_cputime_factors();
> > > + cputime_one = jiffies_to_cputime(1);
> >
> > 1) The variable name is misleading.
>
> What about cputime_one_jiffy ?
>
> > 2) The patch breaks all powerpc platforms which have
> > CONFIG_VIRT_CPU_ACCOUNTING=n and ia64 with
> > CONFIG_VIRT_CPU_ACCOUNTING=y
>
> Stupid me, in asm-generic/cputime.h should be
> #define cputime_one jiffies_to_cputime(1)
Hmmm, I'm confused. Perhaps I missed something, but I think patch was ok.
For powerpc and ia64 and CONFIG_VIRT_CPU_ACCOUNTING=n definitions from
asm-generic/cputime.h where used. In this file was:
#define cputime_one (1UL)
and that correct as jiffies_to_cputime(x) is just (x)
For CONFIG_VIRT_CPU_ACCOUTING=y:
- For powerpc additional variable was declared and computed in
initialization time. Declaration of was in __KERENEL__ scope.
- For ia64: cputime_one was defined as jiffies_to_cputime(1)
Anyway I didn't try to even compile the patch on other architectures than x86.
Of cource I will test my patch, but first I would like to know what You think?
Does we really need such optimization (because before usage of
jiffies_to_cputime(1) was just fine) ?
Cheers
Stanislaw
^ permalink raw reply
* Re: [PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
From: Geert Uytterhoeven @ 2009-05-26 7:29 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie, timur
In-Reply-To: <20090525221507.21370.68301.stgit@terra>
On Mon, 25 May 2009, Jon Smirl wrote:
> (in microseconds) as parameters. It spins until either the condition is true
> or the timeout expires. It returns the result of the condition when the loop
> was terminated.
>
> This primary purpose of this macro is to poll on a hardware register until a
> status bit changes. The timeout ensures that the loop still terminates if the
> bit doesn't change as expected. This macro makes it easier for driver
> developers to perform this kind of operation properly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/include/asm/delay.h | 33 +++++++++++++++++++++++++++++++++
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
> index f9200a6..fedf037 100644
> --- a/arch/powerpc/include/asm/delay.h
> +++ b/arch/powerpc/include/asm/delay.h
> @@ -2,8 +2,11 @@
> #define _ASM_POWERPC_DELAY_H
> #ifdef __KERNEL__
>
> +#include <asm/time.h>
> +
> /*
> * Copyright 1996, Paul Mackerras.
> + * Copyright (C) 2009 Freescale Semiconductor, 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
> @@ -30,5 +33,35 @@ extern void udelay(unsigned long usecs);
> #define mdelay(n) udelay((n) * 1000)
> #endif
>
> +/**
> + * spin_event_timeout - spin until a condition gets true or a timeout elapses
> + * @condition: a C expression to evalate
> + * @timeout: timeout, in microseconds
> + * @delay: the number of microseconds to delay between eache evaluation of
> + * @condition
> + * @rc: the last value of the condition
> + *
> + * The process spins until the condition evaluates to true (non-zero) or the
> + * timeout elapses. Upon exit, @rc contains the value of the condition. This
> + * allows you to test the condition without incurring any side effects.
> + *
> + * This primary purpose of this macro is to poll on a hardware register
> + * until a status bit changes. The timeout ensures that the loop still
> + * terminates even if the bit never changes. The delay is for devices that
> + * need a delay in between successive reads.
> + *
> + * gcc will optimize out the if-statement if @delay is a constant.
> + */
> +#define spin_event_timeout(condition, timeout, delay, rc) \
static inline function, returning rc, instead of a macro?
> +{ \
> + unsigned long __loops = tb_ticks_per_usec * timeout; \
> + unsigned long __start = get_tbl(); \
> + while ((rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
> + if (delay) \
> + udelay(delay); \
> + else \
> + cpu_relax(); \
> +}
> +
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_DELAY_H */
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* MPC85xx erratum "I2C1 - I2C controller is unable to generate clocks when SDA is low coming out of reset"
From: Fredrik Arnerup @ 2009-05-26 8:22 UTC (permalink / raw)
To: linuxppc-dev
We've had some trouble with I2C not working after a soft reboot,
which we think is due to the the erratum "I2C1" which is present in
at least the mpc8540 and the mpc8560. Since there is no good workaround,
the only choice seems to be to avoid resetting the CPU while the I2C bus is
busy.
The problem seems to be that the i2c-mpc driver leaves I2C in a busy state
when
it receives a signal (e.g. upon shutdown).
The code below is not meant as a patch, just me thinking aloud.
Thoughts?
/Fredrik Arnerup
fredrik.arnerup@edgeware.tv
Index: drivers/i2c/busses/i2c-mpc.c
===================================================================
--- drivers/i2c/busses/i2c-mpc.c (revision 6933)
+++ drivers/i2c/busses/i2c-mpc.c (working copy)
@@ -262,12 +262,14 @@
/* Allow bus up to 1s to become not busy */
while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
if (signal_pending(current)) {
- pr_debug("I2C: Interrupted\n");
- writeccr(i2c, 0);
+ printk(KERN_WARNING "I2C: Interrupted\n");
+ if (readb(i2c->base + MPC_I2C_SR) ==
+ (CSR_MCF | CSR_MBB | CSR_RXAK))
+ mpc_i2c_fixup(i2c);
return -EINTR;
}
if (time_after(jiffies, orig_jiffies + HZ)) {
- pr_debug("I2C: timeout\n");
+ printk(KERN_WARNING "I2C: mpc_xfer() timeout\n");
if (readb(i2c->base + MPC_I2C_SR) ==
(CSR_MCF | CSR_MBB | CSR_RXAK))
mpc_i2c_fixup(i2c);
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Arnd Bergmann @ 2009-05-26 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linux Netdev List, devicetree-discuss
In-Reply-To: <4A1A418D.3040207@grandegger.com>
On Monday 25 May 2009, Wolfgang Grandegger wrote:
> > Right, that makes sense. However, most drivers use the field to store the
> > physical address, not the iomap token. Maybe there should be a new field
> > in struct sja1000_priv for the virtual address, but that would be a change
> > to the base driver, not just to the OF portion.
>
> Is that common practice? If yes, I will add a member to store the
> virtual address to struct sja1000_priv.
I grepped through the network driver for usage of ->base_addr, and
it's somewhat inconsistent. The majority of the users use it for
a physical address, but there are also a few that use it for the
__iomem token.
Casts between unsigned long and qualified (__iomem, __user, const, ...)
pointers do not cause a warning, but can easily lead to bugs when
another user casts to an unqualified pointer.
Arnd <><
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Mark Brown @ 2009-05-26 9:21 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <ed82fe3e0905252044w1d0e1f5cqbaf4256b9f749d42@mail.gmail.com>
On Mon, May 25, 2009 at 10:44:12PM -0500, Timur Tabi wrote:
> On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
> > ? ? ?The macro spin_event_timeout() takes a condition and timeout value
> My patch is already set to go through the powerpc tree, so there's no
> need to repost it here. Please, you changed the title of the patch.
Indeed. Since this is a new driver I'm happy to let the code go in
without the new function and then sort itself out in the merge window.
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: David Miller @ 2009-05-26 9:25 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, devicetree-discuss, netdev
In-Reply-To: <200905261010.31364.arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 26 May 2009 10:10:30 +0100
> On Monday 25 May 2009, Wolfgang Grandegger wrote:
>> > Right, that makes sense. However, most drivers use the field to store the
>> > physical address, not the iomap token. Maybe there should be a new field
>> > in struct sja1000_priv for the virtual address, but that would be a change
>> > to the base driver, not just to the OF portion.
>>
>> Is that common practice? If yes, I will add a member to store the
>> virtual address to struct sja1000_priv.
>
> I grepped through the network driver for usage of ->base_addr, and
> it's somewhat inconsistent. The majority of the users use it for
> a physical address, but there are also a few that use it for the
> __iomem token.
>
> Casts between unsigned long and qualified (__iomem, __user, const, ...)
> pointers do not cause a warning, but can easily lead to bugs when
> another user casts to an unqualified pointer.
It's such a baroque thing, there is no reason to set it at all if you
ask me. It's only use is to allow ISA and similar primitive bus
devices to have their I/O ports changed via ifconfig.
^ permalink raw reply
* Query on KGDBOE
From: purushothama s @ 2009-05-26 9:29 UTC (permalink / raw)
To: Linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
Hi All,
I am working on Xilinx virtex5 ppc44x target. I am seeing that
CONFIG_NET_POLL_CONTROLLER is not present xlltemac_main.c, has anybody come
across it. And I also see lltemac is working in interrupt driven mode and
not in polled mode. Is it possible support KGDBOE for xilinx LLTEMAC driver
from Xilinx Git:
log of kernel crash:
===============
KGDB: re-enter exception: ALL breakpoints killed
Call Trace:
[c0391a10] [c00060d0] show_stack+0x4c/0x16c (unreliable)
[c0391a50] [c0067b54] kgdb_handle_exception+0xb28/0xe14
[c0391af0] [c000fa50] kgdb_handle_breakpoint+0x4c/0x8c
[c0391b00] [c000ce40] program_check_exception+0x45c/0x600
[c0391b20] [c000f090] ret_from_except_full+0x0/0x4c
[c0391be0] [c0390000] 0xc0390000
[c0391bf0] [c01df520] xenet_DmaSend+0x48/0x60
[c0391c10] [c023001c] netpoll_send_skb+0x174/0x1c0
[c0391c50] [c01e45a8] eth_flush_buf+0x44/0x80
[c0391c70] [c0067394] kgdb_handle_exception+0x368/0xe14
[c0391d10] [c000fa50] kgdb_handle_breakpoint+0x4c/0x8c
[c0391d20] [c000ce40] program_check_exception+0x45c/0x600
[c0391d40] [c000f090] ret_from_except_full+0x0/0x4c
[c0391e00] [c0390000] 0xc0390000
[c0391e10] [c003bb0c] tasklet_action+0xa0/0x1d0
[c0391e40] [c003bce8] __do_softirq+0xac/0x1d4
[c0391e80] [c0003ef4] do_softirq+0x5c/0x60
[c0391e90] [c003b820] irq_exit+0xc0/0xc4
[c0391ea0] [c00043f0] do_IRQ+0xa0/0xc4
[c0391ec0] [c000f0dc] ret_from_except+0x0/0x18
[c0391f80] [c000725c] cpu_idle+0x50/0xf0
** [c0391fa0] [c02a95b0] __got2_end+0x80/0x94
[c0391fc0] [c03427f8] start_kernel+0x230/0x2ac
[c0391ff0] [c0000218] skpinv+0x1a8/0x1e4
Kernel panic - not syncing: Recursive entry to debugger
Thanks and Regards
Purushothama.S
[-- Attachment #2: Type: text/html, Size: 4377 bytes --]
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Benjamin Herrenschmidt @ 2009-05-26 9:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, devicetree-discuss, Linux Netdev List
In-Reply-To: <200905261010.31364.arnd@arndb.de>
On Tue, 2009-05-26 at 10:10 +0100, Arnd Bergmann wrote:
> On Monday 25 May 2009, Wolfgang Grandegger wrote:
> > > Right, that makes sense. However, most drivers use the field to store the
> > > physical address, not the iomap token. Maybe there should be a new field
> > > in struct sja1000_priv for the virtual address, but that would be a change
> > > to the base driver, not just to the OF portion.
> >
> > Is that common practice? If yes, I will add a member to store the
> > virtual address to struct sja1000_priv.
>
> I grepped through the network driver for usage of ->base_addr, and
> it's somewhat inconsistent. The majority of the users use it for
> a physical address, but there are also a few that use it for the
> __iomem token.
In addition, iirc, it's not big enough to hold >32 bit physical
addresses on 32-bit platforms no ?
Ben.
> Casts between unsigned long and qualified (__iomem, __user, const, ...)
> pointers do not cause a warning, but can easily lead to bugs when
> another user casts to an unqualified pointer.
>
> Arnd <><
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Arnd Bergmann @ 2009-05-26 9:42 UTC (permalink / raw)
To: David Miller; +Cc: devicetree-discuss, netdev, linuxppc-dev, Greg Ungerer
In-Reply-To: <20090526.022508.238274281.davem@davemloft.net>
On Tuesday 26 May 2009, David Miller wrote:
> It's such a baroque thing, there is no reason to set it at all if you
> ask me. It's only use is to allow ISA and similar primitive bus
> devices to have their I/O ports changed via ifconfig.
My original comment was about the fact that sja1000 was doing
dev->base_addr = (unsigned long)ioremap(phys_addr, size), I didn't
even think about SIOCGIFMAP and command line overrides, but that
surely makes it worse and the driver should be changed to
store the virtual register address in its private data structure.
drivers/net/fec.c seems to have the same problem, which manifests
in a number of ugly casts and direct pointer dereferences in places
where it should do writel() or out_be32().
Arnd <><
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 2/5] Main rewite of the mpc5200 audio DMA code
From: Mark Brown @ 2009-05-26 11:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <20090525221509.21370.70182.stgit@terra>
On Mon, May 25, 2009 at 06:15:09PM -0400, Jon Smirl wrote:
> Rewrite the mpc5200 audio DMA code to support both I2S and AC97.
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
Grant, I'm OK with that if you are?
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Mark Brown @ 2009-05-26 11:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, timur
In-Reply-To: <20090525221406.21370.30326.stgit@terra>
On Mon, May 25, 2009 at 06:15:05PM -0400, Jon Smirl wrote:
> reset retries. Removing the retries makes the driver fail to load about 5% of the time. An oscilliscope is
Please also send a patch sorting this out in the STAC9766 driver as
requested. Other than that and the udelay() thing it looks like we can
merge this now - there's the reset issue and probably other things to
clean up but it'd be better to do those as incremental patches.
> needed to figure out what is going on with failed resets. Both pcm030 and Efika ocasionally fail to reset
> and they use different codec chips.
Like I say, it may be worth checking into the startup of the master
clock for the CODECs, especially if it's an output from the SoC on both
boards.
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Jon Smirl @ 2009-05-26 11:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie, Geert Uytterhoeven
In-Reply-To: <ed82fe3e0905252044w1d0e1f5cqbaf4256b9f749d42@mail.gmail.com>
On Mon, May 25, 2009 at 11:44 PM, Timur Tabi <timur@freescale.com> wrote:
> On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> =A0 =A0 =A0The macro spin_event_timeout() takes a condition and timeout =
value
>
> My patch is already set to go through the powerpc tree, so there's no
> need to repost it here. =A0Please, you changed the title of the patch.
I'm changing the code, I removed the ! on the rc. Geert just asked to
have it changed to an in-line too.
I forgot to add the title line so it used the beginning of the comment.
>
> --
> Timur Tabi
> Linux kernel developer at Freescale
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [net-next-2.6 PATCH v2] can: SJA1000: generic OF platform bus driver
From: Sascha Hauer @ 2009-05-26 11:20 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree-discuss, netdev, linuxppc-dev, Greg Ungerer,
David Miller
In-Reply-To: <200905261042.05967.arnd@arndb.de>
On Tue, May 26, 2009 at 10:42:05AM +0100, Arnd Bergmann wrote:
> On Tuesday 26 May 2009, David Miller wrote:
> > It's such a baroque thing, there is no reason to set it at all if you
> > ask me. It's only use is to allow ISA and similar primitive bus
> > devices to have their I/O ports changed via ifconfig.
>
> My original comment was about the fact that sja1000 was doing
> dev->base_addr = (unsigned long)ioremap(phys_addr, size), I didn't
> even think about SIOCGIFMAP and command line overrides, but that
> surely makes it worse and the driver should be changed to
> store the virtual register address in its private data structure.
>
> drivers/net/fec.c seems to have the same problem, which manifests
> in a number of ugly casts and direct pointer dereferences in places
> where it should do writel() or out_be32().
Ack. I'll prepare a patch for fec.c. Internally the driver already uses
a void __iomem * and writel/readl in -next. There is only one usage
left.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-05-26 11:30 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <4A124202.4010201@doredevelopment.dk>
On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal <eha@doredevelopment.dk> w=
rote:
> This fixes MAL (arbitration lost) bug caused by illegal use of
> RSTA (repeated START) after STOP condition generated after last byte
> of reads. With this patch, it is possible to do an i2c_transfer() with
> additional i2c_msg's following the I2C_M_RD messages.
>
> It still needs to be resolved if it is possible to fix this issue
> by removing the STOP condition after reads in a robust way.
>
> Signed-off-by: Esben Haabendal <eha@doredevelopment.dk>
> ---
> =A0drivers/i2c/busses/i2c-mpc.c | =A0 =A09 +++++++--
> =A01 files changed, 7 insertions(+), 2 deletions(-)
Any blockers to get this accepted?
/Esben
^ permalink raw reply
* Re: [PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
From: Timur Tabi @ 2009-05-26 11:32 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <alpine.LRH.2.00.0905260928320.31893@vixen.sonytel.be>
On Tue, May 26, 2009 at 2:29 AM, Geert Uytterhoeven
<Geert.Uytterhoeven@sonycom.com> wrote:
> static inline function, returning rc, instead of a macro?
It won't work as an inline function ...
>> + =A0 =A0 unsigned long __loops =3D tb_ticks_per_usec * timeout; =A0 =A0=
=A0 =A0 =A0 =A0 =A0 =A0\
>> + =A0 =A0 unsigned long __start =3D get_tbl(); =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
>> + =A0 =A0 while ((rc =3D (condition)) && (tb_ticks_since(__start) <=3D _=
_loops)) \
There's no way to pass a expression to an inline function. It has to
be a macro. Here, the loop evaluates "condition" at every pass. If
this were an inline function, "condition" would be evaluated once when
the function were called, and never again.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Timur Tabi @ 2009-05-26 11:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, broonie, Geert Uytterhoeven
In-Reply-To: <9e4733910905260408x335ac337wc77e4d9ac5027f61@mail.gmail.com>
On Tue, May 26, 2009 at 6:08 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On Mon, May 25, 2009 at 11:44 PM, Timur Tabi <timur@freescale.com> wrote:
>> On Mon, May 25, 2009 at 5:15 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>
>>> =A0 =A0 =A0The macro spin_event_timeout() takes a condition and timeout=
value
>>
>> My patch is already set to go through the powerpc tree, so there's no
>> need to repost it here. =A0Please, you changed the title of the patch.
>
> I'm changing the code,
My code? If you want to make your own version of spin_event_timeout,
then you should change the name and keep it local to your C files.
> I removed the ! on the rc. Geert just asked to
> have it changed to an in-line too.
And Geert's request won't work.
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [alsa-devel] [PATCH V4 0/5] AC97 driver for mpc5200
From: Mark Brown @ 2009-05-26 11:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi, Geert Uytterhoeven
In-Reply-To: <9e4733910905260408x335ac337wc77e4d9ac5027f61@mail.gmail.com>
On Tue, May 26, 2009 at 07:08:52AM -0400, Jon Smirl wrote:
> On Mon, May 25, 2009 at 11:44 PM, Timur Tabi <timur@freescale.com> wrote:
> > My patch is already set to go through the powerpc tree, so there's no
> > need to repost it here. ?Please, you changed the title of the patch.
> I'm changing the code, I removed the ! on the rc. Geert just asked to
> have it changed to an in-line too.
If you're doing that you need make it explicit and submit an incremental
patch against the PowerPC tree. You'll also need to take care of any
affected users there.
^ permalink raw reply
* Re: [PATCH V4 1/5] The macro spin_event_timeout() takes a condition and timeout value
From: Geert Uytterhoeven @ 2009-05-26 11:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel, broonie
In-Reply-To: <ed82fe3e0905260432xdc9556cp74edc723eafe24f7@mail.gmail.com>
On Tue, 26 May 2009, Timur Tabi wrote:
> On Tue, May 26, 2009 at 2:29 AM, Geert Uytterhoeven
> <Geert.Uytterhoeven@sonycom.com> wrote:
>
> > static inline function, returning rc, instead of a macro?
>
> It won't work as an inline function ...
>
> >> + unsigned long __loops = tb_ticks_per_usec * timeout; \
> >> + unsigned long __start = get_tbl(); \
> >> + while ((rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
>
> There's no way to pass a expression to an inline function. It has to
> be a macro. Here, the loop evaluates "condition" at every pass. If
> this were an inline function, "condition" would be evaluated once when
> the function were called, and never again.
You're right, I missed that part. Sorry about that.
However, you can still improve useability by making the macro return the rc,
instead of letting the caller pass it, cfr. wait_event_timeout() and friends.
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox