[PATCH] powerpc/44x: Enable 64bit (= 4GB) memory size in Katmai dts
Additionally to increasing #size-cells to in the root node, we also
need to explicitly define the ranges property in the plb node, because
of the different #size-cells between child and parent.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Josh Boyer jwbo...@linux.vnet.ibm.com
---
arch/powerpc/boot/dts/katmai.dts | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
index 077819b..b8cd97c 100644
--- a/arch/powerpc/boot/dts/katmai.dts
+++ b/arch/powerpc/boot/dts/katmai.dts
@@ -16,7 +16,7 @@
/ {
#address-cells = 2;
- #size-cells = 1;
+ #size-cells = 2;
model = amcc,katmai;
compatible = amcc,katmai;
dcr-parent = {/cpus/c...@0};
@@ -49,7 +49,7 @@
memory {
device_type = memory;
- reg = 0x 0x 0x; /* Filled in by
zImage */
+ reg = 0x0 0x 0x0 0x; /* Filled in by U-Boot */
};
UIC0: interrupt-controller0 {
@@ -112,7 +112,15 @@
compatible = ibm,plb-440spe, ibm,plb-440gp, ibm,plb4;
#address-cells = 2;
#size-cells = 1;
- ranges;
+ /*addr-child addr-parentsize */
+ ranges = 0x4 0xe000 0x4 0xe000 0x2000
+ 0xc 0x 0xc 0x 0x2000
+ 0xd 0x 0xd 0x 0x8000
+ 0xd 0x8000 0xd 0x8000 0x8000
+ 0xe 0x 0xe 0x 0x8000
+ 0xe 0x8000 0xe 0x8000 0x8000
+ 0xf 0x 0xf 0x 0x8000
+ 0xf 0x8000 0xf 0x8000 0x8000;
clock-frequency = 0; /* Filled in by zImage */
SDRAM0: sdram {
--
1.6.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
MPC5121e DIU driver - kernel crash writing alpha component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am working on Freescale MPC5121e evaluation board ADS512101 rev. 3 (M34K processor stepping), developing a graphical application. Just switched to ADS512101 rev. 4, 0M36P processor stepping. I have problems with the video framebuffer driver, try to explain: - - app is based on microwindows+fltk, framebuffer driver. On rev3 board working ok. - - rev4 board: using the kernel from ltib 2009/06/02, just adapted fsl-diu-fb.c and .h to support resolution and timings of my lcd panel. The board is booting ok (NFS), but my user space app keeps crashing the kernel. I noticed that in 0M36P processor stepping there are many changes about the video interface (DIU), correcting some bugs of the previous stepping ; seems that when I write to the ram area which is mapped to Panel0 of the DIU the system randomly hangs. After some debugging... 800x480, 32 bits per pixel, using plane1 (first plane, as described in the processor's reference manual). If, from user space, I write some alpha component != 0 in this plane then I have a complete system crash. The reference pdf says There is no alpha component defined for plane1 because there are no planes behind it. I did not yet investigate about writing in other planes ; time is short... For now, patched microwindows driver for writing 0x00 in alpha components, no more hangs. Reported to Freescale FAE, waiting for some answers. Meanwhile: some suggestions about filtering alpha components in the video driver ? I was thinking about some sort of double buffering : user space app (fltk---microwindows) writes in a buffer, then the driver clears alpha to 0x00 and memcpy to the real video buffer. Problems: - - driver / user space sync. Vertical retrace ? ioctl ? - - waste of memory, needs double video buffers Any suggestions are welcome, work in progress. Regards Lucio Dona' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK4VhdvxHCsvXy9okRAtrtAKCaAectSfrHOfzcbTR7KfF9lHCY1QCeOcND HC9fMyGUATKeDL9z9IEzAWc= =ofjv -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: MPC5121e DIU driver - kernel crash writing alpha component
Hi, Pls refer to my comment embedded. -Original Message- From: linuxppc-dev-bounces+hong-jun.chen=freescale@lists.ozlabs. org [mailto:linuxppc-dev-bounces+hong-jun.chen=freescale@lists .ozlabs.org] On Behalf Of LD Sent: Friday, October 23, 2009 3:17 PM To: Linux ppc mailing list; Lucio Dona' Subject: MPC5121e DIU driver - kernel crash writing alpha component -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am working on Freescale MPC5121e evaluation board ADS512101 rev. 3 (M34K processor stepping), developing a graphical application. Just switched to ADS512101 rev. 4, 0M36P processor stepping. I have problems with the video framebuffer driver, try to explain: - - app is based on microwindows+fltk, framebuffer driver. On rev3 board working ok. - - rev4 board: using the kernel from ltib 2009/06/02, just adapted fsl-diu-fb.c and .h to support resolution and timings of my lcd panel. The board is booting ok (NFS), but my user space app keeps crashing the kernel. I noticed that in 0M36P processor stepping there are many changes about the video interface (DIU), correcting some bugs of the previous stepping ; seems that when I write to the ram area which is mapped to Panel0 of the DIU the system randomly hangs. After some debugging... 800x480, 32 bits per pixel, using plane1 (first plane, as described in the processor's reference manual). If, from user space, I write some alpha component != 0 in this plane then I have a complete system crash. The reference pdf says There is no alpha component defined for plane1 because there are no planes behind it. Sure, panel0 doesn't support alpha function, so you can't operate it. I did not yet investigate about writing in other planes ; time is short... For now, patched microwindows driver for writing 0x00 in alpha components, no more hangs. Reported to Freescale FAE, waiting for some answers. Meanwhile: some suggestions about filtering alpha components in the video driver ? You can replace panel0 with panel1, which can support alpha function. I was thinking about some sort of double buffering : user space app (fltk---microwindows) writes in a buffer, then the driver clears alpha to 0x00 and memcpy to the real video buffer. Problems: - - driver / user space sync. Vertical retrace ? ioctl ? - - waste of memory, needs double video buffers Any suggestions are welcome, work in progress. Regards Lucio Dona' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK4VhdvxHCsvXy9okRAtrtAKCaAectSfrHOfzcbTR7KfF9lHCY1QCeOcND HC9fMyGUATKeDL9z9IEzAWc= =ofjv -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC5121e DIU driver - kernel crash writing alpha component
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chen, many thanks for your very fast answer. If I understand well, the situation is as follows: 32 bits mode, plane1 - if I write any alpha component != 0 I have a system hang ; writing alpha components in any other plane is ok. - - - From my first tries I had lockups also in 16 bits 5-6-5 modes, but in this moment I cannot precisely track down things. Is there something I cannot do in plane1 in 16 bits modes ? - - With the previous processor stepping I was not experiencing this problem ; is it something specific from 0M36P ? - - - From this, if I cannot write something in plane1 I would think about a kernel display driver patch: a user program -can not- lock the system by writing something wrong. So... two paths: - - do not publish plane1 as /dev/fb0, but plane2 will be /dev/fb0 or - - see suggestion about double buffering and filtering alpha components Thanks, best regards Lucio Dona' Chen Hongjun-R66092 wrote: Hi, Pls refer to my comment embedded. The board is booting ok (NFS), but my user space app keeps crashing the kernel. If, from user space, I write some alpha component != 0 in this plane then I have a complete system crash. The reference pdf says There is no alpha component defined for plane1 because there are no planes behind it. Sure, panel0 doesn't support alpha function, so you can't operate it. You can replace panel0 with panel1, which can support alpha function. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK4X6XvxHCsvXy9okRApsxAJ40VJ+2/+sP4XW1qoviZlQm6m+0HQCgjkmB p2zNmK+Eyf++r9w0fEQxZxs= =HWm0 -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] spi/mpc52xx: check for invalid PSC usage
Add checks to allow only PSCs capable of SPI.
Also turn printk to dev_err while we are here.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: David Brownell dbrown...@users.sourceforge.net
---
Grant, if the patch is OK, maybe it can also go via your tree?
drivers/spi/mpc52xx_psc_spi.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/mpc52xx_psc_spi.c b/drivers/spi/mpc52xx_psc_spi.c
index 1b74d5c..1d11a6d 100644
--- a/drivers/spi/mpc52xx_psc_spi.c
+++ b/drivers/spi/mpc52xx_psc_spi.c
@@ -467,19 +467,18 @@ static int __init mpc52xx_psc_spi_of_probe(struct
of_device *op,
regaddr_p = of_get_address(op-node, 0, size64, NULL);
if (!regaddr_p) {
- printk(KERN_ERR Invalid PSC address\n);
+ dev_err(op-dev, Invalid PSC address\n);
return -EINVAL;
}
regaddr64 = of_translate_address(op-node, regaddr_p);
- /* get PSC id (1..6, used by port_config) */
+ /* get PSC id (only 1,2,3,6 can do SPI) */
if (op-dev.platform_data == NULL) {
const u32 *psc_nump;
psc_nump = of_get_property(op-node, cell-index, NULL);
- if (!psc_nump || *psc_nump 5) {
- printk(KERN_ERR mpc52xx_psc_spi: Device node %s has
invalid
- cell-index property\n,
op-node-full_name);
+ if (!psc_nump || (*psc_nump 2 *psc_nump != 5)) {
+ dev_err(op-dev, PSC can't do SPI\n);
return -EINVAL;
}
id = *psc_nump + 1;
--
1.6.3.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v9 PATCH 4/9]: x86: refactor x86 idle power management code and remove all instances of pm_idle.
On Fri 2009-10-16 15:13:08, Arun R Bharadwaj wrote:
* Arun R Bharadwaj a...@linux.vnet.ibm.com [2009-10-16 15:08:50]:
This patch cleans up x86 of all instances of pm_idle.
pm_idle which was earlier called from cpu_idle() idle loop
is replaced by cpuidle_idle_call.
x86 also registers to cpuidle when the idle routine is selected,
by populating the cpuidle_device data structure for each cpu.
This is replicated for apm module and for xen, which also used pm_idle.
Signed-off-by: Arun R Bharadwaj a...@linux.vnet.ibm.com
---
arch/x86/kernel/apm_32.c | 55 -
arch/x86/kernel/process.c | 90
--
arch/x86/kernel/process_32.c |3 -
arch/x86/kernel/process_64.c |3 -
arch/x86/xen/setup.c | 40 ++
drivers/acpi/processor_core.c |9 ++--
drivers/cpuidle/cpuidle.c | 16 +--
7 files changed, 182 insertions(+), 34 deletions(-)
...
+static int local_idle_loop(struct cpuidle_device *dev, struct cpuidle_state
*st)
+{
+ ktime_t t1, t2;
+ s64 diff;
+ int ret;
+
+ t1 = ktime_get();
+ local_idle();
+ t2 = ktime_get();
+
+ diff = ktime_to_us(ktime_sub(t2, t1));
+ if (diff INT_MAX)
+ diff = INT_MAX;
+ ret = (int) diff;
+
+ return ret;
+}
So we get this routine essentially 3 times. Is there no way to share
the code?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Page map BUG on program exit
Jake, That is exactly what I needed. Patch 34113 worked like a charm. Thanks for the help! Jonathan Here ya go Jonathan, http://patchwork.ozlabs.org/patch/34047/ http://patchwork.ozlabs.org/patch/34113/ Both patches work for my situation, but I went with the second set as a final patch(34113). - Jake Magee On Thu, Oct 22, 2009 at 3:57 PM, Jonathan Haws jonathan.h...@sdl.usu.edumailto:jonathan.h...@sdl.usu.edu wrote: All, I am using a 405EX CPU on a custom board. The layout and hardware is very similar to the AMCC Kilauea board. Here is the output of uname -a: Linux (none) 2.6.30.3-wolverine-dirty #3 PREEMPT Thu Sep 10 11:41:37 MDT 2009 ppc unknown I am getting the following BUG output when my program exits: BUG: Bad page map in process main pte:980005d7 pmd:0d840400 addr:4800 vm_flags:400844fb anon_vma:(null) mapping:cd8454f8 index:98000 vma-vm_file-f_op-mmap: fpga_mmap+0x0/0x178 [fpgaDriver] Call Trace: [cd84dc40] [c0006f0c] show_stack+0x44/0x16c (unreliable) [cd84dc80] [c00ba314] print_bad_pte+0x140/0x1d0 [cd84dcb0] [c00ba3ec] vm_normal_page+0x48/0x50 [cd84dcc0] [c00bb2ec] unmap_vmas+0x214/0x614 [cd84dd40] [c00bffe0] exit_mmap+0xd0/0x1b4 [cd84dd70] [c0031e40] mmput+0x50/0x134 [cd84dd80] [c0036470] exit_mm+0x114/0x13c [cd84ddb0] [c0037d80] do_exit+0xc0/0x68c [cd84de00] [c0038390] do_group_exit+0x44/0xd8 [cd84de10] [c0044468] get_signal_to_deliver+0x1f8/0x430 [cd84de70] [c0008224] do_signal+0x54/0x29c [cd84df40] [c0010d5c] do_user_signal+0x74/0xc4 I have an FPGA on the PCIe bus that I am mapping BAR0 to user space with a call to mmap(). The mapping works just fine and I can access all the registers in the BAR without a problem. However, on exit this comes up. A Google search showed tons of people with similar problems in standard distributions (Ubuntu primarily), but no resolutions. Has anyone seen this crop up before and know what the issue is? I include any source code, if that is required. Thanks! Jonathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.orgmailto:Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
