* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-31 9:31 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20051028203727.76C2C353E3E@atlas.denx.de>
On Friday 28 October 2005 22:37, Wolfgang Denk wrote:
>[...]
> > They are just integers with fixed start values. These are in the loop, so
> > it's not an empty loop and hopefully the compiler won't out-optimize it
> > so easily (that is of course without specifying any optimization flags).
> > Please don't tell me it's a lousy benchmark, because I already know that!
> > Be it as lousy as it is, I shouldn't get _those_ results IMHO.
>
> Indeed, you should not get such results. If you compare with the
> lmbench results of our 2.4/2.6 comparison, you will notice that we
> did NOT see such behaviour. There was a perfromnce degradation for
> pure integer tests, due to increased system overhead, but far from a
> factor of 2.
> See http://www.denx.de/wiki/pub/Know/Linux24vs26/lmbench_results
I have seen them, and my conclusion is: Your kernel was working ok, while
mine, a newer one, is broken.
As you can see in the other e-mail I just posted (replying to Marcelo), at
least the CPU cache seems to be disabled. Might this have something to do
with processor model (mis-) identification?
I had to apply the "ppc_sys: do not BUG if system ID is unknown" patch from
Marcelo Tosatti a few days back in order to be able to boot in the first
place. I had a look at ppc_sys system identification for 8xx and it looked a
little bit nonsensical to me, since all 8xx report the same ID. Maybe the
intention was to set the ID "by hand" in board support and setup.
Problem is: there is still no real board-support infrastructure for mpc8xx,
like there is for mpc82xx for example. What are the plans for 8xx? Should I
try to emulate what others have done for some PQ2 platforms, i.e. create a
arch/ppc/platforms/myplatform.c file and implement board_init()?
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: exception vectors
From: Ingmar @ 2005-10-31 9:58 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev list
In-Reply-To: <2828913a7186e850887d415a8311dc44@penguinppc.org>
On Sun, 30 Oct 2005 20:28:49 -0600, Hollis Blanchard wrote
> On Oct 30, 2005, at 6:35 PM, Ingmar wrote:
> >
> > I am trying to overwrite the exception vector space of an ibook G4 :).
>
> Why?
>
For my thesis project I am porting the Minix (v3) OS.
> > I have set up (for every exception) a small piece of code, that's a
> > prefix of a
> > handler to be called. My problem is, that writing the small chunks
> > of code to
> > the exception vector space gives no problem(so it seams) but writing
> > all the
> > pieces of code as one chunk gives a exception [dsi, dsisr 0x42000000],
> > this
> > indicates a store problem.
>
> Code please. You're just calling memcpy?
I have done different methods (lots of code),
- as a test just setting the memory, with memset,
- custom copying word by word, flushing the cache while going,
- flushing the cache afterwards,
the results are not always what I excected, the memset works if I don't set to
much like from 0x0 – 0x200. The copying would be the complete block.
> > I have tried different modes of copying, mmu on/off, also chanced the
> > WING bits,
> > switched the exception prefix on.
>
> You could not have gotten a DSI if you disabled the MMU...
Oke, than this is one I am sure of now, thanks :)
> > I don't believe putting the exception vectors to there place one by
> > one is the
> > right way, in the Linux kernel the kernel get relocated and the code
> > comes into
> > place. I have taken this as an example, unfortunately to to result :(..
>
> So you are not trying to overwrite Linux's functioning exception
> handlers, but rather trying to write your own OS?
Yes :).
> > - Am I overlooking something?
> > - Is the a standard way to overwrite the exception vector space of
> > a powerpc?
>
> Do you think this is a common task? :)
No the task maybe not, but the method could be,
- I am sure (now) that the mmu must be off,
- copying must be done with flushing the caches,
> -Hollis
Thanks
Ingmar.
^ permalink raw reply
* [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Heiko Schocher @ 2005-10-31 10:53 UTC (permalink / raw)
To: linuxppc-dev
Hello,
on a MPC8260 based Board, i succesfully wrote chars
over a SCC in UART Mode, but after i closed the port
and opened it again, the write() call failed!
(cpm_uart_tx_empty()returns continually 0).
The following Patch will fix this problem.
thanks
Heiko Schocher
---
drivers/serial/cpm_uart/cpm_uart_core.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..4c3ea05 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -445,6 +445,10 @@ static void cpm_uart_shutdown(struct uar
/* Shut them really down and reinit buffer descriptors */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
cpm_uart_initbd(pinfo);
+ if (IS_SMC(pinfo))
+ cpm_uart_init_smc(pinfo);
+ else
+ cpm_uart_init_scc(pinfo);
}
}
^ permalink raw reply related
* [PATCH] ppc32: fix: swallowed chars when booting.
From: Heiko Schocher @ 2005-10-31 11:29 UTC (permalink / raw)
To: linuxppc-dev
Hello,
on a MPC8260 based Board, i lost some chars on the SMC2
Console, when booting the kernel. The following Patch
will fix this.
thanks
Heiko Schocher
Signed-off-by: Heiko Schocher <hs@denx.de>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 4c3ea05..ac05ee9 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -557,6 +557,11 @@ static void cpm_uart_set_termios(struct
* present.
*/
prev_mode = smcp->smc_smcmr;
+ /* Wait for all the BDs marked sent */
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(4);
+ }
smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART;
smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN));
} else {
^ permalink raw reply related
* Re: ayuda
From: Juan P. Holder @ 2005-10-31 12:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BAY14-F28EE9562AD50489238A8C8B96D0@phx.gbl>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
Buenas como va, yo hace poco compre un ibook G4, instale debian sarge
para ppc y anduvo muy bien salvo en algunos detalles, lo que voy a
probar que me dijeron es genial es UBUNTU, SI PODES probalo.. yo lo
probare estos dias y te cuento!
Jean Pierre
El dom, 30-10-2005 a las 00:26 +0000, Doug Carrillo escribió:
> Hola, tengo una G3 PPC, deseo instalar linux
>
> Cual distribucion me sirve?
>
> _________________________________________________________________
> MSN Amor: busca tu ½ naranja http://latam.msn.com/amor/
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 1344 bytes --]
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: Mark Chambers @ 2005-10-31 12:58 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200510310921.34696.david.jander@protonic.nl>
>
> I have made another test in the meantime, trying to check if cache is
working.
> <snip>
> No, sir, no cache detected !
>
> Where do I have to look now?
>
Could the cache be in writethrough mode? (Instead of writeback)
Mark Chambers
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-31 13:08 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <003501c5de1a$be79b390$0301a8c0@chuck2>
On Monday 31 October 2005 13:58, Mark Chambers wrote:
>[...]
> > No, sir, no cache detected !
> >
> > Where do I have to look now?
>
> Could the cache be in writethrough mode? (Instead of writeback)
Good point. I just checked the same test, but reading instead of writing. Same
result, no cache detected.
I know how to change cache policy in u-boot, but does the kernel change that?
If so, where?
Greetings,
--
David Jander
^ permalink raw reply
* audit_sysctl_exit can only be used with CONF_AUDIT_SYSCTL
From: Horms @ 2005-10-31 13:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Andrew Morton, david
This section of code calls .audit_syscal_exit,
but is inside CONFIG_AUDIT, so it will fail to build
if CONFIG_AUDITSYSCALL is not defined.
After discussion with David Woodhouse, change the
ifdef to CONFIG_AUDITSYSCALL
Signed-off-by: Horms <horms@verge.net.au>
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 984a106..2d22bf0 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -279,7 +279,7 @@ _GLOBAL(ppc32_rt_sigsuspend)
bne syscall_exit
/* If sigsuspend() returns zero, we are going into a signal handler. We
may need to call audit_syscall_exit() to mark the exit from sigsuspend() */
-#ifdef CONFIG_AUDIT
+#ifdef CONFIG_AUDITSYSCALL
ld r3,PACACURRENT(r13)
ld r4,AUDITCONTEXT(r3)
cmpdi 0,r4,0
^ permalink raw reply related
* Re: NFS can not mount (linuxppc2.2.4 mpc5200 lxt971)
From: Tore Martin Hagen @ 2005-10-31 14:13 UTC (permalink / raw)
To: xiay; +Cc: linuxppc-embedded
In-Reply-To: <200510281054.AA34079032@NARI-RELAYS.COM>
ÏÄÓê wrote:
>eth0: config: auto-negotiation on, 100HDX, 10HDX.
>IP-Config: Complete:
> device=eth0, addr=198.87.102.211, mask=255.255.255.0, gw=198.87.102.140,
> host=oops, domain=, nis-domain=(none),
> bootserver=198.87.102.140, rootserver=198.98.102.140, rootpath=
>
>
Hi
Check out your DHCP server. You don't get the rootpath from it.
/etc/dhcpd.conf should contain
option root-path "/local/Mpc8266ads/Box0/root";
or something similar.
also take a look in /var/log/messages to pinpoint the problem.
/Tore Hagen
^ permalink raw reply
* Re: [PATCH] ppc32: Add missing initrd header on ppc440
From: Matt Porter @ 2005-10-31 14:41 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200510311029.13432.sr@denx.de>
On Mon, Oct 31, 2005 at 11:29:13AM +0200, Stefan Roese wrote:
> By the way: What is the current status of the pending 4xx patches. Are they
> going in in this 2-week merge window?
The PPC44x U-Boot cleanup was queued and merged. The rest of PPC4xx
cleanup patches are now pending with akpm and will probably be queued
for Linus shortly. There will be no problem with them being merged.
-Matt
^ permalink raw reply
* Re: Kernel 2.6 on MPC8xx performance trouble...
From: David Jander @ 2005-10-31 15:29 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200510311408.41691.david.jander@protonic.nl>
On Monday 31 October 2005 14:08, David Jander wrote:
> On Monday 31 October 2005 13:58, Mark Chambers wrote:
> >[...]
> >
> > > No, sir, no cache detected !
> > >
> > > Where do I have to look now?
> >
> > Could the cache be in writethrough mode? (Instead of writeback)
>
> Good point. I just checked the same test, but reading instead of writing.
> Same result, no cache detected.
>
> I know how to change cache policy in u-boot, but does the kernel change
> that? If so, where?
Sorry for the stupid question. I did not remember it was there right before my
eyes. It seems I just got lost in the new menu structure of the Kconfig.
And yes, cache was in writethrough mode!!
It seems as though this option disables cache entirely, because after turning
it on, I suddenly get 2.4-type speed measurements.
With CONFIG_8xx_COPYBACK undefined, both reading and writing gives results as
if there was simply no cache. Shouldn't it at least speed up memory-read
access?
Sorry to everone for wasting their time with this stupid mistake of mine.
Thanks for all the help anyway.
Greetings,
--
David Jander
^ permalink raw reply
* Re: [PATCH] PPC: Basic enablement for new 15" PowerBook
From: Segher Boessenkool @ 2005-10-31 16:47 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20051030044256.GA10863@pb15.lixom.net>
> It's a qualified guess that the new 17" is PowerBook5,9, but until it's
> confirmed there's not much use in adding it to the pmac_feature table.
It is. See
http://developer.apple.com/documentation/Hardware/Developer_Notes/
Macintosh_CPUs-G4/17inchPowerBookG4/1Overview/
chapter_2_section_6.html#//apple_ref/doc/uid/TP40003166-CH205-TPXREF108
Segher
^ permalink raw reply
* Re: use of phy_connect() in drivers/net/gianfar.c ?
From: Andy Fleming @ 2005-10-31 16:56 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Linux/PPC Development
In-Reply-To: <20051030151847.C4383353416@atlas.denx.de>
On Oct 30, 2005, at 09:18, Wolfgang Denk wrote:
> Dear Matthew,
>
> in message <1130632707.7470.16.camel@localhost.localdomain> you wrote:
> >
> > As far as I understand there are patches in the -mm tree with =20
> contain
> > the updates for the Gianfar driver. The issue is due to a
>
> Do you happen to know of a specific (set of) patch(es)? URL?
>
> > synchronization issue with the new PHY abstraction layer that was =20=
> added.
>
> Yes, obviously. But I am still so na=EFve to expect that such =
changes
> would not make it untested (the code is not even compile clean) to an
> official kernel release like 2.6.14 ?
Sorry about that. The problem was that the offending changes needed =20
to be broken into two patches. The PHY Layer (a separate patch) =20
required changes to the driver, which required concurrent changes in =20
the platform init code (the MDIO bus was set up as its own device). =20
Unfortunately, the driver changes needed to be handled through =20
netdev, while the platform changes were through -mm. We tried to =20
sync it up so that the changes got into Linus' tree at the same time, =20=
but that did not happen. If you pull the tree today, you will find =20
that patch is now in the main tree.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Mark A. Greer @ 2005-10-31 19:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <17251.265.196352.234376@cargo.ozlabs.ibm.com>
On Sat, Oct 29, 2005 at 02:56:41PM +1000, Paul Mackerras wrote:
> Sven Luther writes:
>
> > +static struct pci_device_id pci_marvell_mv64360[] = {
> > + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
>
> Are there other devices in this northbridge whose drivers might also
> want to bind to this PCI id?
>
> What other devices does this northbridge contain?
It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
are also a serial controller (MPSC), an i2c controller, and a watchdog
timer. I would guess that the MPSC and i2c drivers, at least, should
use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
Mark
^ permalink raw reply
* enabling/disabling CPUs Kconfig bug
From: Giuliano Pochini @ 2005-10-31 21:11 UTC (permalink / raw)
To: LinuxPPC-dev
The option Processor-->Support for enabling/disabling CPUs should require
Platform options-->Power Management support to be enabled, otherwise compile
fails. I'm not sure if this patch is right or if the problem is somewhere else.
Signed-off-by Giuliano Pochini <pochini@shiny.it>
--- arch/ppc/Kconfig__orig 2005-10-30 17:19:17.000000000 +0000
+++ arch/ppc/Kconfig 2005-10-30 17:19:59.000000000 +0000
@@ -263,7 +263,7 @@
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
- depends on SMP && HOTPLUG && EXPERIMENTAL && PPC_PMAC
+ depends on SMP && HOTPLUG && EXPERIMENTAL && PPC_PMAC && PM
---help---
Say Y here to be able to disable and re-enable individual
CPUs at runtime on SMP machines.
--
Giuliano.
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Sven Luther @ 2005-10-31 21:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Andrew Morton, Sven Luther, linuxppc-dev
In-Reply-To: <20051031190524.GE5055@mag.az.mvista.com>
On Mon, Oct 31, 2005 at 12:05:24PM -0700, Mark A. Greer wrote:
> On Sat, Oct 29, 2005 at 02:56:41PM +1000, Paul Mackerras wrote:
> > Sven Luther writes:
> >
> > > +static struct pci_device_id pci_marvell_mv64360[] = {
> > > + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, PCI_DEVICE_ID_MARVELL_MV64360) },
> >
> > Are there other devices in this northbridge whose drivers might also
> > want to bind to this PCI id?
> >
> > What other devices does this northbridge contain?
>
> It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
> are also a serial controller (MPSC), an i2c controller, and a watchdog
> timer. I would guess that the MPSC and i2c drivers, at least, should
> use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
Yeah, forgot those, we don't use them on the pegasos though.
Friendly,
Sven Luther
^ permalink raw reply
* Export assembly symbol
From: Duong Nguyen @ 2005-10-31 23:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
Hello Garcia,
My name is Duong Nguyen. I am also working on a project that is needing
to export symbols from an assembly file for a loadable module. I am
having the exact problem that you were looking for help in August.
Have you gotten a solution for it yet ?
Would you please share your finding with me ?
Thanks
Duong
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
[-- Attachment #2: Type: text/html, Size: 3983 bytes --]
^ permalink raw reply
* Re: exception vectors
From: Olof Johansson @ 2005-11-01 1:46 UTC (permalink / raw)
To: Ingmar; +Cc: linuxppc-dev list
In-Reply-To: <20051031093907.M8073@gmx.net>
On Mon, Oct 31, 2005 at 10:58:53AM +0100, Ingmar wrote:
> On Sun, 30 Oct 2005 20:28:49 -0600, Hollis Blanchard wrote
> > On Oct 30, 2005, at 6:35 PM, Ingmar wrote:
> > >
> > > I am trying to overwrite the exception vector space of an ibook G4 :).
> >
> > Why?
> >
>
> For my thesis project I am porting the Minix (v3) OS.
Sounds like using qemu or some other emulator to do the PPC port first
might be an easier choice, and make debugging easier for you during
early bringup.
-Olof
^ permalink raw reply
* Re: Patches for 2.6.15
From: Paul Mackerras @ 2005-11-01 5:53 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051028103041.B15268@cox.net>
Matt Porter writes:
> Ok, we have a set of 4xx patches that I plan to send to Andrew.
> They are some existing 4xx SoC/board updates as well as a new
> SoC/board. They are obviously mostly confined to the 4xx code paths
> but there's likely conflicts in changes to Makefiles, etc.
>
> Would you prefer these going upstream before or after the
> powerpc-merge pull?
Did you send them yet? Linus has pulled the powerpc-merge tree, as
I'm sure you've noticed.
Paul.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Paul Mackerras @ 2005-11-01 5:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <D45D980C-C3F8-4418-A159-6F10708C914A@freescale.com>
Kumar Gala writes:
> Can you merge this in:
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=2931
Having the same extern declaration in several C files raises a red
flag. Could we have that in a suitable header file instead please?
Paul.
^ permalink raw reply
* Re: [PATCH] ppc32: Fix SCC Uart write problem after 2. open()
From: Heiko Schocher @ 2005-11-01 7:17 UTC (permalink / raw)
To: linuxppc-dev
Hello,
Sorry, here comes the resubmit of the Patch because
corruption of whitespaces.
on a MPC8260 based Board, i succesfully wrote chars
over a SCC in UART Mode, but after i closed the port
and opened it again, the write() call failed!
(cpm_uart_tx_empty()returns continually 0).
The following Patch will fix this problem.
thanks
Heiko Schocher
[PATCH] ppc32: Fix SCC Uart write problem after 2. open().
Signed-off-by: Heiko Schocher <hs@denx.de>
---
commit f27d5789521e3f70a293075a63d195b22f8156ed
tree 1b459d4a9a2795e39e1d415ff21f2a25a0d0fbe5
parent d2fcbaa6d5fcb3c1f80c98997dbcf6f6ee075f1b
author Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 15:46:50 +0100
committer Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 15:46:50 +0100
drivers/serial/cpm_uart/cpm_uart_core.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index a452c38..ac05ee9 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -445,6 +445,10 @@ static void cpm_uart_shutdown(struct uar
/* Shut them really down and reinit buffer descriptors */
cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
cpm_uart_initbd(pinfo);
+ if (IS_SMC(pinfo))
+ cpm_uart_init_smc(pinfo);
+ else
+ cpm_uart_init_scc(pinfo);
}
}
^ permalink raw reply related
* [PATCH] ppc32: fix: swallowed chars when booting.
From: Heiko Schocher @ 2005-11-01 7:22 UTC (permalink / raw)
To: linuxppc-dev
Hello,
Sorry, here comes the resubmit of the Patch because
corruption of whitespaces.
on a MPC8260 based Board, i lost some chars on the SMC2
Console, when booting the kernel. The following Patch
will fix this.
thanks
Heiko Schocher
[PATCH] ppc32: fix: swallowed chars when booting.
In cpm_uart_set_termios(): wait until all chars are transmitted,
before writing the SMC Mode Register.
Signed-off-by: Heiko Schocher <hs@denx.de>
---
commit d2fcbaa6d5fcb3c1f80c98997dbcf6f6ee075f1b
tree d602dae10d2010ca1506c6a02e6a6db36ac86aca
parent ed28f96ac1960f30f818374d65be71d2fdf811b0
author Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 12:11:55 +0100
committer Heiko Schocher <hs@pollux.(none)> Mon, 31 Oct 2005 12:11:55 +0100
drivers/serial/cpm_uart/cpm_uart_core.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index 25825f2..a452c38 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -553,6 +553,11 @@ static void cpm_uart_set_termios(struct
* present.
*/
prev_mode = smcp->smc_smcmr;
+ /* Wait for all the BDs marked sent */
+ while(!cpm_uart_tx_empty(port)) {
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(4);
+ }
smcp->smc_smcmr = smcr_mk_clen(bits) | cval | SMCMR_SM_UART;
smcp->smc_smcmr |= (prev_mode & (SMCMR_REN | SMCMR_TEN));
} else {
\f
!-------------------------------------------------------------flip-
^ permalink raw reply related
* Re: exception vectors
From: Ingmar @ 2005-11-01 8:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20051101014630.GA7938@pb15.lixom.net>
> > > > I am trying to overwrite the exception vector space of an ibook G4 :).
> > >
> > > Why?
> > >
> >
> > For my thesis project I am porting the Minix (v3) OS.
>
> Sounds like using qemu or some other emulator to do the PPC port first
> might be an easier choice, and make debugging easier for you during
> early bringup.
I was going to try that, before I got the ibook. Then I got the ibook and I
wanted to get my hand dirty. Nothing beats the real thing :)
But I have figured it out, I have the code working...
It are more or less (just) two things:
- mmu off,
- make sure u copy through the cache.
And of course make sure your secondary code is working as it should, then a emu
would help :).
Thanks for the reactions.
Ingmar
^ permalink raw reply
* Re: [PATCH 2.6.14-rc5 1/1] : mv643xx_eth_pcidev - implements hotplug for the marvell gige functionality by probing the northbridge pci id.
From: Paul Mackerras @ 2005-11-01 9:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: Andrew Morton, linuxppc-dev, Sven Luther
In-Reply-To: <20051031190524.GE5055@mag.az.mvista.com>
Mark A. Greer writes:
> It does have a PIC, DMA engine, and SRAM that Sven mentioned but there
> are also a serial controller (MPSC), an i2c controller, and a watchdog
> timer. I would guess that the MPSC and i2c drivers, at least, should
> use MODULE_DEVICE_TABLE. If you agree, I'll add it to the list.
But the point is that if one driver has claimed the device (because
its ID is in its module device table), the other drivers won't be able
to. You need something like the macio driver that BenH did, which
claims the macio device and creates a macio bus structure and allows
individual macio device drivers to claim the pieces of it.
Paul.
^ permalink raw reply
* Re: Patches for 2.6.15
From: Matt Porter @ 2005-11-01 13:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <17255.737.832440.137041@cargo.ozlabs.ibm.com>
On Tue, Nov 01, 2005 at 04:53:37PM +1100, Paul Mackerras wrote:
> Matt Porter writes:
>
> > Ok, we have a set of 4xx patches that I plan to send to Andrew.
> > They are some existing 4xx SoC/board updates as well as a new
> > SoC/board. They are obviously mostly confined to the 4xx code paths
> > but there's likely conflicts in changes to Makefiles, etc.
> >
> > Would you prefer these going upstream before or after the
> > powerpc-merge pull?
>
> Did you send them yet? Linus has pulled the powerpc-merge tree, as
> I'm sure you've noticed.
Yes I did. I saw the merge go into mainline and rebased what was
necessary off of that. Andrew now has them queued up for Linus so
we are set. BTW, we're starting to look at merging 4xx to arch/powerpc/
now.
-Matt
^ 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