* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Benjamin Herrenschmidt @ 2006-03-11 23:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20060311215840.GA22766@suse.de>
On Sat, 2006-03-11 at 22:58 +0100, Olaf Hering wrote:
> commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
> on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
>
> Only enable powersave_nap in one place: probe_motherboard()
> ppc32 gets nap if the cpu supports it
> ppc32 smp gets no nap
> ppc64 gets nap unconditionally
CONFIG_SMP is certainly not the way to do it though... I wonder how we
got that wrong, I'll have a look.
Ben.
> ---
> arch/powerpc/platforms/powermac/feature.c | 8 +++++++-
> arch/powerpc/platforms/powermac/setup.c | 4 ----
> arch/powerpc/platforms/powermac/smp.c | 4 ----
> 3 files changed, 7 insertions(+), 9 deletions(-)
>
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/feature.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
> @@ -2513,8 +2513,11 @@ found:
> /* Nap mode not supported if flush-on-lock property is present */
> if (get_property(np, "flush-on-lock", NULL))
> break;
> +
> +#ifndef CONFIG_SMP
> + /* 32 bits SMP can't NAP */
> powersave_nap = 1;
> - printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
> +#endif
> break;
> }
>
> @@ -2526,6 +2529,9 @@ found:
> #ifdef CONFIG_POWER4
> powersave_nap = 1;
> #endif
> + if (powersave_nap)
> + printk(KERN_INFO "Using native/NAP idle loop\n");
> +
> /* Check for "mobile" machine */
> if (model && (strncmp(model, "PowerBook", 9) == 0
> || strncmp(model, "iBook", 5) == 0))
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/setup.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
> @@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
> /* Probe motherboard chipset */
> pmac_feature_init();
>
> - /* We can NAP */
> - powersave_nap = 1;
> - printk(KERN_INFO "Using native/NAP idle loop\n");
> -
> /* Initialize debug stuff */
> udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
> udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
> Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
> ===================================================================
> --- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/smp.c
> +++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
> @@ -739,10 +739,6 @@ static void __init smp_core99_setup(int
> smp_hw_index[i] = i;
> }
> #endif
> -
> - /* 32 bits SMP can't NAP */
> - if (!machine_is_compatible("MacRISC4"))
> - powersave_nap = 0;
> }
>
> static int __init smp_core99_probe(void)
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Linux v2.6.16-rc5
From: Olaf Hering @ 2006-03-11 21:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <20060306230235.GA6113@suse.de>
On Tue, Mar 07, Olaf Hering wrote:
> On Mon, Mar 06, Olaf Hering wrote:
>
> > On Mon, Mar 06, Olaf Hering wrote:
> >
> > > On Mon, Mar 06, Paul Mackeras wrote:
> > >
> > > > There are also commits from Ben H that change the way we parse
> > > > addresses from the OF device tree. If you can bisect a bit further
> > > > that would be good, although you may strike problems between the 401d
> > > > and 6237 commits I mentioned above.
> > >
> > > What I have right now is this, which got me in a non-compiling state.
> > > I will pick the udbg stuff and apply the relevant changes to -git5.
>
> I tried with CONFIG_BOOTX_TEXT disabled. same result. This is the list
> of patches I used on top of 2.6.15:
>
> patches.kernel.org/patch-2.6.15-git5
> patches.suse/get_cramfs_inode-revert.patch
> patches.suse/suse-ppc-legacy-io.patch
> patches.arch/0022-powerpc-incorrect-rmo_top-handling-in-prom_init.txt
> patches.suse/9100b205fdc70b300894954ebebbf2709c5ed525.patch
> patches.suse/3d1229d6ae92ed1994f4411b8493327ef8f4b76f.patch
> patches.suse/d1405b869850982f05c7ec0d3f137ca27588192f.patch
> patches.suse/463ce0e103f419f51b1769111e73fe8bb305d0ec.patch
>
> patches.suse/51d3082fe6e55aecfa17113dbe98077c749f724c.patch
> patches.suse/31df1678d7732b94178a6e457ed6666e4431212f.patch
> patches.suse/8dacaedf04467e32c50148751a96150e73323cdc.patch
> patches.suse/52020d2bda9fe447bb50674a2e39e4064b6a10b5.patch
51d3082fe6e55aecfa17113dbe98077c749f724c enabled powersave_nap
unconditionally. But early G3 cpus can not handle it.
I sent a patch in another thread.
^ permalink raw reply
* [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Olaf Hering @ 2006-03-11 21:58 UTC (permalink / raw)
To: Paul Mackeras, Benjamin Herrenschmidt, linuxppc-dev, linux-kernel
commit 51d3082fe6e55aecfa17113dbe98077c749f724c enabled NAP unconditinally
on all powermacs. Early G3 cpus can not use it, the result is memory corruption.
Only enable powersave_nap in one place: probe_motherboard()
ppc32 gets nap if the cpu supports it
ppc32 smp gets no nap
ppc64 gets nap unconditionally
---
arch/powerpc/platforms/powermac/feature.c | 8 +++++++-
arch/powerpc/platforms/powermac/setup.c | 4 ----
arch/powerpc/platforms/powermac/smp.c | 4 ----
3 files changed, 7 insertions(+), 9 deletions(-)
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/feature.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/feature.c
@@ -2513,8 +2513,11 @@ found:
/* Nap mode not supported if flush-on-lock property is present */
if (get_property(np, "flush-on-lock", NULL))
break;
+
+#ifndef CONFIG_SMP
+ /* 32 bits SMP can't NAP */
powersave_nap = 1;
- printk(KERN_INFO "Processor NAP mode on idle enabled.\n");
+#endif
break;
}
@@ -2526,6 +2529,9 @@ found:
#ifdef CONFIG_POWER4
powersave_nap = 1;
#endif
+ if (powersave_nap)
+ printk(KERN_INFO "Using native/NAP idle loop\n");
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/setup.c
@@ -621,10 +621,6 @@ static void __init pmac_init_early(void)
/* Probe motherboard chipset */
pmac_feature_init();
- /* We can NAP */
- powersave_nap = 1;
- printk(KERN_INFO "Using native/NAP idle loop\n");
-
/* Initialize debug stuff */
udbg_scc_init(!!strstr(cmd_line, "sccdbg"));
udbg_adb_init(!!strstr(cmd_line, "btextdbg"));
Index: linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
===================================================================
--- linux-2.6.16-rc5-olh.orig/arch/powerpc/platforms/powermac/smp.c
+++ linux-2.6.16-rc5-olh/arch/powerpc/platforms/powermac/smp.c
@@ -739,10 +739,6 @@ static void __init smp_core99_setup(int
smp_hw_index[i] = i;
}
#endif
-
- /* 32 bits SMP can't NAP */
- if (!machine_is_compatible("MacRISC4"))
- powersave_nap = 0;
}
static int __init smp_core99_probe(void)
^ permalink raw reply
* Re: SCCx UART status on 8xx
From: Marcelo Tosatti @ 2006-03-11 22:17 UTC (permalink / raw)
To: Aristeu Sergio Rozanski Filho
Cc: fbl, Björn Östby, linuxppc-embedded
In-Reply-To: <20060220141830.GA7228@oops.ghostprotocols.net>
Aris,
Can you please prepare a detailed description of what the
patch is doing and why?
Thanks
On Mon, Feb 20, 2006 at 11:18:35AM -0300, Aristeu Sergio Rozanski Filho wrote:
> Index: stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:11:37.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_cpm1.c 2006-02-17 17:15:57.000000000 -0200
> @@ -139,24 +139,31 @@
> void scc1_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC1: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFFFC0;
> pinfo->brg = 1;
> }
>
> void scc2_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC2: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFFFC0FF;
> + cpmp->cp_sicr |= 0x00000900;
> pinfo->brg = 2;
> }
>
> void scc3_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC3: insert port configuration here */
> + cpmp->cp_sicr &= 0xFFC0FFFF;
> + cpmp->cp_sicr |= 0x00140000;
> pinfo->brg = 3;
> }
>
> void scc4_lineif(struct uart_cpm_port *pinfo)
> {
> /* XXX SCC4: insert port configuration here */
> + cpmp->cp_sicr &= 0xC0FFFFFF;
> + cpmp->cp_sicr |= 0x1BFFFFFF;
> pinfo->brg = 4;
> }
>
> Index: stable/drivers/serial/cpm_uart/cpm_uart_core.c
> ===================================================================
> --- stable.orig/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-07 15:30:42.000000000 -0200
> +++ stable/drivers/serial/cpm_uart/cpm_uart_core.c 2005-12-08 12:39:11.000000000 -0200
> @@ -467,6 +467,7 @@
> /* free interrupt handler */
> free_irq(port->irq, port);
>
> +#if 0
> /* If the port is not the console, disable Rx and Tx. */
> if (!(pinfo->flags & FLAG_CONSOLE)) {
> /* Wait for all the BDs marked sent */
> @@ -492,6 +493,7 @@
> /* Shut them really down */
> cpm_line_cr_cmd(line, CPM_CR_STOP_TX);
> }
> +#endif
> }
>
> static void cpm_uart_set_termios(struct uart_port *port,
> @@ -896,7 +898,7 @@
> pinfo->sccp->scc_gsmrl &= ~(SCC_GSMRL_ENR | SCC_GSMRL_ENT);
> }
>
> - ret = cpm_uart_allocbuf(pinfo, 0);
> + ret = cpm_uart_allocbuf(pinfo, 1);
>
> if (ret)
> return ret;
> @@ -912,10 +914,12 @@
>
> static void cpm_uart_release_port(struct uart_port *port)
> {
> +#if 0
> struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
>
> if (!(pinfo->flags & FLAG_CONSOLE))
> cpm_uart_freebuf(pinfo);
> +#endif
> }
>
> /*
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-11 13:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1142032411.4057.31.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Unmapping pages from the linear addressing
> without HIGHMEM support
> Datum: Sat, 11 Mar 2006 10:13:30 +1100
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
> > Killing the BAT mappings or limiting the memory size covered by the
> > BATs seems to be fairly easy, but I guess I have to setup my own page
> > table for the reserved DMA memory area and implement my own
> > alloc_pages() function!?
>
> No, just limit the size of the BAT mapping and mark some of the top
> pages of the address space reserved... That should be enough.
>
Okay, I will try that first. Marking some of the pages as reserved sounds
like the code you implemented for the uninorth_agp driver with this
"agp_special_page". I guess I still have to modify the code in dma_mapping.c
to use the reserved address space for the consistent memory allocation
(CONSISTENT_BASE, CONSISTENT_END)?
Thanks again!
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: Help: How to search for previous topics
From: wang dengyi @ 2006-03-11 10:29 UTC (permalink / raw)
To: linuxppc-embedded
I have the same question too. I use google to search
it, like this: mpc860 site:ozlabs.org
But I am wondering, is there a better way? I suspect
that google may miss something, especialy when
searching with multiply words.
Best regards,
Dengyi Wang
Krishnan wrote:
>Hello,
>
>Could anyone please tell me how previous topics could
be searched so that I
>don't
>need to trouble anyone for repetitive content?
>
>I only know of one way today, go through each list
and try to do a Ctrl+F
>which is quite
>painful.
>
>Cheers,
>Kris
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-10 23:13 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <22544.1141981797@www088.gmx.net>
> That would mean I cannot reuse the code in dma-mapping.c, right? Killing the
> BAT mappings or limiting the memory size covered by the BATs seems to be
> fairly easy, but I guess I have to setup my own page table for the reserved
> DMA memory area and implement my own alloc_pages() function!?
No, just limit the size of the BAT mapping and mark some of the top
pages of the address space reserved... That should be enough.
Ben.
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-10 23:12 UTC (permalink / raw)
To: Dan Malek; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <051c9d8f422b0e5289b7083367cf44ca@embeddedalley.com>
On Fri, 2006-03-10 at 07:59 -0500, Dan Malek wrote:
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
>
> Sure you can. All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.
And the kernel will blow up in flames under various funny circumstances
and you'll lose a fair amount of performances.
The 6xx kernel requires at least the IBAT mapping the kernel text. Some
of the exception handling code path can't deal with getting a hash fault
at critical locations (they can mostly deal with data hash misses
nowadays, but the code has to be accessible at all times).
> > ... but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
>
> No, that's already done for you behind all of these functions.
>
> Thanks.
>
> -- Dan
>
>
^ permalink raw reply
* Re: 440gx dma transfer with no data change at dest
From: Kevin Kleinosowski @ 2006-03-10 22:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0603071505110.21479@mohave.arlut.utexas.edu>
Maybe this is too much. Has anyone successfully done a memory-to-memory
DMA transfer with the 2.4.27 kernel routines in
arch/ppc/kernel/ppc4xx_dma.c on any ppc embedded platform? If you have,
are you willing to share a bit of code example, or look at one?
#define MEM_BUF_SIZE_ORDER 4
#define MEM_BUF_SIZE_BYTES 65536UL
#define EBC0_DMA_CHANNEL 1
#define DMA_SR_CS_SET 0x80000000
unsigned long interruptFlags;
ppc_dma_ch_t channelSetup;
int dmaStatus;
u32 src, dst;
src = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
memset ((char *)src, 0xFF, MEM_BUF_SIZE_BYTES);
dst = __get_dma_pages (GFP_KERNEL, MEM_BUF_SIZE_ORDER);
memset ((char *)dst, 0x00, MEM_BUF_SIZE_BYTES);
memset (&channelSetup, 0, sizeof (ppc_dma_ch_t));
interruptFlags = claim_dma_lock ();
ppc4xx_get_channel_config (EBC0_DMA_CHANNEL, &channelSetup);
channelSetup.buffer_enable = 1;
channelSetup.tce_enable = 1;
channelSetup.etd_output = 1;
channelSetup.pce = 0;
channelSetup.pl = 1;
channelSetup.pwidth = PW_32;
channelSetup.sai = 1;
channelSetup.dai = 1;
channelSetup.psc = 0;
channelSetup.pwc = 0;
channelSetup.phc = 0;
channelSetup.cp = PRIORITY_LOW;
channelSetup.pf = PREFETCH_1;
channelSetup.int_enable = 1;
channelSetup.mode = DMA_MODE_MM;
ppc4xx_init_dma_channel (EBC0_DMA_CHANNEL, &channelSetup);
ppc4xx_enable_dma_interrupt (EBC0_DMA_CHANNEL);
ppc4xx_disable_dma (EBC0_DMA_CHANNEL);
ppc4xx_set_src_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)src));
ppc4xx_set_dst_addr (EBC0_DMA_CHANNEL, virt_to_bus((u32 *)dst));
ppc4xx_set_dma_count (EBC0_DMA_CHANNEL, MEM_BUF_SIZE_BYTES);
ppc4xx_enable_dma (EBC0_DMA_CHANNEL);
release_dma_lock (interruptFlags);
dmaStatus = ppc4xx_get_dma_status ();
while ((dmaStatus & (DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) !=
(DMA_SR_CS_SET >> EBC0_DMA_CHANNEL)) {
printk ("DMA STATUS: 0x%8.8x\n", dmaStatus);
set_current_state (TASK_INTERRUPTIBLE);
schedule_timeout (HZ/4);
dmaStatus = ppc4xx_get_dma_status ();
}
The result dst was initialed to 0x00 but the transfer should have put
it all to 0xff. However most locations are 0xff, and some locations are
0x00. There seems to be no pattern to it. Sometimes all locations of dst
have 0xff.
Anyone see anything wrong?
Kevin
On Tue, 7 Mar 2006, Kevin Kleinosowski wrote:
>
> I am running a simple test with a software initiated DMA transfer from one
> bigphysarea allocated buffer to another bigphysarea allocated buffer. The
> destination buffer shows no data changes once the transfer is done.
>
> However, I perform the same simple test using __get_dma_pages() rather then
> the bigphysarea_alloc_pages() and the destination does get the data transfer.
>
> Is there a reason this should fail for bigphysarea? I understand the low
> memory addresses needed for the DMA controller on some platforms, but I didnt
> think that limitation existed on the PPC. Besides that, the bigphysarea
> returns low memory address anyway. Anyone have an idea why? An old archive
> email had someone with a similar problem, but there were no follow-ups to the
> message.
>
> I have linux 2.4.27-pre3 patched, ppc-linux-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1
> 3.3.3-9), U-Boot 1.1.2, and GMS 440gx board.
>
> thanks,
> Kevin
>
>
^ permalink raw reply
* Re: How to quickly write cleanmarkers to jffs2 partitions?
From: Jaap-Jan Boor @ 2006-03-10 17:10 UTC (permalink / raw)
To: linuxppc
In-Reply-To: <200603080938.35299.david.jander@protonic.nl>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
On Wed, 2006-03-08 at 09:38 +0100, David Jander wrote:
>
> Thanks to all for the suggestions.
> Is "cleanmark" an open-source tool?
well, I think so, as it's a minimal modified flash_eraseall.c from mtd
> Would you share it?
sure, a gzipped version is attached. Put it in the mtd/util directory
and add it to the Makefile there (to TARGETS) and:
cleanmark: crc32.o cleanmark.o
$(CC) $(LDFLAGS) -o $@ $^
best regards,
Jaap-Jan
>
> Greetings,
>
> --
> David Jander
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: cleanmark.c.gz --]
[-- Type: application/x-gzip, Size: 2567 bytes --]
^ permalink raw reply
* Re: Stable Linux kernel 2.6 for MPC8XX
From: Wolfgang Denk @ 2006-03-10 15:33 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603100822.42764.david.jander@protonic.nl>
In message <200603100822.42764.david.jander@protonic.nl> you wrote:
> >
> > http://www.denx.de/wiki/bin/view/Know/Linux24vs26
>
> I believe most of those observations and measurements are not valid anymore.
> Kernel 2.6 for 8xx has come a long way since this article was written. It
> might have been true back then, but it surely isn't anymore.
So did you actually run any benchmarks? Specilations on what might be
or should be are not really helpful.
> Kernel 2.6 is bigger than 2.4, that's a fact, but application performance is
> actually slightly higher with 2.6.14 than it is with 2.4.25.
What says lmbench on your system? Can you please show actual data?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
...when fits of creativity run strong, more than one programmer or
writer has been known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-10 13:31 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
In-Reply-To: <31042.1141997321@www088.gmx.net>
> --- Ursprüngliche Nachricht ---
> Von: Dan Malek <dan@embeddedalley.com>
> An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> Kopie: debian-powerpc@lists.debian.org, linuxppc-dev@ozlabs.org, Benjamin
> Herrenschmidt <benh@kernel.crashing.org>
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 07:59:33 -0500
>
> On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
>
> > That would mean I cannot reuse the code in dma-mapping.c, right?
>
> Sure you can. All you need to do is turn of BAT mapping, which
> is as easy as using the 'nobats' command line parameter and
> all of this code should just work for you.
Yes, that was the solution I would have used. The other solution is to
reserve a physical memory area for DMA operations that is not mapped by the
BATs (AFAIU nor by any page tables setup by the kernel). Therefore I doubt
that I can simply reuse the dma-mapping.c code for the latter approach!? Do
I mix something up here?
> > ... but I guess I have to setup my own page table for the reserved
> > DMA memory area and implement my own alloc_pages() function!?
>
> No, that's already done for you behind all of these functions.
But only, if the whole BAT mapping is killed, right?
Thanks!
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: Stable Linux kernel 2.6 for MPC8XX
From: Dan Malek @ 2006-03-10 13:16 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200603100822.42764.david.jander@protonic.nl>
On Mar 10, 2006, at 2:22 AM, David Jander wrote:
> I believe most of those observations and measurements are not valid
> anymore.
> Kernel 2.6 for 8xx has come a long way since this article was written.
They are still valid, we just have more knowledge about how to
configure the kernels and have added some features you can
use to mitigate the performance issues. The Linux 2.6 kernel
is simply bigger than 2.4, and on these small, resource challenged
processors, you need to very carefully configure the kernels to
your requirements.
Thanks.
-- Dan
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Dan Malek @ 2006-03-10 12:59 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <22544.1141981797@www088.gmx.net>
On Mar 10, 2006, at 4:09 AM, Gerhard Pircher wrote:
> That would mean I cannot reuse the code in dma-mapping.c, right?
Sure you can. All you need to do is turn of BAT mapping, which
is as easy as using the 'nobats' command line parameter and
all of this code should just work for you.
> ... but I guess I have to setup my own page table for the reserved
> DMA memory area and implement my own alloc_pages() function!?
No, that's already done for you behind all of these functions.
Thanks.
-- Dan
^ permalink raw reply
* Re: kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
From: Carlos Mitidieri @ 2006-03-10 11:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43A6ED1E.20506@anagramm.de>
Hi,
The kernel actually hangs when schedule() is called in rest_init() in main.c
Would someone risk a guess ?
(keeping the walk...) Thanks,
On Monday 19 December 2005 18:25, Clemens Koller wrote:
> Hello!
>
> Here is a little update:
> > I am just about to update my kernel from 2.6.13-rc7 which is working
> > fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board.
> > However, the kernel hangs pretty early after
> >
> > openpic: exit
>
> openpic_init() is called by mpc85xx_ads_init_IRQ in ppc/platforms/85xx
>
> ppc_md.init_IRQ=mpc85xx_ads_init_IRQ in ppc/platforms/85xx
>
> ppc_md.init_IRQ() is called from powerpc/kernel/irq.c
>
> init_IRQ() is called from init/main.c:start_kernel()
>
> and that seems to work fine. So, it crashes silently somewhere
> after that point. I try to build 2.6.15-rc6-latest with kgbd support,
> not knowing if it's supposed to work on this platform.
>
> Are there some open issues from the ppc->powerpc migration?
>
> Thanks,
--
Best regards,
Carlos Mitidieri
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-10 9:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1141942301.3603.12.camel@localhost.localdomain>
> --- Ursprüngliche Nachricht ---
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> Kopie: linuxppc-dev@ozlabs.org, debian-powerpc@lists.debian.org
> Betreff: Re: Unmapping pages from the linear addressing without
> HIGHMEM support
> Datum: Fri, 10 Mar 2006 09:11:41 +1100
>
> On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> > Hi,
> >
> > I'm trying to implement non-coherent DMA for PPC desktop systems (like
> > the AmigaOne with G3/G4 CPU). For this I want to use the code in
> > arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> > implemented in this file allocates pages with alloc_pages() and maps
> > them to its own linear address space, but without unmapping the
> > allocated pages from the kernel linear addressing. Due to this the
> > pages are mapped twice, which results in a conflict between the
> > different WIMG settings of the pages.
> >
> > Is there an API that can be used to unmap the allocated pages from the
> > kernel linear addressing? I thought about using kunmap() and
> > flush_all_zero_pkmaps(), but I'm not sure if this is the right approach
> > and HIGHMEM doesn't work on the AmigaOne too (the highmem base is
> > occupied by the PCI/ISA I/O space!). Wouldn't it be possible to just
> > clear the valid (V) bit of the PTE and do a TLB cache flush?
>
> The main problem is that the mappings may be covered by a BAT and thus
> pages may not be unmappable individually...
>
> What I would suggest is that your dig in the low level RAM mapping code
> and limit it at boot to RAM minus a pool of the size you want.
That would mean I cannot reuse the code in dma-mapping.c, right? Killing the
BAT mappings or limiting the memory size covered by the BATs seems to be
fairly easy, but I guess I have to setup my own page table for the reserved
DMA memory area and implement my own alloc_pages() function!?
Thanks!
Gerhard
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: kernel 2.6.15-rc5-latest doesn't work anymore on mpc8540ads
From: Carlos Mitidieri @ 2006-03-10 7:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0512191437460.4403-100000@gate.crashing.org>
Hi,
Has the knowledge about this issue advanced?
What I have noticed so far is that the same happens in 2.6.14, therefore the
problem rose in the transition from 2.6.13.
Would this be related to the IRQ stuff initialization? Any guess?
On Monday 19 December 2005 21:38, Kumar Gala wrote:
> On Mon, 19 Dec 2005, Clemens Koller wrote:
> > Hello!
> >
> > Here is a little update:
> > > I am just about to update my kernel from 2.6.13-rc7 which is working
> > > fine to linus' 2.6.15-rc5-latest git on my mpc8540ads flavored board.
> > > However, the kernel hangs pretty early after
> > >
> > > openpic: exit
> >
> > openpic_init() is called by mpc85xx_ads_init_IRQ in ppc/platforms/85xx
> >
> > ppc_md.init_IRQ=mpc85xx_ads_init_IRQ in ppc/platforms/85xx
> >
> > ppc_md.init_IRQ() is called from powerpc/kernel/irq.c
> >
> > init_IRQ() is called from init/main.c:start_kernel()
> >
> > and that seems to work fine. So, it crashes silently somewhere
> > after that point. I try to build 2.6.15-rc6-latest with kgbd support,
> > not knowing if it's supposed to work on this platform.
>
> It was a guess :)
>
> > Are there some open issues from the ppc->powerpc migration?
>
> possible, can you use git bisect to find what commit may have caused the
> issue?
>
> - kumar
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
Carlos Mitidieri
^ permalink raw reply
* Re: Stable Linux kernel 2.6 for MPC8XX
From: David Jander @ 2006-03-10 7:22 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1CFEB358338412458B21FAA0D78FE86D02CABEE3@rennsmail02.eu.thmulti.com>
On Wednesday 08 March 2006 15:29, Fillod Stephane wrote:
> >I would want to use a linux kernel 2.6 on a custom MPC8xx board.
> >Which stable kernel release must or can I use ?
>
> http://www.denx.de/wiki/bin/view/Know/Linux24vs26
I believe most of those observations and measurements are not valid anymore.
Kernel 2.6 for 8xx has come a long way since this article was written. It
might have been true back then, but it surely isn't anymore.
Kernel 2.6 is bigger than 2.4, that's a fact, but application performance is
actually slightly higher with 2.6.14 than it is with 2.4.25.
The overall robustness and "niceness" of the code is also a totally different
story now. 2.6 software architecture is definitely better, and many drivers
are much more stable. Implementing board support and drivers in 2.6 is also
much easier and cleaner than in 2.4.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [Patch] Fix compile error for ML300/403
From: Grant Likely @ 2006-03-10 6:36 UTC (permalink / raw)
To: Andrei Konovalov; +Cc: Paul Mackerras, linuxppc-embedded list
In-Reply-To: <44102EB3.2000301@ru.mvista.com>
On 3/9/06, Andrei Konovalov <akonovalov@ru.mvista.com> wrote:
> > diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/v=
irtex.h
> > index 2a2a65c..4d893ef 100644
> > --- a/arch/ppc/platforms/4xx/virtex.h
> > +++ b/arch/ppc/platforms/4xx/virtex.h
> > @@ -27,7 +27,7 @@
> > /* Device type enumeration for platform bus definitions */
> > #ifndef __ASSEMBLY__
> > enum ppc_sys_devices {
> > - VIRTEX_UART, VIRTEX_FB,
> > + VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
>
> AFAIK there is no VIRTEX_FB in the powerpc.git tree yet.
> Otherwise I confirm that adding NUM_PPC_SYS_DEVS is necessary.
heh, oops. yeah, I've got the FB driver in my local tree. Fixed
patch attached...
-----
[patch] Fix compile error for ML300/403.
Due to changes in ppc_sys.c. This is needed in Paul's powerpc.git tree
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
commit 60a9fb927e8f68d307339e6e268452d2c62b717f
tree e62d99cb4fa697d8d59af2a3ab063e050ba6ca99
parent 6749c5507388f3fc3719f57a54b540ee83f6661a
author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -=
0700
committer <grant@weasley-twins.(none)> Thu, 09 Mar 2006 23:30:38 -0700
arch/ppc/platforms/4xx/virtex.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virte=
x.h
index 1a01b81..c14325d 100644
--- a/arch/ppc/platforms/4xx/virtex.h
+++ b/arch/ppc/platforms/4xx/virtex.h
@@ -27,7 +27,7 @@
/* Device type enumeration for platform bus definitions */
#ifndef __ASSEMBLY__
enum ppc_sys_devices {
- VIRTEX_UART,
+ VIRTEX_UART, NUM_PPC_SYS_DEVS,
};
#endif
^ permalink raw reply related
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-09 22:11 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <15153.1141912297@www026.gmx.net>
On Thu, 2006-03-09 at 14:51 +0100, Gerhard Pircher wrote:
> Hi,
>
> I'm trying to implement non-coherent DMA for PPC desktop systems (like the
> AmigaOne with G3/G4 CPU). For this I want to use the code in
> arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
> implemented in this file allocates pages with alloc_pages() and maps them to
> its own linear address space, but without unmapping the allocated pages from
> the kernel linear addressing. Due to this the pages are mapped twice, which
> results in a conflict between the different WIMG settings of the pages.
>
> Is there an API that can be used to unmap the allocated pages from the
> kernel linear addressing? I thought about using kunmap() and
> flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
> HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
> the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
> bit of the PTE and do a TLB cache flush?
The main problem is that the mappings may be covered by a BAT and thus
pages may not be unmappable individually...
What I would suggest is that your dig in the low level RAM mapping code
and limit it at boot to RAM minus a pool of the size you want.
Ben.
^ permalink raw reply
* Re: Virtex-4 TEMAC device driver available?
From: Yoshio Kashiwagi @ 2006-03-09 18:10 UTC (permalink / raw)
To: S. Egbert, linuxppc-embedded
In-Reply-To: <JS200602192039433.11799406@co-nss.co.jp>
Hello Steve San,
Although I was performing porting for the reference design of
xapp902 shown in the following URL, I have noticed that the
temac circuit of this xapp902 cannot perform control of PHY.
The temac circuit of this xapp902 does not have control of PHY.
http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
As a result of consulting with our client, our client newly
creates their original temac based on xapp807 design of the
following URL. It is because the function is insufficient
using Linux in this xapp897 design.
http://www.xilinx.com/bvdocs/appnotes/xapp807.pdf
Since I created the temac driver of their design, the release
of the driver to ML became impossible to me.
Best Regaeds,
Yoshio kashiwagi - Nissin Systems
> Hello Steve San,
>
> Strictly, GSRD differs from TEMAC.
> Although both are embedded TEMAC is used in Virtex4, GSRD accesses
> direct memory through MPMC. MPMC is a multi-port memory controller
> for GSRD to access direct memory.
>
> http://www.xilinx.com/esp/wired/optical/xlnx_net/gsrd_download.htm
>
> Download of GSRD is linked out of the above-mentioned URL, and
> becomes a place to be logged in (Registration for downloading the
> reference design short cut).
> http://www.xilinx.com/xlnx/xil_entry2.jsp?sMode=login&group=gsrd
>
> Linux2.4 driver is contained in this GSRD. However, this Linux2.4
> driver (adapter.c) has the fault which does not operate correctly,
> when a 100BASE hub is connected. In order to correct this problem,
> it is necessary to add the interrupt handling routine of PHY.
> Although this GSRD is a reference design more nearly high-speed
> than TEMAC, many FPGA resources are used for it.
>
> I am going to create a TEMAC driver (Linux2.6) by a scratch, I
> cannot make time for it now. Since it is due to make by the end of
> this month, if it is completed, I'll announce it to this mailing
> list.
>
> I'll write the Linux2.6 TEMAC driver corresponding to the following
> reference designs.
> http://direct.xilinx.com/bvdocs/appnotes/xapp902.pdf
> http://www.xilinx.com/bvdocs/appnotes/xapp902.zip
> (The Linux driver is not contained in this reference design)
>
> Best Regards,
>
> Yoshio Kashiwagi - Nissin Systems
>
> > Dear Kashiwagi-San,
> >
> > I noticed in your posting over at linuxppc-embedded in Jan 2006
about
> a
> > Xilinx demo code for the TEMAC driver.
> >
> > So, I pulled the
> > http://www.xilinx.co.jp/ise/embedded/EDK/71i/mpmc_7_1_2.zip file and
> > browsed it.
> >
> > Do you know where one can get a patch for Linux 2.4?
> >
> > Thank you,
> >
> > Steve Egbert
> >
> > --
> > -----BEGIN GEEK CODE BLOCK-----
> > Version: 3.12
> > GAT d- s++: !a C+++ UL++++ P+++ L+++ E W+++ N+ o++ K+++ w--
> > O- M+ V- PS PE++ Y+ PGP++ t++ 5++ X++ R tv- b++ DI+ D+
> > G++ e* h++ r+++ z
> > ------END GEEK CODE BLOCK------
> > GPG Public Key: http://www.egbert.net/pgp
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
------------------------------------------------------------
柏木良夫
株式会社日新システムズ 基礎技術部
Linuxプロフェショナルグループ
〒600-8482 京都市下京区堀川通四条下ル東側 堀川四条ビル
TEL 075-344-7950 FAX 075-344-7887
E-Mail kashiwagi@co-nss.co.jp HTTP http://www.co-nss.co.jp/
------------------------------------------------------------
^ permalink raw reply
* System time accuracy
From: Brent Cook @ 2006-03-09 14:57 UTC (permalink / raw)
To: linuxppc-dev
I'm having a puzzling problem. On every 7448-based Linux system that I have
worked on so far, including:
Mac Mini, 1.5 Ghz
Various PMC boards - MV64460 system controller
Freescale HPC II - TSI108 system controller
, the system clock loses approx 1 second every 5 minutes. In fact, I have been
unable to even get NTP to sync these system clocks properly; it just doesn't
adjust fast enough to keep up with the lag, leading to big drifts and adjtimex
just doesn't keep up. Eventually the systems get more than 180 seconds out of
sync and NTP stops trying.
Is this normal behavior, and if so, what have you done to work around it? Is
this a general issue with PPC arch, Linux 2.6 (tried 2.6.11 - 2.6.15), or
specific to the platforms I have tried so far?
Here is the result of running openntpd on a freshly synced system (this
particular one is the HPC II running 2.6.11):
ntpd -sd
192.168.1.1: offset 0.000066 delay 0.000352, next query 5s
reply from 192.168.1.1: offset 0.010422 delay 0.000242, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset 0.020899 delay 0.000256, next query 5s
reply from 192.168.1.1: offset 0.031362 delay 0.000306, next query 5s
reply from 192.168.1.1: offset 0.041838 delay 0.000316, next query 5s
reply from 192.168.1.1: offset 0.052244 delay 0.000226, next query 287s
reply from 192.168.1.1: offset 0.652178 delay 0.000343, next query 30s
adjusting local clock by 0.052244s
reply from 192.168.1.1: offset 0.684853 delay 0.000275, next query 30s
reply from 192.168.1.1: offset 0.725305 delay 0.000257, next query 30s
reply from 192.168.1.1: offset 0.788057 delay 0.000397, next query 30s
reply from 192.168.1.1: offset 0.850732 delay 0.000291, next query 30s
reply from 192.168.1.1: offset 0.913406 delay 0.000233, next query 30s
reply from 192.168.1.1: offset 0.976180 delay 0.000369, next query 30s
reply from 192.168.1.1: offset 1.038846 delay 0.000279, next query 30s
adjusting local clock by 0.913406s
reply from 192.168.1.1: offset 1.071584 delay 0.000309, next query 30s
reply from 192.168.1.1: offset 1.104273 delay 0.000289, next query 30s
reply from 192.168.1.1: offset 1.136919 delay 0.000273, next query 30s
reply from 192.168.1.1: offset 1.169708 delay 0.000342, next query 30s
reply from 192.168.1.1: offset 1.202390 delay 0.000295, next query 30s
reply from 192.168.1.1: offset 1.235082 delay 0.000252, next query 30s
adjusting local clock by 1.235082s
reply from 192.168.1.1: offset 1.267829 delay 0.000320, next query 30s
For comparison, this is an x86 PC doing the same thing:
ntpd -sd
ntp engine ready
reply from 192.168.1.1: offset -0.025448 delay 0.000618, next query 5s
reply from 192.168.1.1: offset -0.025973 delay 0.000285, next query 9s
reply from 192.168.1.1: offset -0.030136 delay 0.000248, next query 5s
peer 192.168.1.1 now valid
reply from 192.168.1.1: offset -0.033057 delay 0.000293, next query 6s
reply from 192.168.1.1: offset -0.036570 delay 0.000321, next query 5s
reply from 192.168.1.1: offset -0.039546 delay 0.000231, next query 5s
reply from 192.168.1.1: offset -0.042481 delay 0.000289, next query 34s
reply from 192.168.1.1: offset -0.062430 delay 0.000264, next query 32s
adjusting local clock by -0.039546s
reply from 192.168.1.1: offset -0.049193 delay 0.000264, next query 307s
reply from 192.168.1.1: offset -0.052205 delay 0.000299, next query 307s
reply from 192.168.1.1: offset -0.078816 delay 0.000284, next query 309s
reply from 192.168.1.1: offset -0.010273 delay 0.000336, next query 326s
reply from 192.168.1.1: offset -0.038518 delay 0.000279, next query 323s
reply from 192.168.1.1: offset -0.066434 delay 0.000314, next query 312s
adjusting local clock by -0.049193s
Now, none of these PPC systems has /dev/rtc (the x86 does), but that should
not matter, since the real-time clock is usually used in Linux a boot or
shutdown.
^ permalink raw reply
* Re: [PATCH] Fix platform_notify functions marked __init
From: Mark A. Greer @ 2006-03-09 17:36 UTC (permalink / raw)
To: Adrian Cox; +Cc: linuxppc-dev
In-Reply-To: <1141855821.28095.18.camel@localhost.localdomain>
On Wed, Mar 08, 2006 at 10:10:20PM +0000, Adrian Cox wrote:
> While adding USB support to an MV64360 based board this week, I
> discovered that all MV64x60 boards in the kernel have platform_notify
> functions marked with __init. This causes an oops if a device is added
> after boot.
>
> The patch below removes the __init markers. I do not have all these
> boards to test on, but the change seems very unlikely to break anything
> else.
Arg... I realized this a long time ago and fixed it in my tree.
Somewhere along the line, I dropped it, I guess.
Thanks for the patch Adrian.
Mark
^ permalink raw reply
* Unmapping pages from the linear addressing without HIGHMEM support
From: Gerhard Pircher @ 2006-03-09 13:51 UTC (permalink / raw)
To: linuxppc-dev, debian-powerpc
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1048 bytes --]
Hi,
I'm trying to implement non-coherent DMA for PPC desktop systems (like the
AmigaOne with G3/G4 CPU). For this I want to use the code in
arch/ppc/kernel/dma-mapping.c. The DMA memory allocation function
implemented in this file allocates pages with alloc_pages() and maps them to
its own linear address space, but without unmapping the allocated pages from
the kernel linear addressing. Due to this the pages are mapped twice, which
results in a conflict between the different WIMG settings of the pages.
Is there an API that can be used to unmap the allocated pages from the
kernel linear addressing? I thought about using kunmap() and
flush_all_zero_pkmaps(), but I'm not sure if this is the right approach and
HIGHMEM doesn't work on the AmigaOne too (the highmem base is occupied by
the PCI/ISA I/O space!). Wouldn't it be possible to just clear the valid (V)
bit of the PTE and do a TLB cache flush?
Any suggestions?
Thanks!
Regards,
Gerhard
--
"Feel free" mit GMX FreeMail!
Monat für Monat 10 FreeSMS inklusive! http://www.gmx.net
^ permalink raw reply
* Re: [Patch] Fix compile error for ML300/403
From: Andrei Konovalov @ 2006-03-09 13:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-embedded list
In-Reply-To: <528646bc0603081507t24c7e2f5u8e2823931200a857@mail.gmail.com>
Hi Grant,
Grant Likely wrote:
> Fix compile error due to changes in ppc_sys.c. This is needed in the
> powerpc.git tree
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
> commit 75ec8a6ff8410c30f459e5e1c924ce811f8b1e25
> tree 87f29c44458d2966bf208f9ea25432b26faa2eb5
> parent 126dddf2535520cbeafb7069ce092b80beb8558a
> author Grant Likely <grant.likely@secretlab.ca> Wed, 08 Mar 2006 16:03:56 -0700
> committer <grant@weasley-twins.(none)> Wed, 08 Mar 2006 16:03:56 -0700
>
> arch/ppc/platforms/4xx/virtex.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/ppc/platforms/4xx/virtex.h b/arch/ppc/platforms/4xx/virtex.h
> index 2a2a65c..4d893ef 100644
> --- a/arch/ppc/platforms/4xx/virtex.h
> +++ b/arch/ppc/platforms/4xx/virtex.h
> @@ -27,7 +27,7 @@
> /* Device type enumeration for platform bus definitions */
> #ifndef __ASSEMBLY__
> enum ppc_sys_devices {
> - VIRTEX_UART, VIRTEX_FB,
> + VIRTEX_UART, VIRTEX_FB, NUM_PPC_SYS_DEVS,
AFAIK there is no VIRTEX_FB in the powerpc.git tree yet.
Otherwise I confirm that adding NUM_PPC_SYS_DEVS is necessary.
Thanks,
Andrei
> };
> #endif
>
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ 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