* [PATCH] correct AC Power info in /proc/pmu/info
From: Olaf Hering @ 2006-03-12 11:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Report AC Power present in /proc/pmu/info if there is no battery.
Signed-off-by: Olaf Hering <olh@suse.de>
---
drivers/macintosh/via-pmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
===================================================================
--- linux-2.6.16-rc6-olh.orig/drivers/macintosh/via-pmu.c
+++ linux-2.6.16-rc6-olh/drivers/macintosh/via-pmu.c
@@ -825,7 +825,7 @@ proc_get_info(char *page, char **start,
p += sprintf(p, "PMU driver version : %d\n", PMU_DRIVER_VERSION);
p += sprintf(p, "PMU firmware version : %02x\n", pmu_version);
p += sprintf(p, "AC Power : %d\n",
- ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0));
+ ((pmu_power_flags & PMU_PWR_AC_PRESENT) != 0) || pmu_battery_count == 0);
p += sprintf(p, "Battery count : %d\n", pmu_battery_count);
return p - page;
^ permalink raw reply
* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Olaf Hering @ 2006-03-12 10:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1142121302.4057.52.camel@localhost.localdomain>
On Sun, Mar 12, Benjamin Herrenschmidt wrote:
> 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.
>
> Ok, here is what I think is a proper fix: Just remove the code from
> setup.c since feature.c will already set powersave_nap when needed.
>
> Can you test asap please ? If it fixes the problem for you, I'll send
> the patch to Linus/Andrew with hopes that it will make it in 2.6.16
Yes, this helps.
^ permalink raw reply
* suspend2 on PowerBook: keyboard doesn't work on resume
From: Dustin Lang @ 2006-03-12 1:55 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm trying to get suspend2 working on my PowerBook G4 of Oct 2003 vintage.
I'm running kernel 2.6.15.6 with the 2.6.15.1 suspend2 patch (it applied
and built fine).
Before suspending, I quit X and logged in as root on the console. I
unloaded all the modules I could - leaving just agpgart and uninorth-agp.
USB is kernelized and the modules are unloaded. I started a loop that
printed "Running" every 10 seconds (and also started a job that after 60
seconds would reboot). I ran the 'hibernate' script. It completed
successfully and powered down the machine.
On the next startup, the kernel boots and it resumes. I see the root
terminal again, complete with my "hibernate" command and the syslog
messages detailing the progress of suspend2. The system does not respond
to keystrokes, however. After a few seconds, the "Running" message is
printed out, and after 60 seconds, the system reboots. To me this
suggests that the system is mostly resuming correctly, but something has
gone funny with the keyboard driver.
Keyboard-related dmesg:
MacIO PCI driver attached to Intrepid chipset
input: Macintosh mouse button emulation as /class/input/input0
adb: starting probe task...
[snip]
PCI: Enabling device 0002:20:0d.0 (0000 -> 0002)
adb devices: [2]: 2 c3 [3]: 3 1 [7]: 7 1f
ADB keyboard at 2, handler 1
Detected ADB keyboard, type ANSI.
input: ADB keyboard as /class/input/input1
input: ADB Powerbook buttons as /class/input/input2
ADB mouse at 3, handler set to 4 (trackpad)
input: ADB mouse as /class/input/input3
adb: finished probe task...
Does anyone on the list use suspend2 on a PowerBook? Any success/failure
stories? Any advice for generating more useful debugging information?
Thanks,
dustin.
^ permalink raw reply
* Re: Unmapping pages from the linear addressing without HIGHMEM support
From: Benjamin Herrenschmidt @ 2006-03-12 0:07 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <20006.1142083702@www079.gmx.net>
On Sat, 2006-03-11 at 14:28 +0100, Gerhard Pircher wrote:
> > --- 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)?
Probably. I'm not sure about that code, I think those
CONSISTENT_BASE/END are only virtual addresses, the code still alocates
real pages below that from anywhere in memory, you may have to change
that, or maybe just 1:1 map that reserved area non-cacheable, and change
dma-mapping.c to not allocate any physical pages but just pick the one
matching the virtual ones it just allocated...;
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: enable NAP only on cpus who support it to avoid memory corruption
From: Benjamin Herrenschmidt @ 2006-03-11 23:55 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.
Ok, here is what I think is a proper fix: Just remove the code from
setup.c since feature.c will already set powersave_nap when needed.
Can you test asap please ? If it fixes the problem for you, I'll send
the patch to Linus/Andrew with hopes that it will make it in 2.6.16
---
This patch fixes incorrect setting of powersave_nap to 1 on all
PowerMac's potentially causing memory corruption on some models. This
bug was introuced by me during the 32/64 bits merge.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/setup.c 2006-02-13 14:10:43.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/setup.c 2006-03-12 10:47:39.000000000 +1100
@@ -621,10 +621,6 @@
/* 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-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2006-03-01 11:48:27.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2006-03-12 10:51:31.000000000 +1100
@@ -2491,9 +2491,7 @@
pmac_mb.model_id = PMAC_TYPE_COMET;
iounmap(mach_id_ptr);
}
-#endif /* CONFIG_POWER4 */
-#ifdef CONFIG_6xx
/* Set default value of powersave_nap on machines that support it.
* It appears that uninorth rev 3 has a problem with it, we don't
* enable it on those. In theory, the flush-on-lock property is
@@ -2522,10 +2520,11 @@
* NAP mode
*/
powersave_lowspeed = 1;
-#endif /* CONFIG_6xx */
-#ifdef CONFIG_POWER4
+
+#else /* CONFIG_POWER4 */
powersave_nap = 1;
-#endif
+#endif /* CONFIG_POWER4 */
+
/* Check for "mobile" machine */
if (model && (strncmp(model, "PowerBook", 9) == 0
|| strncmp(model, "iBook", 5) == 0))
^ permalink raw reply
* 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
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