* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-06-06 22:16 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev
In-Reply-To: <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038f45@mail.gmail.com>
Dear John,
In message <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038f45@mail.gmail.com> you wrote:
>
> I think the fec's parent clock is the ipb clock not the ppc core clock.
> Could that be the problem?
I don't think so.
When debugging, I printed the actual clock frequencies, and they
looked as expected. And "arch/powerpc/platforms/512x/clock.c" has
this:
385 static struct clk fec_clk = {
386 .name = "fec_clk",
387 .flags = CLK_HAS_CTRL,
388 .reg = 0,
389 .bit = 13,
390 .calc = unity_clk_calc,
391 .parent = &ips_clk,
392 };
which looks OK to me.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The human mind ordinarily operates at only ten percent of its
capacity. The rest is overhead for the operating system.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: John Rigby @ 2009-06-06 22:27 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20090606221618.701E0832E416@gemini.denx.de>
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]
I noticed the latest BSP from Freescale has this patch:
From: Chen Hongjun <Hong-jun.chen@freecale.com>
Date: Thu, 16 Apr 2009 20:22:52 +0800
Subject: [PATCH] Fixed FEC bug for bluestone board.
Signed-off-by: Chen Hongjun <Hong-jun.chen@freecale.com>
---
drivers/net/fs_enet/mii-fec.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
index 13a7d66..53d01a8 100644
--- a/drivers/net/fs_enet/mii-fec.c
+++ b/drivers/net/fs_enet/mii-fec.c
@@ -208,7 +208,7 @@ static int __devinit fs_enet_mdio_probe(struct of_device
*ofdev,
if (!fec->fecp)
goto out_fec;
- fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
+ fec->mii_speed = ((((ppc_proc_freq + 4999999) / 2500000) / 2) &
0x3F) << 1;
setbits32(&fec->fecp->fec_r_cntrl, FEC_RCNTRL_MII_MODE);
setbits32(&fec->fecp->fec_ecntrl, FEC_ECNTRL_PINMUX |
--
1.5.4
On Sat, Jun 6, 2009 at 4:16 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear John,
>
> In message <4b73d43f0905071909v6e6e8b2el9eb6d4a1b9038f45@mail.gmail.com>
> you wrote:
> >
> > I think the fec's parent clock is the ipb clock not the ppc core clock.
> > Could that be the problem?
>
> I don't think so.
>
> When debugging, I printed the actual clock frequencies, and they
> looked as expected. And "arch/powerpc/platforms/512x/clock.c" has
> this:
>
> 385 static struct clk fec_clk = {
> 386 .name = "fec_clk",
> 387 .flags = CLK_HAS_CTRL,
> 388 .reg = 0,
> 389 .bit = 13,
> 390 .calc = unity_clk_calc,
> 391 .parent = &ips_clk,
> 392 };
>
> which looks OK to me.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> The human mind ordinarily operates at only ten percent of its
> capacity. The rest is overhead for the operating system.
>
[-- Attachment #2: Type: text/html, Size: 2868 bytes --]
^ permalink raw reply related
* Re: [RFC][PATCH v5] MPC5121 TLB errata workaround
From: Benjamin Herrenschmidt @ 2009-06-06 22:42 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, David Jander, gunnar, Paul Mackerras
In-Reply-To: <20090606220723.A38DA832E416@gemini.denx.de>
On Sun, 2009-06-07 at 00:07 +0200, Wolfgang Denk wrote:
> Dear David Jander,
>
> In message <200903161652.09747.david.jander@protonic.nl> you wrote:
> > Complete workaround for DTLB errata in e300c2/c3/c4 processors.
> >
> > Due to the bug, the hardware-implemented LRU algorythm always goes to way
> > 1 of the TLB. This fix implements the proposed software workaround in
> > form of a LRW table for chosing the TLB-way.
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> > Signed-off-by: David Jander <david@protonic.nl>
>
> What is the actual status of this patch?
>
> Patchwork (http://patchwork.ozlabs.org/patch/24502/) says it's
> "superseded" - but by what?
>
> I can't see such code in mainline - what happened to it?
I can see the code in mainline ... but only in the -data- TLB miss
handler, not the instruction one...
Kumar ? Shouldn't we have the workaround in both ?
Cheers,
Ben.
^ permalink raw reply
* Re: Missing some interrupts
From: Benjamin Herrenschmidt @ 2009-06-06 22:47 UTC (permalink / raw)
To: wael showair; +Cc: linuxppc-dev
In-Reply-To: <23901807.post@talk.nabble.com>
On Sat, 2009-06-06 at 06:17 -0700, wael showair wrote:
> Hi All,
> i have a freescale board, that contains MPC8555 processor & DSP-core
> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC of
> the MPC8555 processor.
>
> i test one interrupt from the DSP-core to the MPC8555 processor where i
> configure this interrupt line to be edge-triggered (falling edge) & i
> receive it successfully
> but
> when i generate this interrupt 10 successive times using for loop
> i just receive 2 interrupts?
>
> why can't i receive the 8 other interrupts?
> i print the value of every irq number inside do_IRQ & i found that i receive
> the DSP-interrupt just only twice.
That sounds normal... It all depends what you are doing in the interrupt
handler. If you are doing something for too long, you will "miss" some
interrupts, but that isn't necessarily a problem.
You cannot really rely on getting the exact same number of edge
interrupts that were emitted. At least not unless you have a hard RT
system and can guarantee that you'll always dequeue them fast enough.
Basically, what happens is that in a PIC like the MPIC, if one edge
interrupt is latched, and another one arrives before that first one has
been acked, then the second one is "subsumed", ie, there's only one
input latch.
That should however not be a problem if your driver is written properly.
The idea is that when you get the interrupt, you need to check your
device for -all- the work to do, not only one "item". For example, if
the device fills a ring buffer, you need to check for more than one
entry in there.
The only guarantee you have is that the interrupt will have been acked
before your handler is called. So if another interrupt happens while
your handler is running, you -will- be called again. So you don't need
to worry too much about racing with new incoming messages inside the
interrupt handler itself. But you need to be prepared to pick up more
than one item of work... whatever that is.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-06-06 23:21 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <4b73d43f0906061527p7ca1b301ybcfc576870a168d5@mail.gmail.com>
Dear John,
in message <4b73d43f0906061527p7ca1b301ybcfc576870a168d5@mail.gmail.com> you wrote:
>
> I noticed the latest BSP from Freescale has this patch:
>
> From: Chen Hongjun <Hong-jun.chen@freecale.com>
> Date: Thu, 16 Apr 2009 20:22:52 +0800
> Subject: [PATCH] Fixed FEC bug for bluestone board.
>
> Signed-off-by: Chen Hongjun <Hong-jun.chen@freecale.com>
> ---
> drivers/net/fs_enet/mii-fec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/fs_enet/mii-fec.c b/drivers/net/fs_enet/mii-fec.c
> index 13a7d66..53d01a8 100644
> --- a/drivers/net/fs_enet/mii-fec.c
> +++ b/drivers/net/fs_enet/mii-fec.c
> @@ -208,7 +208,7 @@ static int __devinit fs_enet_mdio_probe(struct of_device
> *ofdev,
> if (!fec->fecp)
> goto out_fec;
>
> - fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
> + fec->mii_speed = ((((ppc_proc_freq + 4999999) / 2500000) / 2) & 0x3F) << 1;
Heh. So we now have 3 versions:
mainline:
fec->mii_speed = ((ppc_proc_freq + 4999999) / 5000000) << 1;
Freescale:
fec->mii_speed = ((((ppc_proc_freq + 4999999) / 2500000) / 2) & 0x3F) << 1;
we:
fec->mii_speed = (((ppc_proc_freq / 1000000) / 30) + 1) << 1;
So what does this give:
ppc_proc_freq mii_speed
mainline freescale we
--------------------------------------------------
50 MHz 0x14 -> 2.5 MHz 0x14 -> 2.5 MHz 0x04 -> 12.50 MHz
100 MHz 0x28 -> 2.5 MHz 0x28 -> 2.5 MHz 0x08 -> 12.50 MHz
150 MHz 0x3C -> 2.5 MHz 0x3C -> 2.5 MHz 0x0C -> 12.50 MHz
200 MHz 0x50 -> 2.5 MHz 0x50 -> 2.5 MHz 0x0E -> 14.29 MHz
250 MHz 0x64 -> 2.5 MHz 0x64 -> 2.5 MHz 0x12 -> 13.89 MHz
300 MHz 0x78 -> 2.5 MHz 0x78 -> 2.5 MHz 0x16 -> 13.36 MHz
316.8 MHz 0x80 -> 2.475 MHz 0x00 -> MDC off 0x16 -> 14.40 MHz
350 MHz 0x8C -> 2.5 MHz 0x0C -> 29.17 MHz 0x18 -> 14.58 MHz
400 MHz 0xA0 -> 2.5 MHz 0x20 -> 12.50 MHz 0x1C -> 14.29 MHz
450 MHz 0xB3 -> 2.5 MHz 0x34 -> 8.654 MHz 0x20 -> 14.06 MHz
500 MHz 0xC8 -> 2.5 MHz 0x48 -> 6.944 MHz 0x22 -> 14.71 MHz
So - the mainline version and what we have don't take into account
that MII_SPEED uses only bit 25...30, i.e. it must fit into the range
from (1 << 1) ... (3F << 1).
The Freescale code tries to address this, but just clipping the data
is incorrect as we can see above.
The funny thing is that the RefMan says:
"...MDC frequency of 1/(mii_speed*2) of the system clock
frequency"
"To be compliant with the IEEE MII specification, the MII_SPEED
field must be programmed with a value that provides an MDC
frequency of less than or equal to 2.5 MHz."
The big question seems to be what the RefMan means when talking about
the "system clock frequency". Obiously it is NOT the CPU clock as
code variants above assume. The examples in "Table 17-24. Programming
Examples for MII_SPEED Register" list "system clock frequencies" of
25, 33, 40 and 50 MHz - which also indiocates that some other
frequency might be referenced here.
But which one is it?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Today's robots are very primitive, capable of understanding only a
few simple instructions such as 'go left', 'go right', and 'build
car'." - John Sladek
^ permalink raw reply
* Re: Missing some interrupts
From: wael showair @ 2009-06-07 0:05 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1244328442.31984.45.camel@pasglop>
Benjamin Herrenschmidt wrote:
>
> On Sat, 2009-06-06 at 06:17 -0700, wael showair wrote:
>> Hi All,
>> i have a freescale board, that contains MPC8555 processor & DSP-core
>> there is a GPIO connecting the DSP-core into an input pin of the OpenPIC
>> of
>> the MPC8555 processor.
>>
>> i test one interrupt from the DSP-core to the MPC8555 processor where i
>> configure this interrupt line to be edge-triggered (falling edge) & i
>> receive it successfully
>> but
>> when i generate this interrupt 10 successive times using for loop
>> i just receive 2 interrupts?
>>
>> why can't i receive the 8 other interrupts?
>> i print the value of every irq number inside do_IRQ & i found that i
>> receive
>> the DSP-interrupt just only twice.
>
> That sounds normal... It all depends what you are doing in the interrupt
> handler. If you are doing something for too long, you will "miss" some
> interrupts, but that isn't necessarily a problem.
>
> You cannot really rely on getting the exact same number of edge
> interrupts that were emitted. At least not unless you have a hard RT
> system and can guarantee that you'll always dequeue them fast enough.
>
> Basically, what happens is that in a PIC like the MPIC, if one edge
> interrupt is latched, and another one arrives before that first one has
> been acked, then the second one is "subsumed", ie, there's only one
> input latch.
>
> That should however not be a problem if your driver is written properly.
> The idea is that when you get the interrupt, you need to check your
> device for -all- the work to do, not only one "item". For example, if
> the device fills a ring buffer, you need to check for more than one
> entry in there.
>
> The only guarantee you have is that the interrupt will have been acked
> before your handler is called. So if another interrupt happens while
> your handler is running, you -will- be called again.
>
> So How can i achieve this? how can i ack the interrupt b 4 calling the
> handler?
>
> So you don't need
> to worry too much about racing with new incoming messages inside the
> interrupt handler itself. But you need to be prepared to pick up more
> than one item of work... whatever that is.
>
> Cheers,
> Ben.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23906763.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: John Rigby @ 2009-06-07 0:08 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <20090606232148.4E0BD832E416@gemini.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
>
>
>
> The big question seems to be what the RefMan means when talking about
> the "system clock frequency". Obiously it is NOT the CPU clock as
> code variants above assume. The examples in "Table 17-24. Programming
> Examples for MII_SPEED Register" list "system clock frequencies" of
> 25, 33, 40 and 50 MHz - which also indiocates that some other
> frequency might be referenced here.
>
> But which one is it?
My best guess is still that it is ips clock. I think I stated in a previous
email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked
at he MII clock on a scope to see how the calculated values compare to
actual?
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> "Today's robots are very primitive, capable of understanding only a
> few simple instructions such as 'go left', 'go right', and 'build
> car'." - John Sladek
>
[-- Attachment #2: Type: text/html, Size: 1675 bytes --]
^ permalink raw reply
* Re: Missing some interrupts
From: wael showair @ 2009-06-07 0:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1244328442.31984.45.camel@pasglop>
> > You cannot really rely on getting the exact same number of edge
> > interrupts that were emitted. At least not unless you have a hard RT
> > system and can guarantee that you'll always dequeue them fast enough.
>
> Yes, my system is a hard RT & i want to receive all the interrupts that
> have been generated exactly
No. Linux is not hard RT. You cannot rely on this in a reliable way,
if for any reason the kernel masks interrupt for too long, which can
happen, you'll see that sort of coalescing happening.
If you -really- can't do anything else, then use critical interrupts
but there is little if no support at all for them in linux. It's your
model that is wrong, you should be able to "poll" the device for how
much work (or interrupts) have been sent and react accordingly
regardless of how many actual IRQ triggers came in via the OpenPIC.
> so who is responsible for acking the interrupt?
At the PIC level, they are acked by the core just before calling into
your handler.
> is there any API in the kernel should i call to do this ack? or
> it is something Dependant on the device that generates the interrupt?
The PIC-level ack is done for you. I don't know what your DSP does.
> Actaully, the device in my case which is a DSP-core is toggles the
> outpin pin of its GPIO that is connected to the input pin of the
> OpenPIC, so how can
> i ack this device? do u have any suggestions?
The Ack isn't your problem. Your model is wrong if you design assuming
you will receive all edge interrupts. Being careful about latencies
etc... (and making sure you toggle for long enough, btw, didn't think
about that one, check your MPIC specs) may improve how many of them you
actually receive, -but- you cannot guarantee that you'll get them all,
so even if you somewhat manager into most of your tests to get 100%,
you'll still have an unreliable system.
You must design your communication between the DSP and Linux such that
the interrupt is purely a wakeup call indicating there's work to do, and
some -other- mean for Linux to actually know how much work is to be
done, the actual number of interrupts is not a proper way to do so.
> So how can i achieve this step? how can i ack the interrupt b 4 i call
> the handler? where can i do this in the kernel?
The kernel does it for you as I said. It's your communication model
that is flawed. Never -ever- rely on edge interrupts in ways that
require them not to be coalesced.
Cheers,
Ben.
> >So you don't need to worry too much about racing with new incoming
> messages inside the
> > interrupt handler itself. But you need to be prepared to pick up more
> > than one item of work... whatever that is.
> >
> > Cheers,
> > Ben.
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> >
> Quoted from:
> http://www.nabble.com/Missing-some-interrupts-tp23901807p23906326.html
--
View this message in context: http://www.nabble.com/Missing-some-interrupts-tp23901807p23906859.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: how can i send real-time signal?
From: wael showair @ 2009-06-07 0:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <23892580.post@talk.nabble.com>
Am Fri, 5 Jun 2009 10:41:56 -0700 (PDT)
schrieb wael showair <showair2003@yahoo.com>:
> My aim is : Each time the DSP-core interrupts the MPC8555 processor, a
> process in the user space will be informed by the arrival of this each
> interrupt.
You should have a look at drivers/uio...
> So i decided to use sw signals, in the ISR of the DSP-core interrupt
> i send a SW signal to the user space process? Is this the best
> solution? are there any better suggestion to achieve my aim?
signals are expensive. Look at the UIO-Framework for a cheaper solution.
preallocated RT-Signals on the other Hand are fragile. Blocking reads
are cheaper and in case of preempt-RT, but not resticted to it, much
easier to handle.
Bene
--
View this message in context: http://www.nabble.com/how-can-i-send-real-time-signal--tp23892580p23906892.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Pekka J Enberg @ 2009-06-07 8:06 UTC (permalink / raw)
To: Sachin Sant; +Cc: Nick Piggin, Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <4A2909E8.6000507@in.ibm.com>
Hi Sachin,
On Fri, 5 Jun 2009, Sachin Sant wrote:
> I can still recreate this bug on a Power 6 hardware with today's next tree.
> I can recreate this problem at will.
> Let me know if i can help in debugging this problem.
Can you please reproduce the issue with this debugging patch applied and
post the result?
Pekka
>From 27189e1e1d2890e98cb029bd1121c86b8c53ecd9 Mon Sep 17 00:00:00 2001
From: Pekka Enberg <penberg@cs.helsinki.fi>
Date: Sun, 7 Jun 2009 11:03:50 +0300
Subject: [PATCH] slqb: debugging
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
---
mm/slqb.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/mm/slqb.c b/mm/slqb.c
index 29bb005..dce39d4 100644
--- a/mm/slqb.c
+++ b/mm/slqb.c
@@ -1382,6 +1382,8 @@ static noinline void *__slab_alloc_page(struct kmem_cache *s,
l = &c->list;
page->list = l;
+ printk(KERN_INFO "%s: cpu=%d, cache_cpu=%p, cache_list=%p\n", __func__, cpu, c, l);
+
spin_lock(&l->page_lock);
l->nr_slabs++;
l->nr_partial++;
@@ -1393,11 +1395,15 @@ static noinline void *__slab_alloc_page(struct kmem_cache *s,
} else {
#ifdef CONFIG_NUMA
struct kmem_cache_node *n;
+ int nid;
- n = s->node_slab[slqb_page_to_nid(page)];
+ nid = slqb_page_to_nid(page);
+ n = s->node_slab[nid];
l = &n->list;
page->list = l;
+ printk(KERN_INFO "%s: nid=%d, cache_node=%p, cache_list=%p\n", __func__, nid, n, l);
+
spin_lock(&n->list_lock);
spin_lock(&l->page_lock);
l->nr_slabs++;
@@ -2028,6 +2034,8 @@ static void free_kmem_cache_nodes(struct kmem_cache *s)
for_each_node_state(node, N_NORMAL_MEMORY) {
struct kmem_cache_node *n;
+ printk(KERN_INFO "%s: cache=%s, node=%d\n", __func__, s->name, node);
+
n = s->node_slab[node];
if (n) {
kmem_cache_free(&kmem_node_cache, n);
@@ -2043,8 +2051,11 @@ static int alloc_kmem_cache_nodes(struct kmem_cache *s)
for_each_node_state(node, N_NORMAL_MEMORY) {
struct kmem_cache_node *n;
+ printk(KERN_INFO "%s: cache=%s, node=%d\n", __func__, s->name, node);
+
n = kmem_cache_alloc_node(&kmem_node_cache, GFP_KERNEL, node);
if (!n) {
+ printk(KERN_INFO "%s: %s: kmem_cache_alloc_node() failed for node %d\n", __func__, s->name, node);
free_kmem_cache_nodes(s);
return 0;
}
--
1.5.6.4
>
^ permalink raw reply related
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfram Sang @ 2009-06-07 8:20 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-dev, Chen Hongjun, Wolfgang Denk
In-Reply-To: <4b73d43f0906061708o763409d0u10a344dfc30e32c1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
> My best guess is still that it is ips clock. I think I stated in a
I fully agree.
a) Table 16-18 in the manual mentions ips and the values given there look much
more like ips than ppc_proc_freq (25MHz?)
b) the excerpt from clock.c Wolfgang posted mentions ips as parent
c) I cannot imagine a divider wrapping around at a frequency which is inside the
range of what the processor is capable of. MII only up to 300MHz seems like a
show-stopper to me :)
d) According to the MPC5200B-manual, ipb _is_ used there (and the linux-driver
adheres to that). I'd guess those two CPUs are related enough to assume it is
ips here.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [BUILD FAILURE 01/04] Next June 04:PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Subrata Modak @ 2009-06-07 14:36 UTC (permalink / raw)
To: fmhess
Cc: sachinp, sfr, Greg KH, linux-kernel, Linuxppc-dev, Ian Abbott,
linux-next, paulus, Geert.Uytterhoeven, geert, David Miller
In-Reply-To: <200906060936.22322.fmhess@speakeasy.net>
On Sat, 2009-06-06 at 09:36 -0400, Frank Mori Hess wrote:
> On Saturday 06 June 2009, Greg KH wrote:
> > Frank and Ian, any thoughts about the vmap call in the
> > comedi_buf_alloc() call? Why is it using PAGE_KERNEL_NOCACHE, and what
> > is the prealloc_buf buffer used for?
>
> It is a circular buffer used to hold data streaming either to or from a
> board (for example when producing an analog output waveform). Reads and
> writes to the device files read/write to the circular buffer, plus a few
> drivers do dma directly to/from it. I personally don't have a problem
> with requiring drivers to have their own dma buffers and making them copy
> data between their private dma buffers and the main circular buffer. I
> guess the original design wanted to support zero-copy dma.
Great to hear that. How about a patch that solves my build problem on
PPC64(the problem seems to be existing for long) ?
Regards--
Subrata
>
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-06-07 20:34 UTC (permalink / raw)
To: John Rigby, Grant Likely; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <4b73d43f0906061708o763409d0u10a344dfc30e32c1@mail.gmail.com>
Dear John,
in message <4b73d43f0906061708o763409d0u10a344dfc30e32c1@mail.gmail.com> you wrote:
>
> > The big question seems to be what the RefMan means when talking about
> > the "system clock frequency". Obiously it is NOT the CPU clock as
...
> > But which one is it?
>
> My best guess is still that it is ips clock. I think I stated in a previous
> email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked
> at he MII clock on a scope to see how the calculated values compare to
> actual?
Yes, it seems very much as if you were right again.
When using ips/ibp everything makes sense, and works.
Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey,
apart from the name these two functions are identical.
Grant - how would you like to see this handled? Should we merge these
two code-wise identical functions into one? What should be the name,
and in which file should we put it?
[We need this clock thing for "drivers/net/fs_enet/mii-fec.c"...]
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Don't think; let the machine do it for you!" - E. C. Berkeley
^ permalink raw reply
* what is /proc/interrupts & /proc/irq/*/spurious mean?
From: wael showair @ 2009-06-08 6:15 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
i have a board shipped with Linux kernel 2.6.27.
i have some problems in interrupts but while i was gathering some info about
the interrupts on my board by
cat /proc/interrupts
CPU0
16: 2525 OpenPIC Level enet_tx
17: 5606 OpenPIC Level enet_rx
18: 0 OpenPIC Level enet_error
21: 3 OpenPIC Level fsldma-channel
22: 3 OpenPIC Level fsldma-channel
23: 3 OpenPIC Level fsldma-channel
25: 3 OpenPIC Level fsldma-channel
26: 461 OpenPIC Level serial
27: 0 OpenPIC Level i2c-mpc
48: 4 OpenPIC Level phy_interrupt
50: 0 OpenPIC Edge DSP-A
52: 11 OpenPIC Edge DSP-B
54: 0 OpenPIC Level FPGA
BAD: 0
actually i m interested in IRQ number 52.
from the previous command: it seems to me OpenPIC has received 11 interrupt
from the device namely DSP-B& this interrupt is edge triggered. Is it
correct?
Also i use:
cat /proc/irq/52/spurious
count 11
unhandled 0
last_unhandled 0 ms
but actually i dont understan its meaning?
does it mean that i received 11 spurious interrupt? i expect this because
the name of the file is spurious.
what does the field unhandled mean?
thanks for ur help.
--
View this message in context: http://www.nabble.com/what-is--proc-interrupts----proc-irq-*-spurious-mean--tp23918722p23918722.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Grandegger @ 2009-06-08 7:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <20090607203406.7C8BC832E416@gemini.denx.de>
Wolfgang Denk wrote:
> Dear John,
>
> in message <4b73d43f0906061708o763409d0u10a344dfc30e32c1@mail.gmail.com> you wrote:
>>> The big question seems to be what the RefMan means when talking about
>>> the "system clock frequency". Obiously it is NOT the CPU clock as
> ...
>>> But which one is it?
>> My best guess is still that it is ips clock. I think I stated in a previous
>> email ipb, but I meant ips. 5200 has ibp and 5121 has ips. Have you looked
>> at he MII clock on a scope to see how the calculated values compare to
>> actual?
>
> Yes, it seems very much as if you were right again.
>
> When using ips/ibp everything makes sense, and works.
>
> Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
> while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey,
> apart from the name these two functions are identical.
>
> Grant - how would you like to see this handled? Should we merge these
> two code-wise identical functions into one? What should be the name,
> and in which file should we put it?
>
> [We need this clock thing for "drivers/net/fs_enet/mii-fec.c"...]
I2C and MSCAN need it as well. What about implementing the more generic
clk api for the MPC5200 as done for the MPC512x?
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c
The MSCAN can also operate with other clock sources, e.g. the external
oscillator (ref_clk). This would avoid cumbersome frequency calculations
from the clock bit settings in the driver as shown below:
/*
* Get the frequency of the external oscillator clock connected
* to the SYS_XTAL_IN pin, or retrun 0 if it cannot be determined.
*/
static unsigned int __devinit mpc52xx_can_xtal_freq(struct device_node *np)
{
struct mpc52xx_cdm __iomem *cdm;
struct device_node *np_cdm;
unsigned int freq;
u32 val;
freq = mpc52xx_find_ipb_freq(np);
if (!freq)
return 0;
/*
* Detemine SYS_XTAL_IN frequency from the clock domain settings
*/
np_cdm = of_find_matching_node(NULL, mpc52xx_cdm_ids);
cdm = of_iomap(np_cdm, 0);
of_node_put(np_cdm);
if (!np_cdm) {
printk(KERN_ERR "%s() failed abnormally\n", __func__);
return 0;
}
if (in_8(&cdm->ipb_clk_sel) & 0x1)
freq *= 2;
val = in_be32(&cdm->rstcfg);
if (val & (1 << 5))
freq *= 8;
else
freq *= 4;
if (val & (1 << 6))
freq /= 12;
else
freq /= 16;
iounmap(cdm);
return freq;
}
Wolfgang.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Wolfgang Denk @ 2009-06-08 8:19 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <4A2CC1DE.5040704@grandegger.com>
Dear Wolfgang,
In message <4A2CC1DE.5040704@grandegger.com> you wrote:
>
> > Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
> > while on MPC5200 we should use mpc52xx_find_ipb_freq() - but hey,
> > apart from the name these two functions are identical.
> >
> > Grant - how would you like to see this handled? Should we merge these
> > two code-wise identical functions into one? What should be the name,
> > and in which file should we put it?
> >
> > [We need this clock thing for "drivers/net/fs_enet/mii-fec.c"...]
>
> I2C and MSCAN need it as well. What about implementing the more generic
> clk api for the MPC5200 as done for the MPC512x?
> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c
Hmmm... I have to admit that I'm biased he. My primary interest at
the moment is obviously just to get the MPC512x stuff into mainline,
and thus I'm not happy about extending the scope of the isse to other
processors.
>From the technical point of view you are right, but I have to admit
that I don't see which direction we should go from here. If we keep in
mind that the same FEC core is also used in various i.MX platforms (=
ARM processors), we probably cannot come up with a clean, unique
implementation that covers all uses.
That's why I asked Grant how to address this. I also added Kumar to
the Cc: list - mayby he has some ideas as well?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The day-to-day travails of the IBM programmer are so amusing to most
of us who are fortunate enough never to have been one - like watching
Charlie Chaplin trying to cook a shoe.
^ permalink raw reply
* Re: mailing list moving
From: Arnd Bergmann @ 2009-06-08 8:56 UTC (permalink / raw)
To: linuxppc-dev, michael; +Cc: Stephen Rothwell, linuxppc-dev-owner, ppc-dev
In-Reply-To: <1244277467.4277.12.camel@concordia>
On Saturday 06 June 2009, Michael Ellerman wrote:
> On Fri, 2009-06-05 at 19:08 +1000, Stephen Rothwell wrote:
> > I do, however, have the old archives, so maybe we can do something ...
>
> We could use the old archive to work out the mapping between old and new
> and write a billion rewrite rules, but it'd probably crash the rewrite
> code - and if not slow the server to a crawl.
>
> So into the too hard basket I think :)
How about just doing a 'wget -r' on the old archive and storing it
in some random directory on lists.ozlabs.org as static files?
Then you only need a single rewrite rule.
Arnd <><
^ permalink raw reply
* Re: [PATCH v4] zone_reclaim is always 0 by default
From: Mel Gorman @ 2009-06-08 11:50 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: Rik van Riel, Christoph Lameter, linux-mm, Zhang, Yanmin, LKML,
linuxppc-dev, Robin Holt, linux-ia64, Andrew Morton, Wu Fengguang
In-Reply-To: <20090604192236.9761.A69D9226@jp.fujitsu.com>
On Thu, Jun 04, 2009 at 07:23:15PM +0900, KOSAKI Motohiro wrote:
>
> Current linux policy is, zone_reclaim_mode is enabled by default if the machine
> has large remote node distance. it's because we could assume that large distance
> mean large server until recently.
>
We don't make assumptions about the server being large, small or otherwise. The
affinity tables reporting a distance of 20 or more is saying "remote memory
has twice the latency of local memory". This is true irrespective of workload
and implies that going off-node has a real penalty regardless of workload.
> Unfortunately, recent modern x86 CPU (e.g. Core i7, Opeteron) have P2P transport
> memory controller. IOW it's seen as NUMA from software view.
> Some Core i7 machine has large remote node distance.
>
If they have large remote node distance, they have large remote node
distance. Now, if they are *lying* and remote memory is not really that
expensive, then prehaps we should be thinking of a per-arch-per-chip
modifier to the distances reported by ACPI.
> Yanmin reported zone_reclaim_mode=1 cause large apache regression.
>
> One Nehalem machine has 12GB memory,
> but there is always 2GB free although applications accesses lots of files.
> Eventually we located the root cause as zone_reclaim_mode=1.
>
> Actually, zone_reclaim_mode=1 mean "I dislike remote node allocation rather than
> disk access", it makes performance improvement to HPC workload.
> but it makes performance degression to desktop, file server and web server.
>
How are you determining a performance regression to desktop? On a
desktop, I would expect processes to be spread on the different CPUs for
each of the nodes. In that case, memory faulted on each CPU should be
faulted locally.
If there are local processes that access a lot of files, then it might end
up reclaiming those to keep memory local and this might be undesirable
but this is explicitly documented;
"It may be beneficial to switch off zone reclaim if the system is used for a
file server and all of memory should be used for caching files from disk. In
that case the caching effect is more important than data locality."
Ideally we could detect if the machine was a file-server or not but no
such luck.
> In general, workload depended configration shouldn't put into default settings.
>
> However, current code is long standing about two year. Highest POWER and IA64 HPC machine
> (only) use this setting.
>
> Thus, x86 and almost rest architecture change default setting, but Only power and ia64
> remain current configuration for backward-compatibility.
>
What about if it's x86-64-based NUMA but it's not i7 based. There, the
NUMA distances might really mean something and that zone_reclaim behaviour
is desirable.
I think if we're going down the road of setting the default, it shouldn't be
per-architecture defaults as such. Other choices for addressing this might be;
1. Make RECLAIM_DISTANCE a variable on x86. Set it to 20 by default, and 5
(or some other sensible figure) on i7
2. There should be a per-arch modifier callback for the affinity
distances. If the x86 code detects the CPU is an i7, it can reduce the
reported latencies to be more in line with expected reality.
3. Do not use zone_reclaim() for file-backed data if more than 20% of memory
overall is free. The difficulty is figuring out if the allocation is for
file pages.
4. Change zone_reclaim_mode default to mean "do your best to figure it
out". Patch 1 would default large distances to 1 to see what happens.
Then apply a heuristic when in figure-it-out mode and using reclaim_mode == 1
If we have locally reclaimed 2% of the nodes memory in file pages
within the last 5 seconds when >= 20% of total physical memory was
free, then set the reclaim_mode to 0 on the assumption the node is
mostly caching pages and shouldn't be reclaimed to avoid excessive IO
Option 1 would appear to be the most straight-forward but option 2
should be doable. Option 3 and 4 could turn into a rats nest and I would
consider those approaches a bit more drastic.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Christoph Lameter <cl@linux-foundation.org>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Robin Holt <holt@sgi.com>
> Cc: "Zhang, Yanmin" <yanmin.zhang@intel.com>
> Cc: Wu Fengguang <fengguang.wu@intel.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/include/asm/topology.h | 6 ++++++
> include/linux/topology.h | 7 +------
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> Index: b/include/linux/topology.h
> ===================================================================
> --- a/include/linux/topology.h
> +++ b/include/linux/topology.h
> @@ -54,12 +54,7 @@ int arch_update_cpu_topology(void);
> #define node_distance(from,to) ((from) == (to) ? LOCAL_DISTANCE : REMOTE_DISTANCE)
> #endif
> #ifndef RECLAIM_DISTANCE
> -/*
> - * If the distance between nodes in a system is larger than RECLAIM_DISTANCE
> - * (in whatever arch specific measurement units returned by node_distance())
> - * then switch on zone reclaim on boot.
> - */
> -#define RECLAIM_DISTANCE 20
> +#define RECLAIM_DISTANCE INT_MAX
> #endif
> #ifndef PENALTY_FOR_NODE_WITH_CPUS
> #define PENALTY_FOR_NODE_WITH_CPUS (1)
> Index: b/arch/powerpc/include/asm/topology.h
> ===================================================================
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -10,6 +10,12 @@ struct device_node;
>
> #include <asm/mmzone.h>
>
> +/*
> + * Distance above which we begin to use zone reclaim
> + */
> +#define RECLAIM_DISTANCE 20
> +
> +
Where is the ia-64-specific modifier to RECAIM_DISTANCE?
> static inline int cpu_to_node(int cpu)
> {
> return numa_cpu_lookup_table[cpu];
>
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [Powerpc/SLQB] Next June 06 : BUG during scsi initialization
From: Sachin Sant @ 2009-06-08 12:12 UTC (permalink / raw)
To: Pekka J Enberg; +Cc: Nick Piggin, Stephen Rothwell, linux-next, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0906071105030.11309@melkki.cs.Helsinki.FI>
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]
Pekka J Enberg wrote:
> Hi Sachin,
>
> On Fri, 5 Jun 2009, Sachin Sant wrote:
>
>> I can still recreate this bug on a Power 6 hardware with today's next tree.
>> I can recreate this problem at will.
>> Let me know if i can help in debugging this problem.
>>
>
> Can you please reproduce the issue with this debugging patch applied and
> post the result?
I had some trouble collecting debug o/p with this patch. Because of the
number of printk's the machine was crawling during boot. It was difficult
to read/collect the o/p. So i inserted a hack as follows such that
slab_alloc_page prints only during the failure.(modprobe scsi-driver)
+ if (strcmp(current->comm, "modprobe"))
+ printk(KERN_INFO "%s: cpu=%d, cache_cpu=%p, cache_list=%p\n", __func__, cpu, c, l);
Attached here is the boot log. Let me know if i can provide any other
information.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: boot-log --]
[-- Type: text/plain, Size: 21505 bytes --]
00
alloc_kmem_cache_nodes: cache=ext2_xattr, node=2
alloc_kmem_cache_nodes: cache=ext2_xattr, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext2_inode_cache, node=2
alloc_kmem_cache_nodes: cache=ext2_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_system_zone, node=2
alloc_kmem_cache_nodes: cache=ext4_system_zone, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_prealloc_space, node=2
alloc_kmem_cache_nodes: cache=ext4_prealloc_space, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_alloc_context, node=2
alloc_kmem_cache_nodes: cache=ext4_alloc_context, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_free_block_extents, node=2
alloc_kmem_cache_nodes: cache=ext4_free_block_extents, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_xattr, node=2
alloc_kmem_cache_nodes: cache=ext4_xattr, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=ext4_inode_cache, node=2
alloc_kmem_cache_nodes: cache=ext4_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=revoke_record, node=2
alloc_kmem_cache_nodes: cache=revoke_record, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=revoke_table, node=2
alloc_kmem_cache_nodes: cache=revoke_table, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=journal_head, node=2
alloc_kmem_cache_nodes: cache=journal_head, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=journal_handle, node=2
alloc_kmem_cache_nodes: cache=journal_handle, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=jbd2_revoke_record, node=2
alloc_kmem_cache_nodes: cache=jbd2_revoke_record, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=jbd2_revoke_table, node=2
alloc_kmem_cache_nodes: cache=jbd2_revoke_table, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=jbd2_journal_head, node=2
alloc_kmem_cache_nodes: cache=jbd2_journal_head, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=jbd2_journal_handle, node=2
alloc_kmem_cache_nodes: cache=jbd2_journal_handle, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
alloc_kmem_cache_nodes: cache=hugetlbfs_inode_cache, node=2
alloc_kmem_cache_nodes: cache=hugetlbfs_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000dbc7b780, cache_list=c0000000dbc7b780
alloc_kmem_cache_nodes: cache=minix_inode_cache, node=2
alloc_kmem_cache_nodes: cache=minix_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=fat_cache, node=2
alloc_kmem_cache_nodes: cache=fat_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=fat_inode_cache, node=2
alloc_kmem_cache_nodes: cache=fat_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
alloc_kmem_cache_nodes: cache=isofs_inode_cache, node=2
alloc_kmem_cache_nodes: cache=isofs_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_node=c0000000de011200, cache_list=c0000000de011200
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de010000, cache_list=c0000000de010000
alloc_kmem_cache_nodes: cache=btrfs_inode_cache, node=2
alloc_kmem_cache_nodes: cache=btrfs_inode_cache, node=3
__slab_alloc_page: nid=2, cache_node=c0000000008c4300, cache_list=c0000000008c4300
__slab_alloc_page: nid=2, cache_00
00
00
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012a00, cache_list=c0000000de012a00
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012a00, cache_list=c0000000de012a00
ehea: eth0: Jumbo frames are disabled
ehea: eth0 -> logical port id #2
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
mice: PS/2 mouse device common for all mice
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de019f00, cache_list=c0000000de019f00
__slab_alloc_page: nid=2, cache_node=c0000000de019900, cache_list=c0000000de019900
__slab_alloc_page: nid=2, cache_node=c0000000de019c00, cache_list=c0000000de019c00
__slab_alloc_page: nid=2, cache_node=c0000000de011200, cache_list=c0000000de011200
__slab_alloc_page: nid=2, cache_node=c0000000de01db00, cache_list=c0000000de01db00
__slab_alloc_page: nid=2, cache_node=c0000000de01a200, cache_list=c0000000de01a200
__slab_alloc_page: nid=2, cache_node=c0000000de01a500, cache_list=c0000000de01a500
__slab_alloc_page: nid=2, cache_node=c0000000de018d00, cache_list=c0000000de018d00
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
EDAC MC: Ver: 2.1.0 Jun 8 2009
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de01e700, cache_list=c0000000de01e700
__slab_alloc_page: nid=2, cache_node=c0000000de012400, cache_list=c0000000de012400
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de011800, cache_list=c0000000de011800
__slab_alloc_page: nid=2, cache_node=c0000000de019f00, cache_list=c0000000de019f00
__slab_alloc_page: nid=2, cache_node=c0000000de019900, cache_list=c0000000de019900
__slab_alloc_page: nid=2, cache_node=c0000000de019c00, cache_list=c0000000de019c00
__slab_alloc_page: nid=2, cache_node=c0000000de011200, cache_list=c0000000de011200
__slab_alloc_page: nid=2, cache_node=c0000000de01db00, cache_list=c0000000de01db00
__slab_alloc_page: nid=2, cache_node=c0000000de01a200, cache_list=c0000000de01a200
__slab_alloc_page: nid=2, cache_node=c0000000de01a500, cache_list=c0000000de01a500
__slab_alloc_page: nid=2, cache_00
00
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de019600, cache_list=c0000000de019600
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de019600, cache_list=c0000000de019600
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de000
00
00
doing fast boot
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de0__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01c000, cache_list=c0000000de01c000
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de000
00
00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_lis__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de019600, cache_list=c0000000de019600
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de000
00
00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de019600, cache_list=c0000000de019600
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de01b100, cache_list=c0000000de01b100
__slab_alloc_page: nid=2, cache_node=c0000000de019600, cache_list=c0000000de019600
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_lis__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de000
00
00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01c300, cache_list=c0000000de01c300
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_list=c0000000de01ba00
__slab_alloc_page: nid=2, cache_node=c0000000de01bd00, cache_list=c0000000de01bd00
__slab_alloc_page: nid=2, cache_node=c0000000de01ba00, cache_lisBUG: spinlock bad magic on CPU#1, modprobe/62
lock: c0000000008c4280, .magic: 7dcc61f0, .owner: || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT/724596736, .owner_cpu: 4095
Call Trace:
[c0000000c7da36d0] [c0000000000116e0] .show_stack+0x6c/0x16c (unreliable)
[c0000000c7da3780] [c000000000365bcc] .spin_bug+0xb0/0xd4
[c0000000c7da3810] [c000000000365e94] ._raw_spin_lock+0x48/0x184
[c0000000c7da38b0] [c0000000005de4f8] ._spin_lock+0x10/0x24
[c0000000c7da3920] [c000000000141240] .__slab_alloc_page+0x410/0x4b4
[c0000000c7da39e0] [c000000000142804] .kmem_cache_alloc+0x13c/0x21c
[c0000000c7da3aa0] [c0000000001431dc] .kmem_cache_create+0x294/0x2a8
[c0000000c7da3b90] [d000000000ea1438] .scsi_init_queue+0x38/0x170 [scsi_mod]
[c0000000c7da3c20] [d000000000ea1334] .init_scsi+0x1c/0xe8 [scsi_mod]
[c0000000c7da3ca0] [c0000000000092c0] .do_one_initcall+0x80/0x19c
[c0000000c7da3d90] [c0000000000c09c8] .SyS_init_module+0xe0/0x244
[c0000000c7da3e30] [c000000000008534] syscall_exit+0x0/0x40
BUG: spinlock lockup on CPU#1, modprobe/62, c0000000008c4280
Call Trace:
[c0000000c7da3760] [c0000000000116e0] .show_stack+0x6c/0x16c (unreliable)
[c0000000c7da3810] [c000000000365f88] ._raw_spin_lock+0x13c/0x184
[c0000000c7da38b0] [c0000000005de4f8] ._spin_lock+0x10/0x24
[c0000000c7da3920] [c000000000141240] .__slab_alloc_page+0x410/0x4b4
[c0000000c7da39e0] [c000000000142804] .kmem_cache_alloc+0x13c/0x21c
[c0000000c7da3aa0] [c0000000001431dc] .kmem_cache_create+0x294/0x2a8
[c0000000c7da3b90] [d000000000ea1438] .scsi_init_queue+0x38/0x170 [scsi_mod]
[c0000000c7da3c20] [d000000000ea1334] .init_scsi+0x1c/0xe8 [scsi_mod]
[c0000000c7da3ca0] [c0000000000092c0] .do_one_initcall+0x80/0x19c
[c0000000c7da3d90] [c0000000000c09c8] .SyS_init_module+0xe0/0x244
[c0000000c7da3e30] [c000000000008534] syscall_exit+0x0/0x40
^ permalink raw reply
* [PATCH] serial: Fix bug of ucc_uart
From: Dave Liu @ 2009-06-08 14:24 UTC (permalink / raw)
To: linux-serial, linuxppc-dev; +Cc: timur
Current ucc_uart driver doesn't work at UART mode,
The TxBD[READY] is not cleared by H/W (RISC engine)
when user send characters to Tx buffer of QE UART.
so, these characters stay on the QE forever, never
go to UART line.
The patch is fixing th bug.
Signed-off-by: Dave Liu <daveliu@freescale.com>
---
drivers/serial/ucc_uart.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
index 7de66c0..e945e78 100644
--- a/drivers/serial/ucc_uart.c
+++ b/drivers/serial/ucc_uart.c
@@ -681,22 +681,27 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
out_be16(&uccup->rccm, 0xc0ff);
/* Configure the GUMR registers for UART */
- if (soft_uart)
+ if (soft_uart) {
/* Soft-UART requires a 1X multiplier for TX */
clrsetbits_be32(&uccp->gumr_l,
UCC_SLOW_GUMR_L_MODE_MASK | UCC_SLOW_GUMR_L_TDCR_MASK |
UCC_SLOW_GUMR_L_RDCR_MASK,
UCC_SLOW_GUMR_L_MODE_UART | UCC_SLOW_GUMR_L_TDCR_1 |
UCC_SLOW_GUMR_L_RDCR_16);
- else
+
+ clrsetbits_be32(&uccp->gumr_h, UCC_SLOW_GUMR_H_RFW,
+ UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX);
+ } else {
clrsetbits_be32(&uccp->gumr_l,
UCC_SLOW_GUMR_L_MODE_MASK | UCC_SLOW_GUMR_L_TDCR_MASK |
UCC_SLOW_GUMR_L_RDCR_MASK,
UCC_SLOW_GUMR_L_MODE_UART | UCC_SLOW_GUMR_L_TDCR_16 |
UCC_SLOW_GUMR_L_RDCR_16);
- clrsetbits_be32(&uccp->gumr_h, UCC_SLOW_GUMR_H_RFW,
- UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX);
+ clrsetbits_be32(&uccp->gumr_h,
+ UCC_SLOW_GUMR_H_TRX | UCC_SLOW_GUMR_H_TTX,
+ UCC_SLOW_GUMR_H_RFW);
+ }
#ifdef LOOPBACK
clrsetbits_be32(&uccp->gumr_l, UCC_SLOW_GUMR_L_DIAG_MASK,
@@ -706,7 +711,7 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
UCC_SLOW_GUMR_H_CDS);
#endif
- /* Enable rx interrupts and clear all pending events. */
+ /* Disable rx interrupts and clear all pending events. */
out_be16(&uccp->uccm, 0);
out_be16(&uccp->ucce, 0xffff);
out_be16(&uccp->udsr, 0x7e7e);
@@ -765,6 +770,10 @@ static void qe_uart_init_ucc(struct uart_qe_port *qe_port)
cecr_subblock = ucc_slow_get_qe_cr_subblock(qe_port->ucc_num);
qe_issue_cmd(QE_INIT_TX_RX, cecr_subblock,
QE_CR_PROTOCOL_UNSPECIFIED, 0);
+ } else {
+ cecr_subblock = ucc_slow_get_qe_cr_subblock(qe_port->ucc_num);
+ qe_issue_cmd(QE_INIT_TX_RX, cecr_subblock,
+ QE_CR_PROTOCOL_UART, 0);
}
}
--
1.5.4
^ permalink raw reply related
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Grant Likely @ 2009-06-08 14:37 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <20090607203406.7C8BC832E416@gemini.denx.de>
On Sun, Jun 7, 2009 at 2:34 PM, Wolfgang Denk<wd@denx.de> wrote:
> Dear John,
>
> in message <4b73d43f0906061708o763409d0u10a344dfc30e32c1@mail.gmail.com> =
you wrote:
>>
>> > The big question seems to be what the RefMan means when talking about
>> > the "system clock frequency". Obiously it is NOT =A0the =A0CPU =A0cloc=
k =A0as
> ...
>> > But which one is it?
>>
>> My best guess is still that it is ips clock. =A0I think I stated in a pr=
evious
>> email ipb, but I meant ips. =A05200 has ibp and 5121 has ips. =A0Have yo=
u looked
>> at he MII clock on a scope to see how the calculated values compare to
>> actual?
>
> Yes, it seems very much as if you were right again.
>
> When using ips/ibp everything makes sense, and works.
>
> Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
> while on MPC5200 we should use =A0mpc52xx_find_ipb_freq() =A0- =A0but =A0=
hey,
> apart from the name these two functions are identical.
>
> Grant - how would you like to see this handled? Should we merge these
> two code-wise identical functions into one? =A0What should be the name,
> and in which file should we put it?
If you want to merge them... Seeing as the function just walks up the
parent nodes looking for the "bus-frequency" property; how about
"mpc5xxx_get_bus_frequency()"? It should go somewhere in
arch/powerpc/sysdev/
Alternately, it is a pretty trivial function; 52xx and 512x could both
have their own versions of it. Whichever makes the most sense to you
(I haven't personally looked at the device driver impact).
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 05/04] *** NOT FOR RELEASE *** HACK *** Work around MII clock issue ***
From: Grant Likely @ 2009-06-08 14:39 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Chen Hongjun
In-Reply-To: <20090608081904.14265832E416@gemini.denx.de>
On Mon, Jun 8, 2009 at 2:19 AM, Wolfgang Denk<wd@denx.de> wrote:
> Dear Wolfgang,
>
> In message <4A2CC1DE.5040704@grandegger.com> you wrote:
>>
>> > Hm... so that means on MPC512x we should use mpc512x_find_ips_freq(),
>> > while on MPC5200 we should use =A0mpc52xx_find_ipb_freq() =A0- =A0but =
=A0hey,
>> > apart from the name these two functions are identical.
>> >
>> > Grant - how would you like to see this handled? Should we merge these
>> > two code-wise identical functions into one? =A0What should be the name=
,
>> > and in which file should we put it?
>> >
>> > [We need this clock thing for "drivers/net/fs_enet/mii-fec.c"...]
>>
>> I2C and MSCAN need it as well. What about implementing the more generic
>> clk api for the MPC5200 as done for the MPC512x?
>
>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/platforms/512x/clock.c
>
> Hmmm... I have to admit that I'm biased he. My =A0primary =A0interest =A0=
at
> the =A0moment is obviously just to get the MPC512x stuff into mainline,
> and thus I'm not happy about extending the scope of the isse to other
> processors.
>
> From the technical point of view you are right, but I have to admit
> that I don't see which direction we should go from here. If we keep in
> mind that the same FEC core is also used in various i.MX platforms (=3D
> ARM processors), we probably cannot come up with a clean, unique
> implementation that covers all uses.
>
> That's why I asked Grant how to address this. =A0I also added Kumar to
> the Cc: list - mayby he has some ideas as well?
I say use the simple approach to get it merged; It can always be changed l=
ater.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* 2.6.30-rc6: Problem with an SSD disk on Freescale PowerPC mpc8315e-rdb, works fine on x86
From: Leon Woestenberg @ 2009-06-08 14:59 UTC (permalink / raw)
To: Linux PPC, Stuart Hughes, Kumar Gala, linux-ide
Hello,
using 2.6.30-rc6, I get the following problems when I read from a SSD
disk, connected to the
3.0 Gb SATA controller of the MPC8315E SoC rev 1.0 running Linux 2.6.30-rc6.
Below see the output from two dd read runs.
The disk behaves fine on a x86 box.
What I can do to (help) pin-point the problem?
Regards,
Leon.
root@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:3e:1e:e0:01/00:00:00:00:00/e0 tag 0 dma 31744 in
res 50/00:3e:e0:df:01/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 01 df e0
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 122910
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 122910
Buffer I/O error on device sda, logical block 122911
Buffer I/O error on device sda, logical block 122912
Buffer I/O error on device sda, logical block 122913
Buffer I/O error on device sda, logical block 122914
Buffer I/O error on device sda, logical block 122915
Buffer I/O error on device sda, logical block 122916
Buffer I/O error on device sda, logical block 122917
Buffer I/O error on device sda, logical block 122918
Buffer I/O error on device sda, logical block 122919
ata2: EH complete
dd: /dev/sda: Input/output error
root@mpc8315e-rdb:~# dd if=/dev/sda of=/dev/null bs=4k
ata2: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:32:9a:6e:00/00:00:00:00:00/e0 tag 0 dma 25600 in
res 50/00:3e:5c:6e:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata2.00: status: { DRDY }
ata2: hard resetting link
ata2: Signature Update detected @ 3528 msecs
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
sd 1:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08
sd 1:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
Descriptor sense data with sense descriptors (in hex):
72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
00 00 6e 5c
sd 1:0:0:0: [sda] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sda, sector 28314
__ratelimit: 52 callbacks suppressed
Buffer I/O error on device sda, logical block 28314
Buffer I/O error on device sda, logical block 28315
Buffer I/O error on device sda, logical block 28316
Buffer I/O error on device sda, logical block 28317
Buffer I/O error on device sda, logical block 28318
Buffer I/O error on device sda, logical block 28319
Buffer I/O error on device sda, logical block 28320
Buffer I/O error on device sda, logical block 28321
Buffer I/O error on device sda, logical block 28322
Buffer I/O error on device sda, logical block 28323
ata2: EH complete
dd: /dev/sda: Input/output error
root@mpc8315e-rdb:~# uname -a
Linux mpc8315e-rdb 2.6.30-rc6 #1 Mon Jun 8 15:54:00 CEST 2009 ppc unknown
root@mpc8315e-rdb:~# hdparm -i /dev/sda
/dev/sda:
Model=Solidata X SSD , FwRev=0955 , SerialNo=<...>
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=128, MultSect=?1?
CurCHS=16383/16/63, CurSects=16514064, LBA=no
IORDY=no, tPIO={min:240,w/IORDY:120}
PIO modes: pio0 pio3 pio4
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=disabled
Drive conforms to: Unspecified: ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6
ATA/ATAPI-7
* signifies the current active mode
--
Leon
^ permalink raw reply
* Re: mkimage for ppc
From: Hollis Blanchard @ 2009-06-08 15:48 UTC (permalink / raw)
To: Avi Kivity; +Cc: u-boot, linuxppc-dev
In-Reply-To: <4A24F20E.2020508@redhat.com>
Sorry, was on vacation. Copying a couple mailing lists...
On Tue, 2009-06-02 at 12:34 +0300, Avi Kivity wrote:
> I am now doing regular build tests on various platforms (kernel only for
> now).
That's great! Much appreciated.
> But ppc wants a mkimage and I don't have one to give it. Where
> can I find it?
mkimage is a tool provided by u-boot
(http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=summary). IIRC
people have discussed the need to include a copy in the kernel source in
the past, but apparently nothing was ever done about it.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: SD card over (xilinx_)SPI, timeout error while CID
From: Lorenz Kolb @ 2009-06-08 15:14 UTC (permalink / raw)
To: Peter Korsgaard
Cc: joachim, dbrownell, Joachim Foerster, lorenz, linuxppc-dev,
john.linn
In-Reply-To: <87bpp1xulr.fsf@macbook.be.48ers.dk>
Peter Korsgaard wrote:
>>>>>> "Joachim" == Joachim Foerster <JOFT@gmx.de> writes:
>>>>>>
>
> Hi,
>
> Joachim> Any hints? Does anybody use SD card support with
> Joachim> mmc_spi+xilinx_spi ?
>
> I don't, but have you compared the spi signals on a scope in the 2
> setups? Is timing significantly different?
>
>
Hi,
we just tried to find differences for the timing with the oszi:
Here are to screenshots taken from the initial first few data bytes that are
communicated. At least at that time there does not seem to be any timing
issue.
2.6.26 using arch ppc and virtex-devices:
http://img145.imageshack.us/img145/9662/2626virtexdevices.jpg
2.6.29.4 using arch powerpc:
http://img145.imageshack.us/img145/9847/2629devtree.jpg
For explanation:
yellow = chan 1 = MOSI = trigger
green = chan 2 = chipselect not
blue = chan 3 = clock
red = chan 4 = MOSI
Looks like we're gonna have to switch to a logic analyzer
(with spi-mode sdcard analyzing support) as we cannot see any differences
in the short timeframe our oszi does measure, though checking the timing
does not look too promising.
We even configured the Xilinx-SPI core to go down to ~780 kHz just to be
safe,
did not help either.
Regards,
Lorenz
^ 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