* slow Kilauea TCP throughput?
From: Donasch, Ingo @ SDS @ 2008-03-12 11:59 UTC (permalink / raw)
To: linuxppc-dev
I have a project where I would like to use the AMC405EX under Linux for
high speed data acquisition. I have the Kilauea board in the lab but
measured only 150Mbit/s TCP throughput (outbound) with iperf. I need
twice of that and actually expecting 3x higher bandwidth from that
architecture.
what is it that I'm missing?
can anybody confirm my results or tell me what am I doing wrong?
any help is appreciated
sincerely
ingo
/home # uname -a
Linux kilauea 2.6.23-g1dfaad37 #1 Wed Nov 21 07:15:18 CET 2007 ppc
unknown
home # ./iperf -c 192.168.1.249 -t60 -i1
------------------------------------------------------------
Client connecting to 192.168.1.249, TCP port 5001 TCP window size: 16.0
KByte (default)
------------------------------------------------------------
[ 5] local 192.168.1.50 port 59035 connected with 192.168.1.249 port
5001
[ 5] 0.0- 1.0 sec 16.6 MBytes 139 Mbits/sec
[ 5] 1.0- 2.0 sec 16.6 MBytes 140 Mbits/sec
...
[ 5] 58.0-59.0 sec 18.0 MBytes 151 Mbits/sec
[ 5] 59.0-60.0 sec 18.0 MBytes 151 Mbits/sec
[ 5] 0.0-60.0 sec 1.04 GBytes 148 Mbits/sec
/home # ifconfig
eth0 Link encap:Ethernet HWaddr 00:06:4B:10:19:5B =20
inet addr:192.168.1.50 Bcast:192.168.1.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:798928 errors:0 dropped:0 overruns:0 frame:0
TX packets:1634765 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000=20
RX bytes:53947650 (51.4 MiB) TX bytes:2341215308 (2.1 GiB)
lo Link encap:Local Loopback =20
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0=20
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
*********************************************************************
The information contained in this e-mail is intended only for the person
or entity to which it is addressed and may contain confidential and / or
privileged material. If you are not the intended recipient of this
e-mail, the use of this information or any disclosure, copying or
distribution is prohibited and may be unlawful.=20
If you received this in error, please contact the sender and delete the
material from any computer.=20
L-3 Communications Security Systems, manufacturer of the eXaminer 3DX
6000 Explosive Detection System - <http://www.l-3com.com>
**********************************************************************
^ permalink raw reply
* Help to make a GPIO driver for MPC8313e EVB with interrupts...
From: Manuel Morillo Marcos @ 2008-03-12 8:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]
Hello all,
I am newbie in this mailing list.
I am using Linux kernel 2.6.18 on a MPC8313e EVB. I am trying to make a
driver example to manage the GPIO port with interrupts.
Is there any source code example anywhere? Besides, I want to manage GPIO0
and GPIO1 as an input and oputput. Does anybody have some source code
example?
That’s all.
TIA.
Manu.
Manuel Morillo Marcos
Ingeniero i+D
Ingeteam T&D
Pol. Ind. Artunduaga · Usausuaga, 7 - 1º
48970 Basauri, Vizcaya, Spain
Tel. +34 946 018 900
Fax +34 946 018 901
cid:image001.gif@01C843B4.192182E0
Este mensaje, y sus anexos, pueden contener información confidencial. Si
usted lo ha recibido por error, le rogamos que lo elimine de su sistema
(incluidas posibles copias), notifique el error al remitente, y se abstenga
de usar, difundir o copiar ninguna parte del mismo. En cualquier caso, la
información mencionada en este mensaje no debe facilitarse a terceras
partes.
En nuestras manos está proteger el medio ambiente. Por favor, no imprima
este mensaje si no es estrictamente necesario.
This message and attachments may contain confidential information. If you
have received this email in error, kindly notify the sender and delete it
from your system. If you are not the intended recipient, you are notified
that using, disseminating, copying all or part of the contents of this email
is strictly prohibited. In any case, the information mentioned herein should
not be disclosed to third parties.
We can all help to protect the environment. Please do not print out this
message unless absolutely necessary.
[-- Attachment #1.2: Type: text/html, Size: 9829 bytes --]
[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 782 bytes --]
^ permalink raw reply
* the question about the internet checksum and CRC on MPC8360?
From: 郭劲 @ 2008-03-12 8:26 UTC (permalink / raw)
To: support.asia; +Cc: linuxppc-embedded
Hi,freescale,
Whether or not the checksum is checked and generated by hardware on QE? We read
the linux kernel code, found that the chechsum is dealed by software, is it true?
How can we let the hardware to deal with the checksum and CRC? then maybe the
speed of TCP package will fast.
follow is from the MPC8360ERM document:
The UEC may programmed to check IP header checksum on the receiver, and generate
IP header checksum on the transmitter.
^ permalink raw reply
* Re: [PATCH 1/4] Ensure that pmu_sys_suspended exists in appropriate configs.
From: Guido Günther @ 2008-03-12 8:38 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <66e63844f95778cdc331d245889ff0ebfe17bbb4.1205279151.git.tony@bakeyournoodle.com>
Hi Tony,
On Wed, Mar 12, 2008 at 10:48:48AM +1100, Tony Breeds wrote:
> pmu_sys_suspended is declared extern when:
> defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
> but only defined when:
> defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
> which is wrong. Lets fix that.
As I wrote, this isn't defined in my config:
# CONFIG_SUSPEND is not set
CONFIG_HIBERNATION=y
Cheers,
-- Guido
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
From: Benjamin Herrenschmidt @ 2008-03-12 6:52 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080312174418.e7206a9b.sfr@canb.auug.org.au>
On Wed, 2008-03-12 at 17:44 +1100, Stephen Rothwell wrote:
> Hi Ben,
>
> On Wed, 12 Mar 2008 17:23:56 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > The iSeries viodasd drivers does some very strange things with
> > scatterlists, one of these causing a BUG_ON to trigger when
> > scatterlist debugging is enabled due to initializing the
> > scatterlist with memset instead of sg_init_table().
> >
> > This fixes it by using sg_init_table(). The rest of the stuff
> > it does to that poor list is still pretty awful but it will work.
>
> Presumably this is also needed in 2.6.24.xx
Possibly, though the problem only occurs when enabling scatterlist
debug, which distros don't do. Is it worth putting in a stable release ?
If yes, I'll submit it as soon as it hits upstream.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
From: Stephen Rothwell @ 2008-03-12 6:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080312062407.492AEDDED5@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
Hi Ben,
On Wed, 12 Mar 2008 17:23:56 +1100 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> The iSeries viodasd drivers does some very strange things with
> scatterlists, one of these causing a BUG_ON to trigger when
> scatterlist debugging is enabled due to initializing the
> scatterlist with memset instead of sg_init_table().
>
> This fixes it by using sg_init_table(). The rest of the stuff
> it does to that poor list is still pretty awful but it will work.
Presumably this is also needed in 2.6.24.xx
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Fix viodasd driver with scatterlist debug
From: Benjamin Herrenschmidt @ 2008-03-12 6:23 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The iSeries viodasd drivers does some very strange things with
scatterlists, one of these causing a BUG_ON to trigger when
scatterlist debugging is enabled due to initializing the
scatterlist with memset instead of sg_init_table().
This fixes it by using sg_init_table(). The rest of the stuff
it does to that poor list is still pretty awful but it will work.
I may look into fixing things in a nicer way some other time.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/block/viodasd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- linux-work.orig/drivers/block/viodasd.c 2008-03-12 10:25:55.000000000 +1100
+++ linux-work/drivers/block/viodasd.c 2008-03-12 10:39:38.000000000 +1100
@@ -528,8 +528,7 @@ static int block_event_to_scatterlist(co
numsg = VIOMAXBLOCKDMA;
*total_len = 0;
- memset(sg, 0, sizeof(sg[0]) * VIOMAXBLOCKDMA);
-
+ sg_init_table(sg, VIOMAXBLOCKDMA);
for (i = 0; (i < numsg) && (rw_data->dma_info[i].len > 0); ++i) {
sg_dma_address(&sg[i]) = rw_data->dma_info[i].token;
sg_dma_len(&sg[i]) = rw_data->dma_info[i].len;
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Tony Breeds @ 2008-03-12 3:41 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linuxppc-dev
In-Reply-To: <E1JZGwo-0000vf-2v@closure.thunk.org>
On Tue, Mar 11, 2008 at 10:44:06PM -0400, Theodore Ts'o wrote:
>
> Hi,
>
> Stephen Rothwell discovered this issue in the linux-next tree:
>
> >Today's powerpc allmodconfig build of linux-next failed with:
> >
> >ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
> >
> >This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 ("ext4:
> >ENOSPC error handling for writing to an uninitialized extent") uses
> >ZERO_PAGE() which on powerpc uses empty_zero_page which is not
> >EXPORT_SYMBOLed on powerpc. I have reverted that commit and a later
> >one (1ae53f35fea49a9013353078e019469551d2ad74 "ext4: zero out
> >small extents when writing to prealloc area.") which depended on it.
>
> Any chance you could get this pushed to Linus ASAP? It would be nice if
> this could get pushed before the merge window, since it could be argued
> that rationalizing whether or not empty_zero_page is exported is a bug
> fix, and anyway this is pretty much a zero-risk patch. Thanks!!
>
> - Ted
>
> >From c3638c5a50de0d360210205625df2ab49508f6d3 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Tue, 11 Mar 2008 22:37:27 -0400
> Subject: [PATCH] ppc: Export empty_zero_page
>
> The empty_zero_page symbol is exported by most other architectures
> (s390, ia64, x86, um), and an upcoming ext4 patch needs it because
> ZERO_PAGE() references empty_zero_page, and we need it to zero out an
> unitialized extents in ext4 files.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> ---
> arch/ppc/kernel/ppc_ksyms.c | 1 +
I suspect you meant arch/*powerpc* arch ppc, wont fix the problem ;P
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* [PATCH] ppc: Export empty_zero_page
From: Theodore Ts'o @ 2008-03-12 2:44 UTC (permalink / raw)
To: linuxppc-dev
Hi,
Stephen Rothwell discovered this issue in the linux-next tree:
>Today's powerpc allmodconfig build of linux-next failed with:
>
>ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
>
>This is because commit dde5f2130096f8469eb1aa1ad250cd2a39fee3f5 ("ext4:
>ENOSPC error handling for writing to an uninitialized extent") uses
>ZERO_PAGE() which on powerpc uses empty_zero_page which is not
>EXPORT_SYMBOLed on powerpc. I have reverted that commit and a later
>one (1ae53f35fea49a9013353078e019469551d2ad74 "ext4: zero out
>small extents when writing to prealloc area.") which depended on it.
Any chance you could get this pushed to Linus ASAP? It would be nice if
this could get pushed before the merge window, since it could be argued
that rationalizing whether or not empty_zero_page is exported is a bug
fix, and anyway this is pretty much a zero-risk patch. Thanks!!
- Ted
>From c3638c5a50de0d360210205625df2ab49508f6d3 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Tue, 11 Mar 2008 22:37:27 -0400
Subject: [PATCH] ppc: Export empty_zero_page
The empty_zero_page symbol is exported by most other architectures
(s390, ia64, x86, um), and an upcoming ext4 patch needs it because
ZERO_PAGE() references empty_zero_page, and we need it to zero out an
unitialized extents in ext4 files.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
arch/ppc/kernel/ppc_ksyms.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/ppc/kernel/ppc_ksyms.c b/arch/ppc/kernel/ppc_ksyms.c
index c353502..418203e 100644
--- a/arch/ppc/kernel/ppc_ksyms.c
+++ b/arch/ppc/kernel/ppc_ksyms.c
@@ -60,6 +60,7 @@ long long __ashrdi3(long long, int);
long long __ashldi3(long long, int);
long long __lshrdi3(long long, int);
+EXPORT_SYMBOL(empty_zero_page);
EXPORT_SYMBOL(clear_pages);
EXPORT_SYMBOL(clear_user_page);
EXPORT_SYMBOL(transfer_to_handler);
--
1.5.4.1.144.gdfee-dirty
^ permalink raw reply related
* [GIT PULL] Please pull spufs.git master branch
From: Jeremy Kerr @ 2008-03-12 2:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev
Hi Paul,
Please do a:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git master
I have a two more bugfixes for the SPU scheduler.
Cheers,
Jeremy
--- 2 commits:
[POWERPC] spufs: don't (ab)use SCHED_IDLE
Jeremy Kerr <jk@ozlabs.org>
arch/powerpc/platforms/cell/spufs/run.c | 3 ++-
arch/powerpc/platforms/cell/spufs/sched.c | 4 ++--
arch/powerpc/platforms/cell/spufs/spufs.h | 1 +
3 files changed, 5 insertions(+), 3 deletions(-)
[POWERPC] spufs: fix rescheduling of non-runnable contexts
Jeremy Kerr <jk@ozlabs.org>
arch/powerpc/platforms/cell/spufs/context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-03-12 0:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: mahuja, linuxppc-dev, linasvepstas
In-Reply-To: <1205280788.7544.2.camel@concordia.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
On Wed, 2008-03-12 at 11:13 +1100, Michael Ellerman wrote:
> On Tue, 2008-03-11 at 17:12 +1100, Paul Mackerras wrote:
> > Manish Ahuja writes:
> >
> > > +#else /* CONFIG_PHYP_DUMP */
> > > +int early_init_dt_scan_phyp_dump(unsigned long node,
> > > + const char *uname, int depth, void *data) { return 0; }
> >
> > This shouldn't be in the header file. Either put it in prom.c (and
> > make it return 1 so the of_scan_flat_dt call doesn't have to go
> > through the entire device tree), or put #ifdef CONFIG_PHYP_DUMP around
> > the of_scan_flat_dt call itself.
>
> It should be in the header file, otherwise we need an #ifdef around the
> call site - which is uglier.
Right I'm an idiot. It is called via a function pointer, so a static
inline (which this should be, but isn't) is no good. An #ifdef around
the call site is probably the least ugly option given that otherwise we
have to have an empty version in the binary.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Interrupt handling documentation
From: Michael Ellerman @ 2008-03-12 0:51 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803111158.48540.laurentp@cse-semaphore.com>
[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]
On Tue, 2008-03-11 at 11:58 +0100, Laurent Pinchart wrote:
> Hi everybody,
>
> is there any documentation describing interrupt handling for the powerpc
> architecture ? I'm writing a driver for a cascaded interrupt controller and
> the only source of information I found was the code.
I don't think there's much documentation.
You might want to look at arch/powerpc/platforms/cell/axon_msi.c, it's a
reasonably simple example of how to setup an irq_host and so on - well I
think so :D
> I'm particularly interested in information about irq hosts (allocation and
> initialisation, especially the map and unmap callbacks) and irq chaining.
> Different drivers seem to implement cascaded irqs differently (for instance
> arch/powerpc/sysdev/uic.c uses setup_irq to register the cascaded irq
> handler, while arch/powerpc/platforms/82xx/pq2ads-pci-pic.c uses
> set_irq_chained_handler) so I'm a bit lost here.
uic.c uses set_irq_chained_handler() now, so that probably answers that
question. I don't think it makes all that much difference if you set it
up by hand, but set_irq_chained_handler() is the neat way to do it.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* The question about the QUICC ENGINE microcode for freescale
From: Russell McGuire @ 2008-03-12 0:20 UTC (permalink / raw)
To: guojin02; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]
Couple of thoughts, is that according to Freescale specs, the QE can only
support TWO 1000Mbit end points. And that is assuming RAW traffic, not
protocol layer processing. Since the 8360E has two QUICC Engines, that is
only 1000Mbits data per Engine. Are you intending to get 1000Mbits TX and RX
on each engine? I think in reality you will be capped at 1000Mbit aggregate
in the RX and TX. I could be wrong, but you might want to run that past a
Freescale FAE, do you have the name of your contact for your area?
This is assuming that you are running at the full speed of the MPC8360E, i.e
both QUICC engines probably pushing 500Mhz. You'll also need to probably be
running DDR2 RAM at MAX speed to achieve these rates, as each skbuf will
have to be dma'd out to external memory. All the early dev boards by
Freescale only used DDR1. As well you'll want to be sure your Coherent
System Bus <CSB> speed is as near max, i.e. 300-333Mhz.
What clock speeds / Frequency of chip are you using to test this? As well
which driver are you using with this test?
As a HW designer for these boards and driver programmer I am just curious
what your HW is looking / configured like?
-Russ
Hi,friends,
I want to realize the high speed TCP package on GETH of MPC8360E,I would
like the speed on both UCC1 and UCC2 for both send and receive TCP
package(big package) up to 1000M bits/sec, so the total internet speed is
4000M bits/sec for MPC8360E.
I tested the internet performance by IPERF test software with the condition
that the core cpu deal with the TCP package,without microcode. I config the
UCC2 down, config UCC1 to send package out to an server PC,no receive,the
speed for UCC1 just only sending package is about 300M bits/sec, and CPU is
100% used. This speed is so slow, is too slow. If I send and recieve at the
same time, the speed is much slower, if I make the UCC2 up, the speed is
much slower and slower.
I do not know how to incrase the internet speed for MPC8360E, somebody told
me, we must use the microcode for QUICC ENGINE.
My question is that where can I download the microcode for QUICC ENGINE and
how to use it? Whether or not this microcode can help me to realize the
4000M bits/sec for TCP package?
[-- Attachment #2: Type: text/html, Size: 9376 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] pseries: phyp dump: reserve-release proof-of-concept
From: Michael Ellerman @ 2008-03-12 0:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: mahuja, linuxppc-dev, linasvepstas
In-Reply-To: <18390.8909.874184.315920@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 903 bytes --]
On Tue, 2008-03-11 at 17:12 +1100, Paul Mackerras wrote:
> Manish Ahuja writes:
>
> > +#else /* CONFIG_PHYP_DUMP */
> > +int early_init_dt_scan_phyp_dump(unsigned long node,
> > + const char *uname, int depth, void *data) { return 0; }
>
> This shouldn't be in the header file. Either put it in prom.c (and
> make it return 1 so the of_scan_flat_dt call doesn't have to go
> through the entire device tree), or put #ifdef CONFIG_PHYP_DUMP around
> the of_scan_flat_dt call itself.
It should be in the header file, otherwise we need an #ifdef around the
call site - which is uglier.
It should definitely return 1 though.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 4/4] Fix arch/powerpc/platforms/powermac/pic.c when !CONFIG_ADB_PMU.
From: Tony Breeds @ 2008-03-11 23:48 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <66e63844f95778cdc331d245889ff0ebfe17bbb4.1205279151.git.tony@bakeyournoodle.com>
When building arch/powerpc/platforms/powermac/pic.c when !CONFIG_ADB_PMU
we get the following warnings:
arch/powerpc/platforms/powermac/pic.c: In function 'pmacpic_find_viaint':
arch/powerpc/platforms/powermac/pic.c:623: warning: label 'not_found' defined but not used
Fix that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/powermac/pic.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pic.c b/arch/powerpc/platforms/powermac/pic.c
index 4073640..829b8b0 100644
--- a/arch/powerpc/platforms/powermac/pic.c
+++ b/arch/powerpc/platforms/powermac/pic.c
@@ -618,9 +618,9 @@ static int pmacpic_find_viaint(void)
if (np == NULL)
goto not_found;
viaint = irq_of_parse_and_map(np, 0);;
-#endif /* CONFIG_ADB_PMU */
not_found:
+#endif /* CONFIG_ADB_PMU */
return viaint;
}
--
1.5.4.3
^ permalink raw reply related
* [PATCH 1/4] Ensure that pmu_sys_suspended exists in appropriate configs.
From: Tony Breeds @ 2008-03-11 23:48 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: Guido Guenther
pmu_sys_suspended is declared extern when:
defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
but only defined when:
defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
which is wrong. Lets fix that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
include/linux/pmu.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/pmu.h b/include/linux/pmu.h
index 4c5f653..b02b57c 100644
--- a/include/linux/pmu.h
+++ b/include/linux/pmu.h
@@ -192,7 +192,7 @@ extern unsigned int pmu_power_flags;
extern void pmu_backlight_init(void);
/* some code needs to know if the PMU was suspended for hibernation */
-#if defined(CONFIG_PM_SLEEP) && defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
extern int pmu_sys_suspended;
#else
/* if power management is not configured it can't be suspended */
--
1.5.4.3
^ permalink raw reply related
* [PATCH 2/4] Fix build of modular drivers/macintosh/apm_emu.c
From: Tony Breeds @ 2008-03-11 23:48 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <66e63844f95778cdc331d245889ff0ebfe17bbb4.1205279151.git.tony@bakeyournoodle.com>
apm_emu.c needs access to pmu_batteries[] and friends. If CONFIG_SUSPEND isn't
defined these symbols aren't exported and the build fails with:
Building modules, stage 2.
ERROR: "pmu_batteries" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_battery_count" [drivers/macintosh/apm_emu.ko] undefined!
ERROR: "pmu_power_flags" [drivers/macintosh/apm_emu.ko] undefined!
Fix that.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/macintosh/via-pmu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index ebec663..0170f55 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -2528,10 +2528,10 @@ EXPORT_SYMBOL(pmu_wait_complete);
EXPORT_SYMBOL(pmu_suspend);
EXPORT_SYMBOL(pmu_resume);
EXPORT_SYMBOL(pmu_unlock);
-#if defined(CONFIG_SUSPEND) && defined(CONFIG_PPC32)
+#if defined(CONFIG_PPC32)
EXPORT_SYMBOL(pmu_enable_irled);
EXPORT_SYMBOL(pmu_battery_count);
EXPORT_SYMBOL(pmu_batteries);
EXPORT_SYMBOL(pmu_power_flags);
-#endif /* CONFIG_SUSPEND && CONFIG_PPC32 */
+#endif /* CONFIG_PPC32 */
--
1.5.4.3
^ permalink raw reply related
* [PATCH 3/4] Fix drivers/macintosh/mediabay.c when !CONFIG_ADB_PMU.
From: Tony Breeds @ 2008-03-11 23:48 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
In-Reply-To: <66e63844f95778cdc331d245889ff0ebfe17bbb4.1205279151.git.tony@bakeyournoodle.com>
When building drivers/macintosh/mediabay.c if CONFIG_ADB_PMU isn't defined we
get:
drivers/built-in.o: In function `media_bay_step':
mediabay.c:(.text+0x92b84): undefined reference to `pmu_suspend'
mediabay.c:(.text+0x92c08): undefined reference to `pmu_resume'
Create empty place holders in that scenario.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
include/linux/pmu.h | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/pmu.h b/include/linux/pmu.h
index b02b57c..cafe98d 100644
--- a/include/linux/pmu.h
+++ b/include/linux/pmu.h
@@ -147,8 +147,15 @@ extern void pmu_wait_complete(struct adb_request *req);
/* For use before switching interrupts off for a long time;
* warning: not stackable
*/
+#if defined(CONFIG_ADB_PMU)
extern void pmu_suspend(void);
extern void pmu_resume(void);
+#else
+static inline void pmu_suspend(void)
+{}
+static inline void pmu_resume(void)
+{}
+#endif
extern void pmu_enable_irled(int on);
--
1.5.4.3
^ permalink raw reply related
* Re: Help needed to describe a custom bus in the device tree
From: David Gibson @ 2008-03-11 22:54 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200803111527.32836.laurentp@cse-semaphore.com>
[-- Attachment #1: Type: text/plain, Size: 6235 bytes --]
On Tue, Mar 11, 2008 at 03:27:26PM +0100, Laurent Pinchart wrote:
> Hi everybody,
>
> the migration process from ARCH=ppc to ARCH=powerpc is easier than I
> thought in some parts, but a few devices are still giving me
> headaches. This should hopefully be one of my last major requests
> for help (I'm sure most of you will be happy to see traffic on this
> list going down when I'll be done :-))
>
> I'm having trouble describing a custom bus named MS bus (completely
> unrelated to a well-known software company) in the device tree. The
> hardware is MPC8248-based and has the following hardware topology.
>
> MPC8248 <-- localbus --> FPGA <-- ms bus --> Custom peripherals
>
> The bus interrupt controller, serial access (SPI) controller and
> status registers are accessed through memory-mapped registers in the
> FPGA. Parallel access to the MS bus is handled transparently by the
> FPGA which handles address mapping.
>
> The FPGA is mapped on the locabus at address 0xf4000000. Bus control
> registers are at 0xf4002000 - 0xf4003000. The parallel bus memory
> window on the localbus is located at 0xf5000000.
>
> My current dts draft describes that topology as follows (unrelated
> devices on the local bus such as flash memory are removed for
> clarity).
>
> localbus@f0010100 {
> compatible = "fsl,pq2-localbus";
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <f0010100 40>;
>
> ranges = <0 0 40000000 01000000
> 2 0 f2000000 00100000
> 3 0 f3000000 00100000
> 4 0 f4000000 00100000
> 5 0 f5000000 00100000>;
>
> fpga@4,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <4 0 0 00010000>;
>
> msbus-arbitrer@2000 {
> compatible = "tbox,cp11-msbus-arbitrer";
> reg = <2000 4>;
> };
>
> msbus_pic: interrupt-controller@2100 {
> compatible = "tbox,cp11-msbus-pic";
> reg = <2100 8>;
> interrupts = <17 2>;
> interrupt-parent = <&cpm_pic>;
> #interrupt-cells = <1>;
> interrupt-controller;
> };
>
> msbus-spi@2200 {
> compatible = "tbox,cp11-msbus-spi";
> reg = <2200 100>;
> interrupts = <18 8>;
> interrupt-parent = <&cpm_pic>;
> };
>
> sdhc@5000 {
> compatible = "tbox,sdhci";
> reg = <5000 1000>;
> interrupts = <16 8>;
> interrupt-parent = <&cpm_pic>;
> };
> };
>
> msbus@5,0 {
> compatible = "tbox,cp11-msbus";
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <1>;
> reg = <5 0 0 00000400>;
> interrupt-parent = <&msbus_pic>;
> };
> };
>
> The device tree reflects the physical topology but makes driver
> access to the bus quite complex. An OF platform device driver
> matching on compatible = "tbox,cp11-msbus" will not have the bus
> FPGA registers described in its device node.
>
> Having a look at the various device trees included in the kernel
> sources, it seems platforms with a PCI bus experience a similar
> problem. To solve it the PCI bus node address and registers describe
> the configuration registers, and the memory window to access PCI
> devices is described by the ranges property. Applying that to my
> custom bus would lead to the following tree.
>
> localbus@f0010100 {
> compatible = "fsl,pq2-localbus";
> #address-cells = <2>;
> #size-cells = <1>;
> reg = <f0010100 40>;
>
> ranges = <0 0 40000000 01000000
> 2 0 f2000000 00100000
> 3 0 f3000000 00100000
> 4 0 f4000000 00100000
> 4 1 f4002000 00000100
> 5 0 f5000000 00100000>;
>
> fpga@4,0 {
> #address-cells = <1>;
> #size-cells = <1>;
> ranges = <4 0 0 00010000>;
>
> msbus_pic: interrupt-controller@2100 {
> compatible = "tbox,cp11-msbus-pic";
> reg = <2100 8>;
> interrupts = <17 2>;
> interrupt-parent = <&cpm_pic>;
> #interrupt-cells = <1>;
> interrupt-controller;
> };
>
> msbus-spi@2200 {
> compatible = "tbox,cp11-msbus-spi";
> reg = <2200 100>;
> interrupts = <18 8>;
> interrupt-parent = <&cpm_pic>;
> };
>
> sdhc@5000 {
> compatible = "tbox,sdhci";
> reg = <5000 1000>;
> interrupts = <16 8>;
> interrupt-parent = <&cpm_pic>;
> };
> };
>
> msbus@4,1 {
> compatible = "tbox,cp11-msbus";
> #address-cells = <1>;
> #size-cells = <1>;
> #interrupt-cells = <1>;
> reg = <4 1 4>;
> interrupt-parent = <&msbus_pic>;
> ranges = <5 0 0 00000400>;
> };
> };
>
> Is this correct ? Is that the best way to describe my custom bus in
> the device tree ?
Your second example looks closer to right. Certainly you should use
'reg' only for bus control registers, and 'ranges' for windows into
the bus address space itself.
The device tree describes hardware from a functional point of view, so
I don't know that it's relevant that all the bus control functions are
implemented in an FPGA. Each of the subnodes are more-or-less
independent devices, so they could just have separate nodes.
Or, if this seems more sensible, you could decide that they're
sufficiently closely related to put them all as one node, with
multiple register blocks listed in the 'reg' property. That would
probably get messy for your PIC at the very least though.
> How would the relationships between the bus and
> its PIC and SPI controller be handled in the drivers ?
If the msbus driver needs to work with the associated PIC and SPI
controllers, then you should put properties in the msbus node giving
their phandles.
> I also don't
> understand how interrupt mappings are supposed to be handled. PCI
> busses have two CPM interrupt lines, one for the PCI PIC and one for
> the PCI bus, with the PCI bus having the CPM PIC as its interrupt
> controller. My bus PIC uses a single interrupt line. Is there some
> documentation explaining how PICs and interrupt mappings should be
> described ?
Are interrupts from devices on the msbus routed over the msbus, or are
they routed independently to the mspic or the cpm PIC?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ARCH=ppc -> ARCH=powerpc : help needed for dts file
From: David Gibson @ 2008-03-11 22:42 UTC (permalink / raw)
To: Philippe De Muyter; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080311114601.GA19189@netgate.macqel>
On Tue, Mar 11, 2008 at 12:46:02PM +0100, Philippe De Muyter wrote:
> Hi David,
>
> On Tue, Mar 11, 2008 at 11:32:49AM +1100, David Gibson wrote:
> > On Sun, Mar 09, 2008 at 11:31:09PM +0100, Philippe De Muyter wrote:
> > > Hi Ben,
> > >
> > > I now have a working linux on my mpc8540 based board, with support for
> > > the compactflash disk and the i2c rtc.
> > >
> > > The network tough, does not work yet. altough the the integrated ethernet
> > > controller (FEC) seems to be recognized. Could it be a problem with the phy ?
> > > I notice that I do not have an entry for gfar_interrupt in /proc/interrupts
> > > on my ethernet-missing linux, while I have one ont the working arch/ppc linux ?
> > > Do I need to give the phy type in the dts file, and how ?
> > >
> > > I would also like to know if it is possible to still get in linux the mac
> > > address known by uboot when using a dts file, and how ?
> >
> > This chiefly depends on whether you're using an old u-boot that
> > doesn't know about the device tree, or a new u-boot which itself
> > supplies a device tree to the kernel.
> >
> > If the old u-boot, you'll need to write a bootwrapper for your
> > platform which reads the bd_t and pokes the right mac addresses into
> > the device tree.
> >
> > If the new u-boot, u-boot itself should put the address into the
> > device tree. If it's not, why it's not is a u-boot question rather
> > than a device tree question.
>
> OK :(
>
> Now back to the first an bigger problem :
> currently, I have an "old" U-boot and I have written myself a dts file.
>
> Problem is : ethernet does not work, but that's not a mac-address problem,
> but something else that I do not understand yet. The symptom is I get
>
> ip route add default via 192.168.85.33 dev eth0
> RTNETLINK answers: Network is unreachable
>
> I surmise this is because my eth0 does not become up, and I surmise
> again this is because there is no driver selected to drive the phy.
>
> In my arch/ppc setup this was automagically handled by fixed@100:1 IIRC
>
> Is there something I can put in my dts file to activate a driver for
> my phy ?
Probably, but how phy selection works is dependent on the ethernet
driver, so I can't help you. You'll need someone familiar with the
driver in question (or read the code and figure it out).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: David Gibson @ 2008-03-11 22:41 UTC (permalink / raw)
To: Rune Torgersen; +Cc: ben, linuxppc-dev, linux-mtd
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B041854B3@ismail.innsys.innovsys.com>
On Tue, Mar 11, 2008 at 10:00:10AM -0500, Rune Torgersen wrote:
> David Gibson wrote:
> > On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> >> We ran ito the same issue.
> >> We did option 3, as it was efinetly the easiest,
> >
> > I think this is the best option in principle.
> >
> >> here is the sram entry in our dts:
> >
> > Except that your implementation of it is not good.
> >
> > You're relying on the old obsolete flash binding with the "probe-type"
> > field. The solution should be adapted to the new approach which uses
> > values in the "compatible" field to indicate various sorts of flash
> > device.
>
> Yea, I know. But it was the easiest way of doing it at the time we did
> our port....
> In a timecrunch, easier is sometimes better than correct. :)
Well sure, but don't expect others to be swayed by your time pressure.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: OF compatible MTD platform RAM driver ?
From: David Gibson @ 2008-03-11 22:40 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: ben, linuxppc-dev, linux-mtd
In-Reply-To: <200803111139.12667.laurentp@cse-semaphore.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
On Tue, Mar 11, 2008 at 11:39:08AM +0100, Laurent Pinchart wrote:
> On Tuesday 11 March 2008 01:45, David Gibson wrote:
> > On Mon, Mar 10, 2008 at 12:00:22PM -0500, Rune Torgersen wrote:
> > > linuxppc-dev-bounces+runet=innovsys.com@ozlabs.org wrote:
[snip]
> > > We ran ito the same issue.
> > > We did option 3, as it was efinetly the easiest,
> >
> > I think this is the best option in principle.
>
> I'll implement that and post a patch after completing the ppc-to-powerpc
> migration.
>
> > > here is the sram entry in our dts:
> >
> > Except that your implementation of it is not good.
> >
> > You're relying on the old obsolete flash binding with the "probe-type"
> > field. The solution should be adapted to the new approach which uses
> > values in the "compatible" field to indicate various sorts of flash
> > device.
>
> What "compatible" values should I use for ROM and RAM mappings ?
That I'm not so sure of. We'll need to find some consensus.
There may be existing IEEE1275 bindings for roms, which we should
investigate. Arguably RAM should be represented by a memory node, but
that's going to get messy for this sort of application.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: of_serial vs legacy serial support with powerpc arch on 405
From: John Linn @ 2008-03-11 22:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20080311170255.4866e51a@zod.rchland.ibm.com>
Thanks for the help Josh. I made some comments in-line.
-----Original Message-----
From: Josh Boyer [mailto:jwboyer@linux.vnet.ibm.com]=20
Sent: Tuesday, March 11, 2008 4:03 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject: Re: of_serial vs legacy serial support with powerpc arch on 405
On Tue, 11 Mar 2008 09:04:27 -0600
"John Linn" <John.Linn@xilinx.com> wrote:
> I've searched and found some threads, but it's still not clear to me.
> I'm working on 405 with powerpc and trying to get UART550 working.
Walnut works. So do Halakeau and Kilauea. Is your serial port
significantly different from those?
>> Requires a shift as the regs are farther apart.
> I know that I need speed, freq, and reg-shift properties in the device
> tree and I have found patches for of_serial.c.
Patches for of_serial.c for what?
>> There was a patch to correct where the spd was assumed to be in the=20
>> device tree and it would bomb out if it wasn't. I was thinking there
was
>> a patch for the reg-shift value also.
=20
> I still don't understand when to use of_serial.c (SERIAL_OF_PLATFORM)
vs
> the legacy support for serial ports. Is there any docs that I'm not
> finding that I should read?
There are no docs. At one time, of_serial was declared as the one true
serial driver, but these days either will do. The benefit of
legacy_serial is that output is enabled earlier in the boot.
> I don't see a way to configure in the legacy support, but I'm using
> SERIAL_OF and having problems. I don't see the console getting enabled
> even though it found the serial port driver.
You need to have CONFIG_PPC_UDBG_16550 set to bring in legacy_serial.
>> Thanks got it working with some mods.
josh
^ permalink raw reply
* RE: of_serial vs legacy serial support with powerpc arch on 405
From: Stephen Neuendorffer @ 2008-03-11 22:14 UTC (permalink / raw)
To: Josh Boyer, John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080311170255.4866e51a@zod.rchland.ibm.com>
Josh,
Specifically, we're trying to get console on of_serial, but there
doesn't seem to be any code to register a console, except in
legacy_serial? But legacy_serial doesn't implement the offsets
necessary for the Xilinx uart16550 cores. Does it seem reasonable to
add code to of_serial.c to register consoles, or is there something else
we're missing here?
Steve
> -----Original Message-----
> From: =
linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.org] On Behalf Of =
Josh
Boyer
> Sent: Tuesday, March 11, 2008 3:03 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: of_serial vs legacy serial support with powerpc arch on
405
>=20
> On Tue, 11 Mar 2008 09:04:27 -0600
> "John Linn" <John.Linn@xilinx.com> wrote:
>=20
> > I've searched and found some threads, but it's still not clear to
me.
> > I'm working on 405 with powerpc and trying to get UART550 working.
>=20
> Walnut works. So do Halakeau and Kilauea. Is your serial port
> significantly different from those?
>=20
> > I know that I need speed, freq, and reg-shift properties in the
device
> > tree and I have found patches for of_serial.c.
>=20
> Patches for of_serial.c for what?
>=20
> > I still don't understand when to use of_serial.c
(SERIAL_OF_PLATFORM) vs
> > the legacy support for serial ports. Is there any docs that I'm not
> > finding that I should read?
>=20
> There are no docs. At one time, of_serial was declared as the one
true
> serial driver, but these days either will do. The benefit of
> legacy_serial is that output is enabled earlier in the boot.
>=20
> > I don't see a way to configure in the legacy support, but I'm using
> > SERIAL_OF and having problems. I don't see the console getting
enabled
> > even though it found the serial port driver.
>=20
> You need to have CONFIG_PPC_UDBG_16550 set to bring in legacy_serial.
>=20
> josh
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: of_serial vs legacy serial support with powerpc arch on 405
From: Josh Boyer @ 2008-03-11 22:02 UTC (permalink / raw)
To: John.Linn; +Cc: linuxppc-dev
In-Reply-To: <20080311150430.153AD3D8066@mail134-sin.bigfish.com>
On Tue, 11 Mar 2008 09:04:27 -0600
"John Linn" <John.Linn@xilinx.com> wrote:
> I've searched and found some threads, but it's still not clear to me.
> I'm working on 405 with powerpc and trying to get UART550 working.
Walnut works. So do Halakeau and Kilauea. Is your serial port
significantly different from those?
> I know that I need speed, freq, and reg-shift properties in the device
> tree and I have found patches for of_serial.c.
Patches for of_serial.c for what?
> I still don't understand when to use of_serial.c (SERIAL_OF_PLATFORM) vs
> the legacy support for serial ports. Is there any docs that I'm not
> finding that I should read?
There are no docs. At one time, of_serial was declared as the one true
serial driver, but these days either will do. The benefit of
legacy_serial is that output is enabled earlier in the boot.
> I don't see a way to configure in the legacy support, but I'm using
> SERIAL_OF and having problems. I don't see the console getting enabled
> even though it found the serial port driver.
You need to have CONFIG_PPC_UDBG_16550 set to bring in legacy_serial.
josh
^ 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