* [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
* [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 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 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
* 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
* 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: 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
* 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
* [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
* [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
* 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] [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] [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
* 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 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
* 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
* 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
* 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
* Using the loop feature of the DMA controller on MPC8544 DS
From: Sebastian Siewior @ 2008-03-12 12:34 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-embedded
Hello,
I have here a MPC8544 DS board and I tried to utilise the dma
controller. For the transfers I need set the [S|D]AHE bit in the Mode
Register. This seems to be implemented but is currently unused in the
driver. I haven't found a way how to set this bit except globally for
the whole channel.
Is it possible to solve this nicely except dedicating one channel for
such an operation?
thanks,
Sebastian
^ permalink raw reply
* 2.6.23.1 and more than 32MB, segfault
From: Petr Žejdl @ 2008-03-12 12:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm using MEMEC board ML300 compatible with 64MB SDRAM available and
vanilla kernel 2.6.23.1. The problem are random segfaults from init,
sometimes before init when using more than 32MB ram. Everything is OK
only when memory is limited to 32MB (mem=32M).
Thank You for any advice.
Petr
^ permalink raw reply
* [BUG] 2.6.25-rc5-mm1 kernel panic with "Exception: 501 " on powerpc
From: Kamalesh Babulal @ 2008-03-12 12:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20080311011434.ad8c8d7d.akpm@linux-foundation.org>
Hi Andrew,
The 2.6.25-rc5-mm1 kernel panics while bootup on powerpc
returning from prom_init
Unable to handle kernel paging request for data at address 0x00000000
Faulting instruction address: 0xc00000000000d5dc
cpu 0x0: Vector: 300 (Data Access) at [c0000000007636e0]
pc: c00000000000d5dc: .do_IRQ+0x74/0x1f4
lr: c00000000000d5a8: .do_IRQ+0x40/0x1f4
sp: c000000000763960
msr: 8000000000001032
dar: 0
dsisr: 40000000
current = 0xc000000000688e60
paca = 0xc000000000689900
pid = 0, comm = swapper
enter ? for help
[c000000000763a00] c000000000004c24 hardware_interrupt_entry+0x24/0x28
--- Exception: 501 (Hardware Interrupt) at c0000000006021b0 .free_bootmem_core+0x94/0xcc
[link register ] c00000000060373c .free_bootmem_with_active_regions+0x78/0xb8
[c000000000763cf0] c000000000602610 .init_bootmem_core+0x5c/0xfc (unreliable)
[c000000000763d80] c0000000005eb68c .do_init_bootmem+0x964/0xaf0
[c000000000763e50] c0000000005e03b0 .setup_arch+0x1a4/0x218
[c000000000763ee0] c0000000005d76bc .start_kernel+0xe8/0x424
[c000000000763f90] c000000000008590 .start_here_common+0x60/0xd0
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: [PATCH] ppc: Export empty_zero_page
From: Theodore Tso @ 2008-03-12 14:42 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev
In-Reply-To: <20080312034110.GT6887@bakeyournoodle.com>
On Wed, Mar 12, 2008 at 02:41:10PM +1100, Tony Breeds wrote:
>
> I suspect you meant arch/*powerpc* arch ppc, wont fix the problem ;P
>
Um, right. I didn't know about this:
> Why: The arch/powerpc tree is the merged architecture for ppc32 and ppc64
> platforms. Currently there are efforts underway to port the remaining
> arch/ppc platforms to the merged tree. New submissions to the arch/ppc
> tree have been frozen with the 2.6.22 kernel release and that tree will
> remain in bug-fix only mode until its scheduled removal. Platforms
> that are not ported by June 2008 will be removed due to the lack of an
> interested maintainer.
Oops, sorry. So should I not bother with a patch to arch/ppc at all?
I guess it's somewhat likely that whatever is left in arch/ppc is not
likely to need to support ext4?
Back with a real patch in just a bit. :-)
- Ted
^ permalink raw reply
* XMD to debug Linux kernel 2.6
From: Ramkumar J @ 2008-03-12 15:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
Hi All,
I need to dump the TLB entries, i-cache and d-cache entries on a ML-403
board ( I use a PowerPc based design) using the Xilinx Parallel-4 Cable.
When I download the zImage.elf using dow command on XMD, I m not able to
access the TLB and cache address special memory mappings as displayed by the
XMD. I suspect that XMD only allows the dump for sections inside the elf
file. If its true, then how to access the sections of kernel.
Could XMD be used to debug a linux kernel by dumping the registers, TLBs,
cache entries,etc. Am I missing anything. Any pointers would be very
helpful.
Thanks and Regards,
Ramkumar
[-- Attachment #2: Type: text/html, Size: 664 bytes --]
^ permalink raw reply
* RE: XMD to debug Linux kernel 2.6
From: John Linn @ 2008-03-12 16:01 UTC (permalink / raw)
To: Ramkumar J, linuxppc-embedded
In-Reply-To: <4f8c3030803120815o7dcf5e8xb74650c8b993d26d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]
Hi Ramkumar,
XMD can definitely be used to help debug a kernel. I use it to dump
registers and to dump memory. I'm not sure on the TLB entries yet but
will check into it. I'm sure that XMD does not handle any virtual
address to physical conversions.
I use it to dump the log buff sometimes when the kernel doesn't come up.
You may need to do a RST and then you need to use the physical address
rather than the virtual address (Address - 0xC0000000).
You can do a help in XMD.
Thanks,
John
________________________________
From: linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+john.linn=xilinx.com@ozlabs.org] On
Behalf Of Ramkumar J
Sent: Wednesday, March 12, 2008 9:15 AM
To: linuxppc-embedded@ozlabs.org
Subject: XMD to debug Linux kernel 2.6
Hi All,
I need to dump the TLB entries, i-cache and d-cache entries on a ML-403
board ( I use a PowerPc based design) using the Xilinx Parallel-4 Cable.
When I download the zImage.elf using dow command on XMD, I m not able to
access the TLB and cache address special memory mappings as displayed by
the XMD. I suspect that XMD only allows the dump for sections inside the
elf file. If its true, then how to access the sections of kernel.
Could XMD be used to debug a linux kernel by dumping the registers,
TLBs, cache entries,etc. Am I missing anything. Any pointers would be
very helpful.
Thanks and Regards,
Ramkumar
[-- Attachment #2: Type: text/html, Size: 11267 bytes --]
^ permalink raw reply
* Re: Using the loop feature of the DMA controller on MPC8544 DS
From: Timur Tabi @ 2008-03-12 15:58 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: linuxppc-embedded, Zhang Wei
In-Reply-To: <20080312123437.GA1589@Chamillionaire.breakpoint.cc>
Sebastian Siewior wrote:
> Hello,
>
> I have here a MPC8544 DS board and I tried to utilise the dma
> controller. For the transfers I need set the [S|D]AHE bit in the Mode
> Register. This seems to be implemented but is currently unused in the
> driver.
Which driver? Zhang's DMA driver?
I haven't looked at Zhang's driver, but I just spotted this code:
case FSL_DMA_IP_85XX:
new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan->toggle_ext_pause = fsl_chan_toggle_ext_pause;
case FSL_DMA_IP_83XX:
new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size;
new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size;
(Don't let the missing "break" from FSL_DMA_IP_85XX fool you)
So it looks like there already is a way to set the SAHE and DAHE bits. I guess
this is what you mean by "seems to be implemented but is currently unused"?
> I haven't found a way how to set this bit except globally for
> the whole channel.
Well, the SAHE bit is part of the MR register, so it can only apply to a whole
channel. This is a hardware limitation.
> Is it possible to solve this nicely except dedicating one channel for
> such an operation?
No.
--
Timur Tabi
Linux kernel developer at Freescale
^ 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