* 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
* 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 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
* 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: 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: [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: 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: 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: [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: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: 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: 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: [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: [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: [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: [RFC][PATCH v5] MPC5121 TLB errata workaround
From: Wolfgang Denk @ 2009-06-06 22:07 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-dev, Paul Mackerras, gunnar
In-Reply-To: <200903161652.09747.david.jander@protonic.nl>
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?
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
One essential to success is that you desire be an all-obsessing one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
^ permalink raw reply
* Re: how can i send real-time signal?
From: Benedikt Spranger @ 2009-06-06 20:51 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
^ permalink raw reply
* [PATCH] powerpc: Enable additional BAT registers in setup_745x_specifics()
From: Gerhard Pircher @ 2009-06-06 21:12 UTC (permalink / raw)
To: linuxppc-dev
Currently the kernel expects the additional four IBAT and DBAT registers
to be available, but doesn't enable these registers on 745x CPUs, which
have them disabled after reset. Thus set the HIGH_BAT_EN bit in HID0
register, if the corresponding MMU feature is defined.
Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
---
arch/powerpc/kernel/cpu_setup_6xx.S | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_6xx.S b/arch/powerpc/kernel/cpu_setup_6xx.S
index 54f767e..1e9949e 100644
--- a/arch/powerpc/kernel/cpu_setup_6xx.S
+++ b/arch/powerpc/kernel/cpu_setup_6xx.S
@@ -239,6 +239,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
ori r11,r11,HID0_SGE | HID0_FOLD | HID0_BHTE
ori r11,r11,HID0_LRSTK | HID0_BTIC
oris r11,r11,HID0_DPM@h
+BEGIN_MMU_FTR_SECTION
+ oris r11,r11,HID0_HIGH_BAT@h
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_USE_HIGH_BATS)
BEGIN_FTR_SECTION
xori r11,r11,HID0_BTIC
END_FTR_SECTION_IFSET(CPU_FTR_NO_BTIC)
--
1.5.6.5
--
GMX FreeDSL mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.!
http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a
^ permalink raw reply related
* Re: [PATCH] Remove machine_is(chrp) from 64-bit kernel
From: Benjamin Herrenschmidt @ 2009-06-06 21:15 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1244306290.3751.2032.camel@macbook.infradead.org>
On Sat, 2009-06-06 at 17:38 +0100, David Woodhouse wrote:
> The CHRP platform type only exists in a 32-bit build. Don't bother
> checking machine_is(chrp) if we're in 64-bit mode.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Isn't the test bogus anyway ? It should be if (!machine_is(powermac))
but is useless since the function is called via:
machine_device_initcall(powermac, pmac_declare_of_platform_devices);
Cheers,
Ben.
> diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
> index 45936c9..c22f7e8 100644
> --- a/arch/powerpc/platforms/powermac/setup.c
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
> {
> struct device_node *np;
>
> +#ifdef CONFIG_PPC32
> if (machine_is(chrp))
> return -1;
> -
> +#endif
> np = of_find_node_by_name(NULL, "valkyrie");
> if (np)
> of_platform_device_create(np, "valkyrie", NULL);
>
^ permalink raw reply
* Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Sachin Sant @ 2009-06-06 19:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Mel Gorman, linuxppc-dev
In-Reply-To: <1244233062.31984.6.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]
Benjamin Herrenschmidt wrote:
> No, Mel's patch is for a different problem and has been fixed upstream
> already. This is more concerning... I'm not sure what's up but would
> you be able to send a disassembly of the hpte_need_flush() function in
> your kernel binary for me to see what access precisely caused the
> fault ?
>
Was able to recreate this with git3 kernel. Here is the disassembly
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32): cpu 0x1: Vector: 300 (Data Access) at [c0000000faa13490]
pc: c000000000038240: .hpte_need_flush+0x1bc/0x2d8
lr: c0000000000380f0: .hpte_need_flush+0x6c/0x2d8
sp: c0000000faa13710
msr: 8000000000009032
dar: c00000005e5e0480
dsisr: 40000000
current = 0xc0000000f9bde3e0
paca = 0xc000000000b72600
pid = 12152, comm = shm-fork
enter ? for help
[c0000000faa13710] c000000000038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable)
[c0000000faa137d0] c000000000039fa4 .huge_ptep_get_and_clear+0x40/0x5c
[c0000000faa13850] c00000000012d044 .__unmap_hugepage_range+0x178/0x2b8
[c0000000faa13940] c00000000012d1d8 .unmap_hugepage_range+0x54/0x88
[c0000000faa139e0] c000000000116f78 .unmap_vmas+0x178/0x8f4
[c0000000faa13b30] c00000000011c690 .unmap_region+0xfc/0x1e4
[c0000000faa13c00] c00000000011de20 .do_munmap+0x2f4/0x38c
[c0000000faa13cc0] c0000000002f6a08 .SyS_shmdt+0xc0/0x188
[c0000000faa13d70] c00000000000c430 .sys_ipc+0x274/0x2fc
[c0000000faa13e30] c000000000008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000021d2dc
SP (fffee026010) is in userspace
1:mon> di $.hpte_need_flush
c000000000038084 fac1ffb0 std r22,-80(r1)
c000000000038088 7c0802a6 mflr r0
c00000000003808c f8010010 std r0,16(r1)
c000000000038090 2fa70000 cmpdi cr7,r7,0
c000000000038094 fb21ffc8 std r25,-56(r1)
c000000000038098 6cc01000 xoris r0,r6,4096
c00000000003809c fb41ffd0 std r26,-48(r1)
c0000000000380a0 7cd93378 mr r25,r6
c0000000000380a4 fb61ffd8 std r27,-40(r1)
c0000000000380a8 7cb62b78 mr r22,r5
c0000000000380ac fb81ffe0 std r28,-32(r1)
......... <SNIP> .........
1:mon>
c000000000038204 38090001 addi r0,r9,1
c000000000038208 78004602 rldicl r0,r0,40,24
c00000000003820c 7c004a14 add r0,r0,r9
c000000000038210 78090220 clrldi r9,r0,40
c000000000038214 2fbd0000 cmpdi cr7,r29,0
c000000000038218 409e0010 bne cr7,c000000000038228 # .hpte_need_flush+0x1a4/0x2d8
c00000000003821c 7929e0e4 rldicr r9,r9,28,35
c000000000038220 7be00120 clrldi r0,r31,36
c000000000038224 4800000c b c000000000038230 # .hpte_need_flush+0x1ac/0x2d8
c000000000038228 792945c6 rldicr r9,r9,40,23
c00000000003822c 7be00600 clrldi r0,r31,24
c000000000038230 7d3f0378 or r31,r9,r0
c000000000038234 7c1cb82e lwzx r0,r28,r23
c000000000038238 3d360001 addis r9,r22,1
c00000000003823c 2f800000 cmpwi cr7,r0,0
c000000000038240 eb898000 ld r28,-32768(r9) <<== +0x1bc should be this
1:mon> r
R00 = 0000000000000000 R16 = 0000000023aa4db0
R01 = c0000000faa13710 R17 = 0000000000000000
R02 = c000000000a9d788 R18 = ffffffffffff9010
R03 = 0000000000000004 R19 = 0000000000000000
R04 = 000003fff0000000 R20 = 0000000000000000
R05 = c00000005e5d8480 R21 = 0000040000000000
R06 = 0000364008000393 R22 = c00000005e5d8480
R07 = 0000000000000001 R23 = 0000000000750000
R08 = 0000000000000004 R24 = 0000000000000000
R09 = c00000005e5e8480 R25 = 0000364008000393
R10 = 000000000003fff0 R26 = c0000000673f0680
R11 = 0000000000000280 R27 = 0000000000000004
R12 = 0000000044022422 R28 = c000000000890430
R13 = c000000000b72600 R29 = 0000000000000001
R14 = 00000000ffffffff R30 = c000000000fe0430
R15 = ffffffffffffffff R31 = 8812ebfff0000000
pc = c000000000038240 .hpte_need_flush+0x1bc/0x2d8
lr = c0000000000380f0 .hpte_need_flush+0x6c/0x2d8
msr = 8000000000009032 cr = 44022422
ctr = c00000000025cc28 xer = 0000000000000001 trap = 300
dar = c00000005e5e0480 dsisr = 40000000
1:mon>
Have attached the complete disassembly.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: disassembly.log --]
[-- Type: text/x-log, Size: 8364 bytes --]
shm-fork 10 10 (64): PASS
shm-fork 10 20 (32): cpu 0x1: Vector: 300 (Data Access) at [c0000000faa13490]
pc: c000000000038240: .hpte_need_flush+0x1bc/0x2d8
lr: c0000000000380f0: .hpte_need_flush+0x6c/0x2d8
sp: c0000000faa13710
msr: 8000000000009032
dar: c00000005e5e0480
dsisr: 40000000
current = 0xc0000000f9bde3e0
paca = 0xc000000000b72600
pid = 12152, comm = shm-fork
enter ? for help
[c0000000faa13710] c000000000038264 .hpte_need_flush+0x1e0/0x2d8 (unreliable)
[c0000000faa137d0] c000000000039fa4 .huge_ptep_get_and_clear+0x40/0x5c
[c0000000faa13850] c00000000012d044 .__unmap_hugepage_range+0x178/0x2b8
[c0000000faa13940] c00000000012d1d8 .unmap_hugepage_range+0x54/0x88
[c0000000faa139e0] c000000000116f78 .unmap_vmas+0x178/0x8f4
[c0000000faa13b30] c00000000011c690 .unmap_region+0xfc/0x1e4
[c0000000faa13c00] c00000000011de20 .do_munmap+0x2f4/0x38c
[c0000000faa13cc0] c0000000002f6a08 .SyS_shmdt+0xc0/0x188
[c0000000faa13d70] c00000000000c430 .sys_ipc+0x274/0x2fc
[c0000000faa13e30] c000000000008534 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000004000021d2dc
SP (fffee026010) is in userspace
1:mon> di $.hpte_need_flush
c000000000038084 fac1ffb0 std r22,-80(r1)
c000000000038088 7c0802a6 mflr r0
c00000000003808c f8010010 std r0,16(r1)
c000000000038090 2fa70000 cmpdi cr7,r7,0
c000000000038094 fb21ffc8 std r25,-56(r1)
c000000000038098 6cc01000 xoris r0,r6,4096
c00000000003809c fb41ffd0 std r26,-48(r1)
c0000000000380a0 7cd93378 mr r25,r6
c0000000000380a4 fb61ffd8 std r27,-40(r1)
c0000000000380a8 7cb62b78 mr r22,r5
c0000000000380ac fb81ffe0 std r28,-32(r1)
c0000000000380b0 eb828d30 ld r28,-29392(r2)
c0000000000380b4 fbc1fff0 std r30,-16(r1)
c0000000000380b8 781b27e2 rldicl r27,r0,36,63
c0000000000380bc fbe1fff8 std r31,-8(r1)
c0000000000380c0 7c7a1b78 mr r26,r3
1:mon>
c0000000000380c4 fae1ffb8 std r23,-72(r1)
c0000000000380c8 789f03e4 rldicr r31,r4,0,47
c0000000000380cc fb01ffc0 std r24,-64(r1)
c0000000000380d0 fba1ffe8 std r29,-24(r1)
c0000000000380d4 f821ff41 stdu r1,-192(r1)
c0000000000380d8 eaed0040 ld r23,64(r13)
c0000000000380dc 7fdcba14 add r30,r28,r23
c0000000000380e0 eb1e0008 ld r24,8(r30)
c0000000000380e4 419e0014 beq cr7,c0000000000380f8 # .hpte_need_flush+0x74/0x2d8
c0000000000380e8 7fe4fb78 mr r4,r31
c0000000000380ec 48000d85 bl c000000000038e70 # .get_slice_psize+0x0/0x38
c0000000000380f0 60000000 nop
c0000000000380f4 7c7b1b78 mr r27,r3
c0000000000380f8 e8028d38 ld r0,-29384(r2)
c0000000000380fc 7fbf0040 cmpld cr7,r31,r0
c000000000038100 419d00a8 bgt cr7,c0000000000381a8 # .hpte_need_flush+0x124/0x2d8
1:mon>
c000000000038104 3800ffff li r0,-1
c000000000038108 3ba00000 li r29,0
c00000000003810c 78000600 clrldi r0,r0,24
c000000000038110 7fbf0040 cmpld cr7,r31,r0
c000000000038114 409d000c ble cr7,c000000000038120 # .hpte_need_flush+0x9c/0x2d8
c000000000038118 e9228d40 ld r9,-29376(r2)
c00000000003811c eba90002 lwa r29,0(r9)
c000000000038120 2fbd0000 cmpdi cr7,r29,0
c000000000038124 e97a0390 ld r11,912(r26)
c000000000038128 409e003c bne cr7,c000000000038164 # .hpte_need_flush+0xe0/0x2d8
c00000000003812c 796b83e4 rldicr r11,r11,16,47
c000000000038130 7be02702 rldicl r0,r31,36,28
c000000000038134 3d200bf6 lis r9,3062
c000000000038138 7c005b78 or r0,r0,r11
c00000000003813c 6129e61b ori r9,r9,58907
c000000000038140 7c0049d2 mulld r0,r0,r9
1:mon>
c000000000038144 78090700 clrldi r9,r0,28
c000000000038148 7800e120 rldicl r0,r0,28,36
c00000000003814c 7d290214 add r9,r9,r0
c000000000038150 38090001 addi r0,r9,1
c000000000038154 7800e120 rldicl r0,r0,28,36
c000000000038158 7c004a14 add r0,r0,r9
c00000000003815c 78090700 clrldi r9,r0,28
c000000000038160 48000038 b c000000000038198 # .hpte_need_flush+0x114/0x2d8
c000000000038164 796b26e4 rldicr r11,r11,4,59
c000000000038168 7be0c220 rldicl r0,r31,24,40
c00000000003816c 3d2000bf lis r9,191
c000000000038170 7c005b78 or r0,r0,r11
c000000000038174 612950d9 ori r9,r9,20697
c000000000038178 7c0049d2 mulld r0,r0,r9
c00000000003817c 78090220 clrldi r9,r0,40
c000000000038180 78004602 rldicl r0,r0,40,24
1:mon>
c000000000038184 7d290214 add r9,r9,r0
c000000000038188 38090001 addi r0,r9,1
c00000000003818c 78004602 rldicl r0,r0,40,24
c000000000038190 7c004a14 add r0,r0,r9
c000000000038194 78090220 clrldi r9,r0,40
c000000000038198 7d200074 cntlzd r0,r9
c00000000003819c 7800d182 rldicl r0,r0,58,6
c0000000000381a0 0b000000 tdnei r0,0
c0000000000381a4 48000070 b c000000000038214 # .hpte_need_flush+0x190/0x2d8
c0000000000381a8 e9228d48 ld r9,-29368(r2)
c0000000000381ac eba90002 lwa r29,0(r9)
c0000000000381b0 2fbd0000 cmpdi cr7,r29,0
c0000000000381b4 409e0034 bne cr7,c0000000000381e8 # .hpte_need_flush+0x164/0x2d8
c0000000000381b8 3d200bf6 lis r9,3062
c0000000000381bc 7be02702 rldicl r0,r31,36,28
c0000000000381c0 6129e61b ori r9,r9,58907
1:mon>
c0000000000381c4 7c0049d2 mulld r0,r0,r9
c0000000000381c8 78090700 clrldi r9,r0,28
c0000000000381cc 7800e120 rldicl r0,r0,28,36
c0000000000381d0 7d290214 add r9,r9,r0
c0000000000381d4 38090001 addi r0,r9,1
c0000000000381d8 7800e120 rldicl r0,r0,28,36
c0000000000381dc 7c004a14 add r0,r0,r9
c0000000000381e0 78090700 clrldi r9,r0,28
c0000000000381e4 48000038 b c00000000003821c # .hpte_need_flush+0x198/0x2d8
c0000000000381e8 3d2000bf lis r9,191
c0000000000381ec 7be0c220 rldicl r0,r31,24,40
c0000000000381f0 612950d9 ori r9,r9,20697
c0000000000381f4 7c0049d2 mulld r0,r0,r9
c0000000000381f8 78090220 clrldi r9,r0,40
c0000000000381fc 78004602 rldicl r0,r0,40,24
c000000000038200 7d290214 add r9,r9,r0
1:mon>
c000000000038204 38090001 addi r0,r9,1
c000000000038208 78004602 rldicl r0,r0,40,24
c00000000003820c 7c004a14 add r0,r0,r9
c000000000038210 78090220 clrldi r9,r0,40
c000000000038214 2fbd0000 cmpdi cr7,r29,0
c000000000038218 409e0010 bne cr7,c000000000038228 # .hpte_need_flush+0x1a4/0x2d8
c00000000003821c 7929e0e4 rldicr r9,r9,28,35
c000000000038220 7be00120 clrldi r0,r31,36
c000000000038224 4800000c b c000000000038230 # .hpte_need_flush+0x1ac/0x2d8
c000000000038228 792945c6 rldicr r9,r9,40,23
c00000000003822c 7be00600 clrldi r0,r31,24
c000000000038230 7d3f0378 or r31,r9,r0
c000000000038234 7c1cb82e lwzx r0,r28,r23
c000000000038238 3d360001 addis r9,r22,1
c00000000003823c 2f800000 cmpwi cr7,r0,0
c000000000038240 eb898000 ld r28,-32768(r9)
1:mon> r
R00 = 0000000000000000 R16 = 0000000023aa4db0
R01 = c0000000faa13710 R17 = 0000000000000000
R02 = c000000000a9d788 R18 = ffffffffffff9010
R03 = 0000000000000004 R19 = 0000000000000000
R04 = 000003fff0000000 R20 = 0000000000000000
R05 = c00000005e5d8480 R21 = 0000040000000000
R06 = 0000364008000393 R22 = c00000005e5d8480
R07 = 0000000000000001 R23 = 0000000000750000
R08 = 0000000000000004 R24 = 0000000000000000
R09 = c00000005e5e8480 R25 = 0000364008000393
R10 = 000000000003fff0 R26 = c0000000673f0680
R11 = 0000000000000280 R27 = 0000000000000004
R12 = 0000000044022422 R28 = c000000000890430
R13 = c000000000b72600 R29 = 0000000000000001
R14 = 00000000ffffffff R30 = c000000000fe0430
R15 = ffffffffffffffff R31 = 8812ebfff0000000
pc = c000000000038240 .hpte_need_flush+0x1bc/0x2d8
lr = c0000000000380f0 .hpte_need_flush+0x6c/0x2d8
msr = 8000000000009032 cr = 44022422
ctr = c00000000025cc28 xer = 0000000000000001 trap = 300
dar = c00000005e5e0480 dsisr = 40000000
1:mon>
^ permalink raw reply
* Re: Missing some interrupts
From: Grant Likely @ 2009-06-06 17:27 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, wael showair
In-Reply-To: <9e4733910906060634k16a2dc6er138820e71cd2c6cf@mail.gmail.com>
On Sat, Jun 6, 2009 at 7:34 AM, Jon Smirl<jonsmirl@gmail.com> wrote:
> On Sat, Jun 6, 2009 at 9:17 AM, wael showair<showair2003@yahoo.com> 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.
>>
>> do u have any suggestions to solve this problem?
>> i want to make sure that i can receive 10 interrupts
>
> Don't do a printk() with interrupts disabled. A printk() takes 1.5ms
> on a mpc5200.
Look at /proc/interrupts instead to see how many IRQs are received.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] powerpc/install: Bail with error code on error in install script
From: Grant Likely @ 2009-06-06 16:44 UTC (permalink / raw)
To: linuxppc-dev, benh, John Linn
In-Reply-To: <20090606163837.17482.56209.stgit@localhost.localdomain>
Oops, forgot one. Here is a new request including the xilinxfb refactoring=
:
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d=
:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascad=
ing
John Linn (1):
fbdev: Add PLB support and cleanup DCR in xilinxfb driver.
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++=
++++
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 ++++--
arch/powerpc/sysdev/xilinx_pci.c | 132 ++++++++
drivers/video/xilinxfb.c | 290 ++++++++++---------
12 files changed, 883 insertions(+), 158 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
On Sat, Jun 6, 2009 at 10:39 AM, Grant Likely<grant.likely@secretlab.ca> wr=
ote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> If anything goes wrong when copying images into the install path, then
> the install script should exit with an error code so that 'make' knows
> about it and tells the user.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> =A0arch/powerpc/boot/install.sh | =A0 =A03 +++
> =A01 files changed, 3 insertions(+), 0 deletions(-)
>
>
> diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
> index 51b2387..98312d1 100644
> --- a/arch/powerpc/boot/install.sh
> +++ b/arch/powerpc/boot/install.sh
> @@ -18,6 +18,9 @@
> =A0# =A0 $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc=
.
> =A0#
>
> +# Bail with error code if anything goes wrong
> +set -e
> +
> =A0# User may have a custom install script
>
> =A0if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec ~/bin/${CROSS=
_COMPILE}installkernel "$@"; fi
>
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc/install: Bail with error code on error in install script
From: Grant Likely @ 2009-06-06 16:39 UTC (permalink / raw)
To: linuxppc-dev, benh
From: Grant Likely <grant.likely@secretlab.ca>
If anything goes wrong when copying images into the install path, then
the install script should exit with an error code so that 'make' knows
about it and tells the user.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
arch/powerpc/boot/install.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/install.sh b/arch/powerpc/boot/install.sh
index 51b2387..98312d1 100644
--- a/arch/powerpc/boot/install.sh
+++ b/arch/powerpc/boot/install.sh
@@ -18,6 +18,9 @@
# $5 and more - kernel boot files; zImage*, uImage, cuImage.*, etc.
#
+# Bail with error code if anything goes wrong
+set -e
+
# User may have a custom install script
if [ -x ~/bin/${CROSS_COMPILE}installkernel ]; then exec ~/bin/${CROSS_COMPILE}installkernel "$@"; fi
^ permalink raw reply related
* [PATCH] Remove machine_is(chrp) from 64-bit kernel
From: David Woodhouse @ 2009-06-06 16:38 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The CHRP platform type only exists in a 32-bit build. Don't bother
checking machine_is(chrp) if we're in 64-bit mode.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
diff --git a/arch/powerpc/platforms/powermac/setup.c b/arch/powerpc/platforms/powermac/setup.c
index 45936c9..c22f7e8 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -518,9 +518,10 @@ static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
+#ifdef CONFIG_PPC32
if (machine_is(chrp))
return -1;
-
+#endif
np = of_find_node_by_name(NULL, "valkyrie");
if (np)
of_platform_device_create(np, "valkyrie", NULL);
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply related
* Please pull -next branch from git.secretlab.ca
From: Grant Likely @ 2009-06-06 16:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Roderick Colenbrander, linuxppc-dev
Hi Ben,
Here are some new commits to support the Xilinx ML507 board for 2.6.31
The following changes since commit baf75b0a42a1b3f6fca80f8949b6141eaff61b0d:
Stephen Rothwell (1):
powerpc/pci: Fix annotation of pcibios_claim_one_bus
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6 next
Grant Likely (1):
powerpc/virtex: refactor intc driver and add support for i8259 cascading
Roderick Colenbrander (3):
powerpc/virtex: Add support for Xilinx PCI host bridge
powerpc/virtex: Add Xilinx ML510 reference design support
powerpc/virtex: Add ml510 reference design device tree
arch/powerpc/boot/dts/virtex440-ml510.dts | 465 +++++++++++++++++++++++++++++
arch/powerpc/include/asm/xilinx_pci.h | 21 ++
arch/powerpc/platforms/40x/virtex.c | 2 +
arch/powerpc/platforms/44x/Kconfig | 13 +-
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 2 +
arch/powerpc/platforms/44x/virtex_ml510.c | 29 ++
arch/powerpc/platforms/Kconfig | 4 +
arch/powerpc/sysdev/Makefile | 1 +
arch/powerpc/sysdev/xilinx_intc.c | 81 ++++--
arch/powerpc/sysdev/xilinx_pci.c | 132 ++++++++
11 files changed, 732 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
create mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/sysdev/xilinx_pci.c
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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