Re: [PATCH 2/7] i2c: add info-archdata field
On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote: Hi Anton, On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote: If present the info-archdata is copied into the dev-archdata. Some (OpenFirmware) platforms need it. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- So who's pushing this one ? Jean ? As I wrote before, I'm happy to take this patch if you want me to, but I also have no objection if the author of this patchset wants to push it himself together with the rest of the set. Just let me know what you expect from me (preferably in the next few hours, as I will be sending my second and last round of i2c patches for kernel 2.6.28 to Linus today.) -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] i2c: add info-archdata field
On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote: On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote: Hi Anton, On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote: If present the info-archdata is copied into the dev-archdata. Some (OpenFirmware) platforms need it. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- So who's pushing this one ? Jean ? As I wrote before, I'm happy to take this patch if you want me to, but I also have no objection if the author of this patchset wants to push it himself together with the rest of the set. Just let me know what you expect from me (preferably in the next few hours, as I will be sending my second and last round of i2c patches for kernel 2.6.28 to Linus today.) Anton, I've done my last batch for 2.6.28 before -rc1 so it might be better if it goes through Jean no ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mfd/wm8350: don't export static functions
Hi Mark, On Thu, 16 Oct 2008 13:04:16 +0100 Mark Brown [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 08:47:54PM +1100, Stephen Rothwell wrote: Today's linux-next build (powerpc allyesconfig) failed like this: drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache causes a section type conflict Caused by commit 89b4012befb1abca5e86d232bc0e2a797b0d9825 (mfd: Core support for the WM8350 AudioPlus PMIC). wm8350_create_cache is not used elsewhere, so remove the EXPORT_SYMBOL. Acked-by: Mark Brown [EMAIL PROTECTED] I thought that this had been applied, but I have had to apply it to my tree today again. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpQtA6IfDHdk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mfd/wm8350: don't export static functions
Hi Mark, On Wed, 22 Oct 2008 10:37:22 +0100 Mark Brown [EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 08:31:12PM +1100, Stephen Rothwell wrote: I thought that this had been applied, but I have had to apply it to my tree today again. Samuel doesn't seem to have picked it up (though looking at the CC list you've not sent it to him). I'm going to push another batch of stuff to him later today, hopefully he will pick it up then. OK, thanks. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpOp4ma1esla.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] i2c: add info-archdata field
On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote: On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote: Hi Anton, On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote: If present the info-archdata is copied into the dev-archdata. Some (OpenFirmware) platforms need it. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- So who's pushing this one ? Jean ? As I wrote before, I'm happy to take this patch if you want me to, but I also have no objection if the author of this patchset wants to push it himself together with the rest of the set. Just let me know what you expect from me (preferably in the next few hours, as I will be sending my second and last round of i2c patches for kernel 2.6.28 to Linus today.) Anton, I've done my last batch for 2.6.28 before -rc1 so it might be better if it goes through Jean no ? Sorry, I guess the few hours limit was done exactly when I was sleeping. ;-) Anyway, I'm fine either way. Don't see any problem if it goes i2c or powerpc tree. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
Easier I suppose to just have OF specific hooks in the bus code.
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code being the of_platform_bus_type infrastructure.
Example: instead of Anton's patch #6 modifying the existing pca953x
driver, an of_pca953x driver that knows how to poke around in the OF
device attributes to (a) create the pca953x_platform_data, (b) call
i2c_register_board_info() to make that available later, and then
finally (c) vanish, since it's not needed any longer.
Heh. You tell me my first approach:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056730.html (mmc_spi)
The OF people didn't like the patch which was used to support this
approach:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056728.html
Though, I think I'll able to persuade Grant that two registration paths
are inevitable (i.e. for simple devices we should use
drivers/of/of_{i2c,spi}.c and for complex cases we'll have to have
another method of registration).
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
And try to solve this problem... maybe then things will begin to
move forward.
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] i2c: add info-archdata field
On Wed, 22 Oct 2008 14:08:13 +0400, Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 06:37:55PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2008-10-22 at 08:50 +0200, Jean Delvare wrote: On Wed, 22 Oct 2008 11:27:34 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-10-17 at 11:21 +0200, Jean Delvare wrote: Hi Anton, On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote: If present the info-archdata is copied into the dev-archdata. Some (OpenFirmware) platforms need it. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- So who's pushing this one ? Jean ? As I wrote before, I'm happy to take this patch if you want me to, but I also have no objection if the author of this patchset wants to push it himself together with the rest of the set. Just let me know what you expect from me (preferably in the next few hours, as I will be sending my second and last round of i2c patches for kernel 2.6.28 to Linus today.) Anton, I've done my last batch for 2.6.28 before -rc1 so it might be better if it goes through Jean no ? Sorry, I guess the few hours limit was done exactly when I was sleeping. ;-) Anyway, I'm fine either way. Don't see any problem if it goes i2c or powerpc tree. OK, then I'm taking the patch in my tree and it will go to Linus later today. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote: Hello Everyone, I'm looking for some information about the Extended Addressing Mode (XAEN bit of HID0 register) of PPC32 support in Linux. I do not see anything in the main kernel tree but there may be some patches available ? Any information will be appreciate. Regards. There are patches from Becky Bruce that are going into 2.6.28. What are you needing 32-bit for? There are some SW IO MMU changes that are still pending to complete this work. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Kumar Gala wrote: On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote: Hello Everyone, I'm looking for some information about the Extended Addressing Mode (XAEN bit of HID0 register) of PPC32 support in Linux. I do not see anything in the main kernel tree but there may be some patches available ? Any information will be appreciate. Regards. There are patches from Becky Bruce that are going into 2.6.28. What are you needing 32-bit for? There are some SW IO MMU changes that are still pending to complete this work. - k We are developing a board based on Freescale 8641D which can get 4GB of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. Where can I glance through Becky patches ? -- Régis ODEYE Kontron Modular Computers SA 150, rue M. Berthelot / ZI Toulon Est / BP 244 / Fr 83078 TOULON Cedex 9 Phone: (33) 4 98 16 34 86 Fax: (33) 4 98 16 34 01 E-mail: [EMAIL PROTECTED] Web : www.kontron.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote: Kumar Gala wrote: On Oct 22, 2008, at 3:59 AM, Régis Odeyé wrote: Hello Everyone, I'm looking for some information about the Extended Addressing Mode (XAEN bit of HID0 register) of PPC32 support in Linux. I do not see anything in the main kernel tree but there may be some patches available ? Any information will be appreciate. Regards. There are patches from Becky Bruce that are going into 2.6.28. What are you needing 32-bit for? There are some SW IO MMU changes that are still pending to complete this work. - k We are developing a board based on Freescale 8641D which can get 4GB of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. So we have XAEN support in the tree.. however non-contiguous is something you'll have to work on yourself. Patches are welcome for this Where can I glance through Becky patches ? This is the bulk: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ee7084eb11e00eb02dc8435fd18273a61ffa9bf - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
I'm extremely troubled that it is not used in the code,
surely device_type is checked as a legacy for Open Firmware
(otherwise a lot of devices may never be detected!), or does
device tree parsing/checking follow a different path for FDT?
(absolutely fine with it being removed from new DTS but, just
concerned about your comment and it's impact...)
--
Matt Sealey [EMAIL PROTECTED]
Genesi, Manager, Developer Relations
Anton Vorontsov wrote:
We don't want to encourage the device_type usage. It isn't used in the
code, so we can simply remove it from the dts files.
Suggested-by: Scott Wood [EMAIL PROTECTED]
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/kuroboxHD.dts |1 -
arch/powerpc/boot/dts/kuroboxHG.dts |1 -
arch/powerpc/boot/dts/lite5200.dts |1 -
arch/powerpc/boot/dts/lite5200b.dts |1 -
arch/powerpc/boot/dts/motionpro.dts |1 -
arch/powerpc/boot/dts/mpc8315erdb.dts|1 -
arch/powerpc/boot/dts/mpc8349emitx.dts |1 -
arch/powerpc/boot/dts/mpc8349emitxgp.dts |1 -
arch/powerpc/boot/dts/mpc8377_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8378_rdb.dts|1 -
arch/powerpc/boot/dts/mpc8379_rdb.dts|1 -
arch/powerpc/boot/dts/pcm030.dts |2 --
arch/powerpc/boot/dts/tqm5200.dts|1 -
13 files changed, 0 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/boot/dts/kuroboxHD.dts
b/arch/powerpc/boot/dts/kuroboxHD.dts
index 2e5a1a1..8d725d1 100644
--- a/arch/powerpc/boot/dts/kuroboxHD.dts
+++ b/arch/powerpc/boot/dts/kuroboxHD.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/kuroboxHG.dts
b/arch/powerpc/boot/dts/kuroboxHG.dts
index e4916e6..b13a11e 100644
--- a/arch/powerpc/boot/dts/kuroboxHG.dts
+++ b/arch/powerpc/boot/dts/kuroboxHG.dts
@@ -76,7 +76,6 @@ add flash parts, rtc, ??
interrupt-parent = mpic;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = ricoh,rs5c372a;
reg = 0x32;
};
diff --git a/arch/powerpc/boot/dts/lite5200.dts
b/arch/powerpc/boot/dts/lite5200.dts
index 2cf9a87..3f7a5dc 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts
b/arch/powerpc/boot/dts/lite5200b.dts
index 7bd5b9c..63e3bb4 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -130,7 +130,6 @@
[EMAIL PROTECTED] { // Real time clock
compatible = fsl,mpc5200b-rtc,fsl,mpc5200-rtc;
- device_type = rtc;
reg = 0x800 0x100;
interrupts = 1 5 0 1 6 0;
interrupt-parent = mpc5200_pic;
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 9e3c921..52ba6f9 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -248,7 +248,6 @@
fsl5200-clocking;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 6b85067..d3d3097 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -117,7 +117,6 @@
interrupt-parent = ipic;
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
};
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 2c9d54a..d86c6a3 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -85,7 +85,6 @@
dfsrr;
[EMAIL PROTECTED] {
- device_type = rtc;
compatible = dallas,ds1339;
reg = 0x68;
interrupts = 18 0x8;
diff --git
Re: Extended Addressing Mode
Kumar Gala wrote: So we have XAEN support in the tree.. however non-contiguous is something you'll have to work on yourself. Patches are welcome for this OK. I will let you know about this. Where can I glance through Becky patches ? This is the bulk: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ee7084eb11e00eb02dc8435fd18273a61ffa9bf Thank you very much, Sir. -- Régis ODEYE Kontron Modular Computers SA 150, rue M. Berthelot / ZI Toulon Est / BP 244 / Fr 83078 TOULON Cedex 9 Phone: (33) 4 98 16 34 86 Fax: (33) 4 98 16 34 01 E-mail: [EMAIL PROTECTED] Web : www.kontron.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Kumar Gala wrote: On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote: of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. So we have XAEN support in the tree.. however non-contiguous is something you'll have to work on yourself. Patches are welcome for this So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Where can I glance through Becky patches ? This is the bulk: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ee7084eb11e00eb02dc8435fd18273a61ffa9bf I'd also be interested in any work done to enable non-contiguous memory areas. Reading the docs for the MPC8641D though I am not sure you can set up LAWs for it? One thing I wanted to try was installing 4GB in a system and overlapping IO (since there is very little of it on a stock MPC8641DHPCN) in the top ~256MB-512MB, but I am fairly sure this is NOT supported because of the way the LAWs work, and also the alignment of the LAWs means it is not fine enough granularity to map between 2GB and 4GB into a window (you can have 2GB or 4GB but not some more arbitrary value?) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote: I'm extremely troubled that it is not used in the code, surely device_type is checked as a legacy for Open Firmware (otherwise a lot of devices may never be detected!), Checked where? Can you point out a code snippet? (Except for CHRP platforms, the CHRP is running real OF, so it is irrelevant if it checks for device_type = rtc or not.) or does device tree parsing/checking follow a different path for FDT? (absolutely fine with it being removed from new DTS but, just concerned about your comment and it's impact...) -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote: Kumar Gala wrote: On Oct 22, 2008, at 7:59 AM, Régis Odeyé wrote: of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. So we have XAEN support in the tree.. however non-contiguous is something you'll have to work on yourself. Patches are welcome for this So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Yes, its the only part that has XAEN. Where can I glance through Becky patches ? This is the bulk: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4ee7084eb11e00eb02dc8435fd18273a61ffa9bf I'd also be interested in any work done to enable non-contiguous memory areas. Reading the docs for the MPC8641D though I am not sure you can set up LAWs for it? You can if you can configure your DDR to support it. One thing I wanted to try was installing 4GB in a system and overlapping IO (since there is very little of it on a stock MPC8641DHPCN) in the top ~256MB-512MB, but I am fairly sure this is NOT supported because of the way the LAWs work, and also the alignment of the LAWs means it is not fine enough granularity to map between 2GB and 4GB into a window (you can have 2GB or 4GB but not some more arbitrary value?) You can overlap LAWs because they have priority encoding. The lower the LAW # the higher the priority. Your bigger issue is if you can setup the DDR controller for the hole you want. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Matt Sealey wrote: I'd also be interested in any work done to enable non-contiguous memory areas. Reading the docs for the MPC8641D though I am not sure you can set up LAWs for it? One thing I wanted to try was installing 4GB in a system and overlapping IO (since there is very little of it on a stock MPC8641DHPCN) in the top ~256MB-512MB, but I am fairly sure this is NOT supported because of the way the LAWs work, and also the alignment of the LAWs means it is not fine enough granularity to map between 2GB and 4GB into a window (you can have 2GB or 4GB but not some more arbitrary value?) On my point of view, LAWs sizes are power of 2 and should be aligned to the window size. But there is 10 LAWs you can combine to achieve quite a lot of different mappings. Regards. -- Régis ODEYE Kontron Modular Computers SA 150, rue M. Berthelot / ZI Toulon Est / BP 244 / Fr 83078 TOULON Cedex 9 Phone: (33) 4 98 16 34 86 Fax: (33) 4 98 16 34 01 E-mail: [EMAIL PROTECTED] Web : www.kontron.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Kumar Gala wrote: On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote: So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Yes, its the only part that has XAEN. Okay I saw a lot of e500/BookE support go past but nothing specific :) NOT supported because of the way the LAWs work, and also the alignment of the LAWs means it is not fine enough granularity to map between 2GB and 4GB into a window (you can have 2GB or 4GB but not some more arbitrary value?) You can overlap LAWs because they have priority encoding. The lower the LAW # the higher the priority. Hmm :) Your bigger issue is if you can setup the DDR controller for the hole you want. Hm :) Okay good to know. I'll go back to reading the docs. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Kumar Gala wrote: Your bigger issue is if you can setup the DDR controller for the hole you want. I just remembered;; ~~ The CCSR window always takes precedence over all local access windows. However, the CCSR window must not overlap an LAW that maps to the DDR controller. Otherwise, undefined behavior occurs. ~~ So, it's not really possible to map 4GB of RAM in the lower 32-bit area, without interacting badly with the CCSR. This means you're forced to select a 2GB LAW for DDR, then leave 2GB free, then map the rest above.. using more than 2Gb therefore absolutely requires non-contiguous memory..? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
Hi Ilya, I just tried your patch on my 440 board because it would help us in our environment. Unfortunately I run into a bug on early boot (mark_bootmem). A log can be found in this mail, this is the bug when running with 64k page size. I tried this with and without your 2/2 265k patch and also with page size configured to 16k, the error is the same in all cases. I used an earlier version of your patch in the past and it worked fine. Applying this old patch causes the same problem. Therefore I expect that there was some other code changed that breaks with page size != 4k. I did not check that in detail yet, but I would be happy for every hint I could get to fix this. = bootm ## Booting kernel from Legacy Image at 0400 ... Image Name: Linux-2.6.27-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1512203 Bytes = 1.4 MB Load Address: 0040 Entry Point: 00400458 Verifying Checksum ... OK Uncompressing Kernel Image ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) Memory - 0x0 0x0 0x000 (255MB) ethernet0: local-mac-address - 00:10:ec:00:e2:3e ethernet1: local-mac-address - 00:10:ec:80:e2:3e zImage starting: loaded at 0x0040 (sp: 0x0fe3c820) Allocating 0x3c54dc bytes for kernel ... gunzipping (0x - 0x0040e000:0x007a2428)...done 0x380a90 bytes Linux/PowerPC load: console=ttyS0,115200 ip=dhcp nfsroot=192.168.1.2:/home/paelzer/ubuntu_ppc.8.04 root=/dev/nfs rw Finalizing device tree... flat tree at 0x40bed8 Using PowerPC 44x Platform machine description Linux version 2.6.27-dirty ([EMAIL PROTECTED]) (gcc version 4.2.3) #5 Wed Oct 22 15:15:40 CEST 2008 console [udbg0] enabled [ cut here ] Kernel BUG at c02be6cc [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] PowerPC 44x Platform NIP: c02be6cc LR: c02ba4e4 CTR: REGS: c0351eb0 TRAP: 0700 Not tainted (2.6.27-dirty) MSR: 00021000 ME CR: 22004022 XER: 005f TASK = c03204a8[0] 'swapper' THREAD: c035 GPR00: c02d0a1c c0351f60 c03204a8 0fff 1000 0001 GPR08: e000 c02d0a14 2224 0ffa6800 0ffbf000 GPR16: c02ed838 bfe8f45c 0ffa7500 0fe3cb20 0001 c02d0a1c GPR24: 0001 1000 0fff c039 0fff c039d1d0 c02d0a08 NIP [c02be6cc] mark_bootmem+0xe0/0x124 LR [c02ba4e4] do_init_bootmem+0x134/0x168 Call Trace: [c0351f60] [c02be6a4] mark_bootmem+0xb8/0x124 (unreliable) [c0351f90] [c02ba4e4] do_init_bootmem+0x134/0x168 [c0351fb0] [c02b8e00] setup_arch+0x13c/0x1b8 [c0351fc0] [c02b066c] start_kernel+0x94/0x2ac [c0351ff0] [c1e8] skpinv+0x190/0x1cc Instruction dump: 7f07c378 4bfffe15 7c7e1b78 4192000c 2f83 409e0024 7f9ae000 419e0050 817f0014 83bf0004 3bebffec 4b68 0fe0 4800 7f63db78 7fa4eb78 ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. Ilya Yanok wrote: This patch adds support for page sizes bigger than 4K (16K/64K) on PPC 44x. Signed-off-by: Yuri Tikhonov [EMAIL PROTECTED] Signed-off-by: Vladimir Panfilov [EMAIL PROTECTED] Signed-off-by: Ilya Yanok [EMAIL PROTECTED] --- arch/powerpc/Kconfig | 26 -- arch/powerpc/include/asm/highmem.h |8 +++- arch/powerpc/include/asm/mmu-44x.h | 18 ++ arch/powerpc/include/asm/page.h| 13 - arch/powerpc/include/asm/pgtable.h |3 +++ arch/powerpc/kernel/asm-offsets.c |4 arch/powerpc/kernel/head_44x.S | 22 +- arch/powerpc/kernel/misc_32.S | 12 ++-- arch/powerpc/mm/pgtable_32.c |9 ++--- arch/powerpc/platforms/Kconfig.cputype |2 +- 10 files changed, 82 insertions(+), 35 deletions(-) diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 587da5e..9627cfd 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -402,16 +402,30 @@ config PPC_HAS_HASH_64K depends on PPC64 default n -config PPC_64K_PAGES - bool 64k page size - depends on PPC64 - select PPC_HAS_HASH_64K +choice + prompt Page size + default PPC_4K_PAGES help - This option changes the kernel logical page size to 64k. On machines + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases like software + RAID with accelerated calculations. In PPC64 case on machines
[PATCH] powerpc: XICS - fix getting the server number size
The 'ibm,interrupt-server#-size' properties are not cpu nodes properties,
but rather live under the interrupt source controller nodes (compatible
ibm,ppc-xics).
Therefore, this patch moves the detection of this property outside of
xics_update_irq_servers() and into xics_init_IRQ().
Also this adds a check for mismatched sizes across the interrupt source
controller nodes. Not sure this is necessary as in this case the firmware
might be seriously busted.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Milton Miller [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 28 ++--
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index e190477..75a289b 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -579,7 +579,7 @@ static void xics_update_irq_servers(void)
int i, j;
struct device_node *np;
u32 ilen;
- const u32 *ireg, *isize;
+ const u32 *ireg;
u32 hcpuid;
/* Find the server numbers for the boot cpu. */
@@ -607,11 +607,6 @@ static void xics_update_irq_servers(void)
}
}
- /* get the bit size of server numbers */
- isize = of_get_property(np, ibm,interrupt-server#-size, NULL);
- if (isize)
- interrupt_server_size = *isize;
-
of_node_put(np);
}
@@ -682,6 +677,7 @@ void __init xics_init_IRQ(void)
struct device_node *np;
u32 indx = 0;
int found = 0;
+ const u32 *isize;
ppc64_boot_msg(0x20, XICS Init);
@@ -701,6 +697,26 @@ void __init xics_init_IRQ(void)
if (found == 0)
return;
+ /* get the bit size of server numbers */
+ found = 0;
+
+ for_each_compatible_node(np, NULL, ibm,ppc-xics) {
+ isize = of_get_property(np, ibm,interrupt-server#-size, NULL);
+
+ if (!isize)
+ continue;
+
+ if (!found) {
+ interrupt_server_size = *isize;
+ found = 1;
+ } else if (*isize != interrupt_server_size) {
+ printk(KERN_WARNING XICS:
+ mismatched ibm,interrupt-server#-size\n);
+ interrupt_server_size = max(*isize,
+ interrupt_server_size);
+ }
+ }
+
xics_update_irq_servers();
xics_init_host();
--
1.6.0.1.308.gede4c
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote: Kumar Gala wrote: On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote: So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Yes, its the only part that has XAEN. Okay I saw a lot of e500/BookE support go past but nothing specific :) The XAEN is specific to e600. e500 has its own ability to do 36-bit physical (not called XAEN). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote: Kumar Gala wrote: Your bigger issue is if you can setup the DDR controller for the hole you want. I just remembered;; ~~ The CCSR window always takes precedence over all local access windows. However, the CCSR window must not overlap an LAW that maps to the DDR controller. Otherwise, undefined behavior occurs. ~~ So, it's not really possible to map 4GB of RAM in the lower 32-bit area, without interacting badly with the CCSR. This means you're forced to select a 2GB LAW for DDR, then leave 2GB free, then map the rest above.. using more than 2Gb therefore absolutely requires non-contiguous memory..? As I said, its all about your physical DDR layout. If you have two DDR dimms each 2Gb you can do: 0..2G - DDR DIMM A 2G..4G - IO 4G..6G - DDR DIMM B - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build failure on powerpc with current -git
On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras [EMAIL PROTECTED] wrote: Stephen Rothwell writes: On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED] wrote: It's a bug in older versions of ld (including 2.16.1) that's fixed in the current version (2.18). However, this patch appears to work around the problem - at least, it let me build a 32-bit kernel with a cross-toolchain including a 2.16.1 ld. Let me know if this gets it working for you. With that patch applied I got these errors for a powerpc ppc64_defconfig build (linux-next). /usr/bin/objcopy: Warning: '/dev/null' is not an ordinary file Hmmm, so do I, and in fact the arch/powerpc/boot/wrapper change now seems to be unnecessary with my cross-compile setup (which has ld 2.16.1), whereas yesterday I'm sure it got errors. Weird. Chris, could you try just the following change (my previous patch without the arch/powerpc/boot/wrapper change) and let me know if it fixes things with the ld you use? Works for me. binutils 2.16.1 is the most recent binutils that will build with crosstool, so IMHO it's worth supporting. :) -Hollis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCHv3 1/1] powerpc: Update page in counter for CMM
A new field has been added to the VPA as a method for
the client OS to communicate to firmware the number of
page ins it is performing when running collaborative
memory overcommit. The hypervisor will use this information
to better determine if a partition is experiencing memory
pressure and needs more memory allocated to it.
Signed-off-by: Brian King [EMAIL PROTECTED]
---
arch/powerpc/include/asm/lppaca.h |3 ++-
arch/powerpc/kernel/paca.c|1 +
arch/powerpc/mm/fault.c | 12 ++--
3 files changed, 13 insertions(+), 3 deletions(-)
diff -puN arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure
arch/powerpc/mm/fault.c
--- linux-2.6/arch/powerpc/mm/fault.c~powerpc_vrm_mm_pressure 2008-10-20
17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/mm/fault.c 2008-10-22 08:53:13.0
-0500
@@ -30,6 +30,7 @@
#include linux/kprobes.h
#include linux/kdebug.h
+#include asm/firmware.h
#include asm/page.h
#include asm/pgtable.h
#include asm/mmu.h
@@ -318,9 +319,16 @@ good_area:
goto do_sigbus;
BUG();
}
- if (ret VM_FAULT_MAJOR)
+ if (ret VM_FAULT_MAJOR) {
current-maj_flt++;
- else
+#ifdef CONFIG_PPC_SMLPAR
+ if (firmware_has_feature(FW_FEATURE_CMO)) {
+ preempt_disable();
+ get_lppaca()-page_ins++;
+ preempt_enable();
+ }
+#endif
+ } else
current-min_flt++;
up_read(mm-mmap_sem);
return 0;
diff -puN arch/powerpc/include/asm/lppaca.h~powerpc_vrm_mm_pressure
arch/powerpc/include/asm/lppaca.h
--- linux-2.6/arch/powerpc/include/asm/lppaca.h~powerpc_vrm_mm_pressure
2008-10-20 17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/include/asm/lppaca.h 2008-10-21
13:46:45.0 -0500
@@ -133,7 +133,8 @@ struct lppaca {
//=
// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=
- u8 pmc_save_area[256]; // PMC interrupt Area x00-xFF
+ u32 page_ins; // CMO Hint - # page ins by OS
x00-x04
+ u8 pmc_save_area[252]; // PMC interrupt Area x04-xFF
} __attribute__((__aligned__(0x400)));
extern struct lppaca lppaca[];
diff -puN arch/powerpc/kernel/paca.c~powerpc_vrm_mm_pressure
arch/powerpc/kernel/paca.c
--- linux-2.6/arch/powerpc/kernel/paca.c~powerpc_vrm_mm_pressure
2008-10-20 17:13:25.0 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/paca.c2008-10-20
17:13:25.0 -0500
@@ -37,6 +37,7 @@ struct lppaca lppaca[] = {
.end_of_quantum = 0xul,
.slb_count = 64,
.vmxregs_in_use = 0,
+ .page_ins = 0,
},
};
_
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] mutex: optimise generic mutex implementations
* Nick Piggin [EMAIL PROTECTED] wrote: Speed up generic mutex implementations. - atomic operations which both modify the variable and return something imply full smp memory barriers before and after the memory operations involved (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because they don't modify the target). See Documentation/atomic_ops.txt. So remove extra barriers and branches. - All architectures support atomic_cmpxchg. This has no relation to __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally This reduces a simple single threaded fastpath lock+unlock test from 590 cycles to 203 cycles on a ppc970 system. Signed-off-by: Nick Piggin [EMAIL PROTECTED] no objections here. Lets merge these two patches via the ppc tree, so that it gets testing on real hardware as well? Acked-by: Ingo Molnar [EMAIL PROTECTED] Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] mutex: optimise generic mutex implementations
Nick Piggin [EMAIL PROTECTED] wrote: Speed up generic mutex implementations. - atomic operations which both modify the variable and return something imply full smp memory barriers before and after the memory operations involved (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because they don't modify the target). See Documentation/atomic_ops.txt. So remove extra barriers and branches. - All architectures support atomic_cmpxchg. This has no relation to __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally This reduces a simple single threaded fastpath lock+unlock test from 590 cycles to 203 cycles on a ppc970 system. Signed-off-by: Nick Piggin [EMAIL PROTECTED] This seems to work on FRV which uses the mutex-dec generic algorithm, though you have to take that with a pinch of salt as I don't have SMP hardware for it. Acked-by: David Howells [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
oops in net_rx_action
I just tried booting a post 2.6.27 -git on a Motorola ATCA6101 (very similar to a Maple board). The first time I booted I got the first log below. I rebooted and got as far as a login prompt. I was able to log in via the serial console, but then got an almost identical oops again, as shown in the second log below. Anyone have any idea what might be causing this? I'm going to try configging out the gigE drivers for the backplane, but I thought I'd see if this is a known issue first. Thanks, Chris Starting xinetd: [ OK ] Starting cron: [ OK ] Unable to handle kernel paging request for data at address 0x00100108 Faulting instruction address: 0xc028c1cc Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 Maple Modules linked in: NIP: c028c1cc LR: c028c13c CTR: REGS: cfff7b90 TRAP: 0300 Not tainted (2.6.27-05329-g39076ba) MSR: 90009032 EE,ME,IR,DR CR: 2224 XER: 2000 DAR: 00100108, DSISR: 0a00 TASK = c0017a061080[0] 'swapper' THREAD: c0017a078000 CPU: 1 GPR00: cfff7e10 c059bfe0 0020 GPR04: 0001 c00178179800 c027fda8 GPR08: 00200200 0001 00100100 GPR12: 2222 c05bc500 GPR16: GPR20: 000a 0001 0001 GPR24: c05a2280 c05f5134 fffd9bbe 00ec GPR28: c6e30c28 0020 c0543440 c0017a279b40 NIP [c028c1cc] .net_rx_action+0x1e4/0x26c LR [c028c13c] .net_rx_action+0x154/0x26c Call Trace: [cfff7e10] [c028c13c] .net_rx_action+0x154/0x26c (unreliable) [cfff7ec0] [c0056938] .__do_softirq+0xf8/0x1f4 [cfff7f90] [c0024334] .call_do_softirq+0x14/0x24 [c0017a07b970] [c000bcdc] .do_softirq+0xf0/0x104 [c0017a07ba10] [c0056ae8] .irq_exit+0x70/0x88 [c0017a07ba90] [c000ba18] .do_IRQ+0x14c/0x244 [c0017a07bb30] [c0004710] hardware_interrupt_entry+0x18/0x1c --- Exception: 501 at .raw_local_irq_restore+0x38/0x44 LR = .cpu_idle+0xd8/0x154 [c0017a07be20] [c0012068] .cpu_idle+0x118/0x154 (unreliable) [c0017a07bec0] [c03d4304] .start_secondary+0x310/0x3e8 [c0017a07bf90] [c00072b4] .start_secondary_prolog+0x10/0x14 Instruction dump: eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 e81f0010 7809ffe3 40820038 e93f0008 e97f f92b0008 f969 e95c0008 fb9f [EMAIL PROTECTED]:/root uname -a Linux 10.41.18.77 2.6.27-05329-g39076ba #1 SMP Tue Oct 21 16:46:06 CST 2008 ppc64 GNU/Linux [EMAIL PROTECTED]:/root Unable to handle kernel paging request for data at address 0x00100108 Faulting instruction address: 0xc028c1cc Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 Maple Modules linked in: NIP: c028c1cc LR: c028c13c CTR: REGS: cfff7b90 TRAP: 0300 Not tainted (2.6.27-05329-g39076ba) MSR: 90009032 EE,ME,IR,DR CR: 2224 XER: 2000 DAR: 00100108, DSISR: 0a00 TASK = c0017a061080[0] 'swapper' THREAD: c0017a078000 CPU: 1 GPR00: cfff7e10 c059bfe0 0020 GPR04: 0001 0001 c027fda8 GPR08: 00200200 0001 00100100 GPR12: 2222 c05bc500 GPR16: GPR20: 000a 0001 0001 GPR24: c05a2280 c05f5134 0001000387ff 010c GPR28: c6e30c28 0020 c0543440 c0017a2b0b40 NIP [c028c1cc] .net_rx_action+0x1e4/0x26c LR [c028c13c] .net_rx_action+0x154/0x26c Call Trace: [cfff7e10] [c028c13c] .net_rx_action+0x154/0x26c (unreliable) [cfff7ec0] [c0056938] .__do_softirq+0xf8/0x1f4 [cfff7f90] [c0024334] .call_do_softirq+0x14/0x24 [c0017a07b970] [c000bcdc] .do_softirq+0xf0/0x104 [c0017a07ba10] [c0056ae8] .irq_exit+0x70/0x88 [c0017a07ba90] [c000ba18] .do_IRQ+0x14c/0x244 [c0017a07bb30] [c0004710] hardware_interrupt_entry+0x18/0x1c --- Exception: 501 at .cpu_idle+0xf0/0x154 LR = .cpu_idle+0xd8/0x154 [c0017a07be20] [c0012068] .cpu_idle+0x118/0x154 (unreliable) [c0017a07bec0] [c03d4304] .start_secondary+0x310/0x3e8 [c0017a07bf90] [c00072b4] .start_secondary_prolog+0x10/0x14 Instruction dump: eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 7c0803a6 4e800020 e81f0010 7809ffe3 40820038 e93f0008 e97f f92b0008 f969 e95c0008
Re: build failure on powerpc with current -git
Paul Mackerras wrote: Chris, could you try just the following change (my previous patch without the arch/powerpc/boot/wrapper change) and let me know if it fixes things with the ld you use? The build completes with no errors. Haven't actually booted it though. Gets my vote... Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
Ilya, here the snippet you asked for with CONFIG_DEBUG_BUGVERBOSE enabled and bootmem_debug set. ## Booting kernel from Legacy Image at 0400 ... Image Name: Linux-2.6.27-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1521505 Bytes = 1.5 MB Load Address: 0040 Entry Point: 00400458 Verifying Checksum ... OK Uncompressing Kernel Image ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) Memory - 0x0 0x0 0x000 (255MB) ethernet0: local-mac-address - 00:10:ec:00:e2:3e ethernet1: local-mac-address - 00:10:ec:80:e2:3e zImage starting: loaded at 0x0040 (sp: 0x0fe3c820) Allocating 0x3d54dc bytes for kernel ... gunzipping (0x - 0x0040e000:0x007b24a4)...done 0x390af8 bytes Linux/PowerPC load: console=ttyS0,115200 ip=dhcp nfsroot=192.168.1.2:/home/paelzer/ubuntu_ppc.8.04 root=/dev/nfs rw bootmem_debug Finalizing device tree... flat tree at 0x40bed8 Using PowerPC 44x Platform machine description Linux version 2.6.27-dirty ([EMAIL PROTECTED]) (gcc version 4.2.3) #12 Wed Oct 22 19:40:49 CEST 2008 console [udbg0] enabled bootmem::init_bootmem_core nid=0 start=0 map=ffd end=fff mapsize=200 bootmem::mark_bootmem_node nid=0 start=0 end=fff reserve=0 flags=0 bootmem::__free nid=0 start=0 end=fff bootmem::mark_bootmem_node nid=0 start=0 end=3e reserve=1 flags=0 bootmem::__reserve nid=0 start=0 end=3e flags=0 bootmem::mark_bootmem_node nid=0 start=40 end=41 reserve=1 flags=0 bootmem::__reserve nid=0 start=40 end=41 flags=0 bootmem::mark_bootmem_node nid=0 start=ffd end=fff reserve=1 flags=0 bootmem::__reserve nid=0 start=ffd end=fff flags=0 [ cut here ] kernel BUG at mm/bootmem.c:320! Oops: Exception in kernel mode, sig: 5 [#1] PowerPC 44x Platform NIP: c02ce838 LR: c02ca4e4 CTR: c000dcf8 REGS: c0361eb0 TRAP: 0700 Not tainted (2.6.27-dirty) MSR: 00021000 ME CR: 22004022 XER: 005f TASK = c03304a8[0] 'swapper' THREAD: c036 GPR00: c02e0c98 c0361f60 c03304a8 0fff 1000 0001 4000 GPR08: e000 c02e0c90 2224 0ffa6800 0ffbf000 GPR16: 100c 100c 0ffa7500 0fe3cb20 0001 c02e0c98 GPR24: 0001 1000 0fff c03a 0fff c03ad1e0 c02e0c84 NIP [c02ce838] mark_bootmem+0xe0/0x124 LR [c02ca4e4] do_init_bootmem+0x134/0x168 Call Trace: [c0361f60] [c02ce810] mark_bootmem+0xb8/0x124 (unreliable) [c0361f90] [c02ca4e4] do_init_bootmem+0x134/0x168 [c0361fb0] [c02c8e00] setup_arch+0x13c/0x1b8 [c0361fc0] [c02c066c] start_kernel+0x94/0x2ac [c0361ff0] [c1e8] skpinv+0x190/0x1cc Instruction dump: 7f07c378 4bfffe15 7c7e1b78 4192000c 2f83 409e0024 7f9ae000 419e0050 817f0014 83bf0004 3bebffec 4b68 0fe0 4800 7f63db78 7fa4eb78 ---[ end trace 31fd0ba7d8756001 ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. Christian Ehrhardt wrote: Hi Ilya, I just tried your patch on my 440 board because it would help us in our environment. Unfortunately I run into a bug on early boot (mark_bootmem). A log can be found in this mail, this is the bug when running with 64k page size. I tried this with and without your 2/2 265k patch and also with page size configured to 16k, the error is the same in all cases. I used an earlier version of your patch in the past and it worked fine. Applying this old patch causes the same problem. Therefore I expect that there was some other code changed that breaks with page size != 4k. I did not check that in detail yet, but I would be happy for every hint I could get to fix this. = bootm ## Booting kernel from Legacy Image at 0400 ... Image Name: Linux-2.6.27-dirty Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1512203 Bytes = 1.4 MB Load Address: 0040 Entry Point: 00400458 Verifying Checksum ... OK Uncompressing Kernel Image ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - 42ecac (4MHz) Memory - 0x0 0x0 0x000 (255MB) ethernet0: local-mac-address - 00:10:ec:00:e2:3e ethernet1: local-mac-address - 00:10:ec:80:e2:3e zImage starting: loaded at 0x0040 (sp: 0x0fe3c820) Allocating
Re: Extended Addressing Mode
Kumar Gala wrote: On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote: Kumar Gala wrote: On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote: So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Yes, its the only part that has XAEN. Okay I saw a lot of e500/BookE support go past but nothing specific :) The XAEN is specific to e600. e500 has its own ability to do 36-bit physical (not called XAEN). You have to forgive me I was only half awake when I started :D Yeah so I saw BookE and e500 stuff go past but nothing specific for e600/XAEN. I mailed Becky and got no response. I'm glad to know it's in there though, somewhere. Just so it has been asked, do you know in a broad sense what it would take to add the non-contiguous memory mapping support? Doesn't ppc64 already have this? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build failure on powerpc with current -git
Hollis Blanchard wrote: binutils 2.16.1 is the most recent binutils that will build with crosstool, so IMHO it's worth supporting. :) I was wondering about thatwasted a bunch of time trying to build something more recent. Chris ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Kumar Gala wrote: On Oct 22, 2008, at 9:22 AM, Matt Sealey wrote: ~~ The CCSR window always takes precedence over all local access windows. However, the CCSR window must not overlap an LAW that maps to the DDR controller. Otherwise, undefined behavior occurs. ~~ So, it's not really possible to map 4GB of RAM in the lower 32-bit area, without interacting badly with the CCSR. This means you're forced to select a 2GB LAW for DDR, then leave 2GB free, then map the rest above.. using more than 2Gb therefore absolutely requires non-contiguous memory..? As I said, its all about your physical DDR layout. If you have two DDR dimms each 2Gb you can do: 0..2G - DDR DIMM A 2G..4G - IO 4G..6G - DDR DIMM B I assume on the HPCN DDR DIMM A would be one or both of one set of DDR slots, and DDR DIMM B would be one or both o the other set (since there are 4 slots, two for each controller)? Or are we talking about actual, physical DIMMs? If we're talking about controllers, could you not do; 0..2GB DDR Controller 1 (partial) 2G..4GB IO 4GB..NGB DDR Controller 1 (the rest) NGB-64GB DDR Controller 2 (or whatever) Or do LAWs not cooperate when for the same target? I would assume if you set up the CSn_BNDS registers right you could get a real fine grained mapping of DDR controller to memory space in combination with the LAWs? It would then be actually possible (however disgusting this config would be) to have a 2GB DIMM, 1GB DIMM on the first controller with two LAWs, and the appropriate chip selects, then 1GB IO space, then up to 32GB (since 16GB DIMMs are about as high as it goes for DDR2) memory space mapped after that, with a single LAW? Or more comfortably, pair up 2x 2GB DIMMs and simply ignore the last 1GB, and pair up 2x 16GB DIMMs? -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 02:46:06PM +0400, Anton Vorontsov wrote:
On Wed, Oct 22, 2008 at 02:36:41PM +0400, Anton Vorontsov wrote:
On Tue, Oct 21, 2008 at 09:22:48PM -0700, David Brownell wrote:
On Tuesday 21 October 2008, Benjamin Herrenschmidt wrote:
The notifier can be registered before the devices, though it's a little
bit fishy and fragile.
Easier I suppose to just have OF specific hooks in the bus code.
Like what I suggested: chip-aware OF glue drivers. The relevant
bus code being the of_platform_bus_type infrastructure.
Example: instead of Anton's patch #6 modifying the existing pca953x
driver, an of_pca953x driver that knows how to poke around in the OF
device attributes to (a) create the pca953x_platform_data, (b) call
i2c_register_board_info() to make that available later, and then
finally (c) vanish, since it's not needed any longer.
Heh. You tell me my first approach:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056730.html (mmc_spi)
The OF people didn't like the patch which was used to support this
approach:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/056728.html
Though, I think I'll able to persuade Grant that two registration paths
are inevitable (i.e. for simple devices we should use
drivers/of/of_{i2c,spi}.c and for complex cases we'll have to have
another method of registration).
The board info has another problem though. We can't remove it, thus
we can't implement module_exit() for the 'OF glue'.
And try to solve this problem... maybe then things will begin to
move forward.
There is another problem: board infos are scanned at the controller
registration time only. So if we register the board infos after
the controller registered, then nobody will probe the board infos.
This is all solvable by hacking the i2c core code though. I started
it, but it turned out to be ugly. I'll finish it though, just to show
it someday.
But now I'm not sure if it worth the efforts. Maybe we could just
modify the drivers to do something like this?
This is not exactly transparently to the drivers, but well..
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 01b4bbd..b1dfa7b 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -9,4 +9,7 @@ obj-$(CONFIG_GPIO_MAX732X) += max732x.o
obj-$(CONFIG_GPIO_MCP23S08)+= mcp23s08.o
obj-$(CONFIG_GPIO_PCA953X) += pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += pcf857x.o
+ifeq ($(CONFIG_OF),y)
+obj-$(CONFIG_GPIO_PCF857X) += pcf857x_of.o
+endif
obj-$(CONFIG_GPIO_BT8XX) += bt8xxgpio.o
diff --git a/drivers/gpio/pcf857x.c b/drivers/gpio/pcf857x.c
index 4bc2070..f8057d2 100644
--- a/drivers/gpio/pcf857x.c
+++ b/drivers/gpio/pcf857x.c
@@ -187,7 +187,7 @@ static int pcf857x_probe(struct i2c_client *client,
struct pcf857x *gpio;
int status;
- pdata = client-dev.platform_data;
+ pdata = pcf857x_get_pdata(client);
if (!pdata)
return -ENODEV;
@@ -314,7 +314,7 @@ fail:
static int pcf857x_remove(struct i2c_client *client)
{
- struct pcf857x_platform_data*pdata = client-dev.platform_data;
+ struct pcf857x_platform_data*pdata = pcf857x_get_pdata(client);
struct pcf857x *gpio = i2c_get_clientdata(client);
int status = 0;
@@ -334,6 +334,8 @@ static int pcf857x_remove(struct i2c_client *client)
kfree(gpio);
else
dev_err(client-dev, %s -- %d\n, remove, status);
+
+ pcf857x_put_pdata(client);
return status;
}
diff --git a/drivers/gpio/pcf857x_of.c b/drivers/gpio/pcf857x_of.c
new file mode 100644
index 000..414943b
--- /dev/null
+++ b/drivers/gpio/pcf857x_of.c
@@ -0,0 +1,36 @@
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/i2c/pcf857x.h
+#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
+
+struct pcf857x_platform_data *pcf857x_get_pdata(struct i2c_client *client)
+{
+ struct pcf857x_platform_data *pdata = client-dev.platform_data;
+
+ if (pdata)
+ return pdata;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ /*
+* Do the OF-specific setup here.
+*/
+
+ client-dev.platform_data = pdata;
+}
+
+void pcf857x_put_pdata(struct i2c_client *client)
+{
+ struct pcf857x_platform_data *pdata = client-dev.platform_data;
+
+ /*
+* Do the OF-specific cleanup here.
+*/
+
+ kfree(pdata);
+}
diff --git a/include/linux/i2c/pcf857x.h b/include/linux/i2c/pcf857x.h
index 0767a2a..bdc1aba 100644
--- a/include/linux/i2c/pcf857x.h
+++ b/include/linux/i2c/pcf857x.h
@@ -1,6 +1,8 @@
#ifndef __LINUX_PCF857X_H
#define __LINUX_PCF857X_H
+struct i2c_client;
+
/**
* struct pcf857x_platform_data - data to set up pcf857x
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote: I'm extremely troubled that it is not used in the code, surely device_type is checked as a legacy for Open Firmware (otherwise a lot of devices may never be detected!), Checked where? of_find_device_by_type() goes through it and of_find_compatible_node() - while not directly, checks the type field of the node which is filled in from device_type BEFORE it checks the compatible property. This isn't specific CHRP/FDT platform code it's in the generic tree scanning functions. platforms, the CHRP is running real OF, so it is irrelevant if it checks for device_type = rtc or not.) Except when there is no compatible property because the device is adequately identified by device_type (for instance if you are looking for every serial port on a system, device_type is your only hope without checking for every different KIND of serial port you may ever possibly encounter.. or if you are checking for what kind of console OF attached you to (be it display/keyboard combination or serial or something else). It's a useful property that should be kept around, you never know when it might be needed :D but of course since it's not in ePAPR, no point in shoving it in when compatible describes your board very very accurately anyway (except when you have no need to be very very accurate and are just looking for serial ports... :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote: Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 08:38:03AM -0500, Matt Sealey wrote: I'm extremely troubled that it is not used in the code, surely device_type is checked as a legacy for Open Firmware (otherwise a lot of devices may never be detected!), Checked where? of_find_device_by_type() goes through it and of_find_compatible_node() - while not directly, checks the type field of the node which is filled in from device_type BEFORE it checks the compatible property. Yes, I know this. This isn't specific CHRP/FDT platform code it's in the generic tree scanning functions. I think I got it. ;-) You think that I'm not aware of that we _can_ use the device_type for matching the nodes. Well, I'm aware of it, sure we can. ;-) But we don't use it for the rtc nodes, and we don't want to encourage the usage for the flat trees. And that's the point of this patch. Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote: I think I got it. ;-) You think that I'm not aware of that we _can_ use the device_type for matching the nodes. Well, I'm aware of it, sure we can. ;-) I'm sure you are aware, I am just a little jumpy regarding this as the whole ePAPR-is-official thing and the direction Linux is taking with regards to redefining part of the device tree specs, that this could have been something a little more serious :) But we don't use it for the rtc nodes, and we don't want to encourage the usage for the flat trees. And that's the point of this patch. Would it not be prudent to, while not actively encouraging it, at least mention device_type in any specifications as a legacy item (for real Open Firmware only) and for if a device should be in the tree as a generic, IEEE 1275-style device (i.e. there would be a set of well-defined client interface methods for it in a real OF)? My basic concerns are for input/output as reported by /chosen - in case it is important exactly what is being used, there is at least one out-of-driver code snippet which checks if stdin and stdout are of type serial (or failsafe) and auto-directs console to that - it would be nice to keep this clean and not dump a million serial-device-compatibles in another list here if someone wants to automatically choose between console output on the DIU or PSC for MPC5121e/MPC8610 for example, or wants to restrict the amount of fancy stuff it does on a terminal if it's a slow serial device, or perhaps even automatically invoke netconsole if it's set to network? I know U-Boot doesn't have the intelligence to output to anything but a serial port these days on those devices, but as they say, there is no fate but what we make .. we should make sure it doesn't turn up that code is never suggested or attempted because supporting it in Linux would be too big a jump or too messy a patch :) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
On Wed, Oct 22, 2008 at 02:09:01PM -0500, Matt Sealey wrote: Anton Vorontsov wrote: On Wed, Oct 22, 2008 at 01:40:50PM -0500, Matt Sealey wrote: I think I got it. ;-) You think that I'm not aware of that we _can_ use the device_type for matching the nodes. Well, I'm aware of it, sure we can. ;-) I'm sure you are aware, I am just a little jumpy regarding this as the whole ePAPR-is-official thing and the direction Linux is taking with regards to redefining part of the device tree specs, that this could have been something a little more serious :) But we don't use it for the rtc nodes, and we don't want to encourage the usage for the flat trees. And that's the point of this patch. Would it not be prudent to, while not actively encouraging it, at least mention device_type in any specifications as a legacy item (for real Open Firmware only) and for if a device should be in the tree as a generic, IEEE 1275-style device (i.e. there would be a set of well-defined client interface methods for it in a real OF)? My basic concerns are for input/output as reported by /chosen - in case it is important exactly what is being used, there is at least one out-of-driver code snippet which checks if stdin and stdout are of type serial (or failsafe) and auto-directs console to that - it would be nice to keep this clean and not dump a million serial-device-compatibles in another list here if someone wants to automatically choose between console output on the DIU or PSC for MPC5121e/MPC8610 for example, or wants to restrict the amount of fancy stuff it does on a terminal if it's a slow serial device, or perhaps even automatically invoke netconsole if it's set to network? I know U-Boot doesn't have the intelligence to output to anything but a serial port these days on those devices, but as they say, there is no fate but what we make .. we should make sure it doesn't turn up that code is never suggested or attempted because supporting it in Linux would be too big a jump or too messy a patch :) I don't feel competent to comment on embedded-OF/FDT design decisions... Let's Cc [EMAIL PROTECTED] ? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote: Kumar Gala wrote: On Oct 22, 2008, at 9:19 AM, Matt Sealey wrote: Kumar Gala wrote: On Oct 22, 2008, at 8:42 AM, Matt Sealey wrote: So to confirm, XAEN support through Becky's patches does support the MPC8641D/e600 cores? Yes, its the only part that has XAEN. Okay I saw a lot of e500/BookE support go past but nothing specific :) The XAEN is specific to e600. e500 has its own ability to do 36- bit physical (not called XAEN). You have to forgive me I was only half awake when I started :D Yeah so I saw BookE and e500 stuff go past but nothing specific for e600/XAEN. I mailed Becky and got no response. I'm glad to know it's in there though, somewhere. Huh? I have one mail from you, on Sep 1, to which I responded on Sep 2. Was there another mail I missed, or did you not see my response? Freescale's mail server is unreliable, and since I'm not in the habit of ignoring emails, feel free to nag me anytime if you send me something and don't get a response. Just so it has been asked, do you know in a broad sense what it would take to add the non-contiguous memory mapping support? Doesn't ppc64 already have this? PPC64 has SPARSEMEM support, IIRC. It's non-trivial to add for 32-bit, although I haven't scoped it out in any detail. Cheers, B ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: XICS - fix getting the server number size
On Oct 22, 2008, at 9:36 AM, Sebastien Dugue wrote: The 'ibm,interrupt-server#-size' properties are not cpu nodes properties, but rather live under the interrupt source controller nodes (compatible ibm,ppc-xics). Therefore, this patch moves the detection of this property outside of xics_update_irq_servers() and into xics_init_IRQ(). yes, PAPR says its on one of the interrupt nodes. I am too tired to decipher if it on the presentation or source. Acked-by: Milton Miller [EMAIL PROTECTED] Also this adds a check for mismatched sizes across the interrupt source controller nodes. Not sure this is necessary as in this case the firmware might be seriously busted. I am hoping you have tested this? A POWER6 box? Last time I looked (POWER5 timeframe) firmware was ignoring the parameter to set-indicator(gqirm) which is the only use of this property. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Remove device_type = rtc properties in .dts files
Matt Sealey wrote: Anton Vorontsov wrote: We don't want to encourage the device_type usage. It isn't used in the code, so we can simply remove it from the dts files. I'm extremely troubled that it is not used in the code, surely device_type is checked as a legacy for Open Firmware (otherwise a lot of devices may never be detected!), or does device tree parsing/checking follow a different path for FDT? (absolutely fine with it being removed from new DTS but, just concerned about your comment and it's impact...) device_type is used by Open Firmware itself to specify the binding that a node implements. That includes both properties and methods or words. Since a flat tree doesn't have words to operate, we are activly discouraging flat trees from specifiying device_type with a few exceptions that are well defined -- main memory nodes for one. For most nodes the binding that firmware uses is not relevent to the kernel, and we don't want bindings that only exist in flat trees to result in an unusable OF binding. The i2c binding used by sparc vs flat trees is an example of what can happen without the proper review. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
build break CONFIG_SPU_FS=n CONFIG_CBE_THERM=y
as of 4792adbac9eb41cea77a45ab76258ea10d411173 CONFIG_SPU_FS=n CONFIG_PPC_CELL=y CONFIG_PPC_CELL_NATIVE=y CONFIG_PPC_IBM_CELL_BLADE=y CONFIG_CBE_RAS=y CONFIG_PPC_IBM_CELL_RESETBUTTON=y CONFIG_CBE_THERM=y rest mostly pseries_defconfig. MODPOST vmlinux.o WARNING: modpost: Found 8 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 ld: drivers/built-in.o section .devinit.text exceeds stub group size ld: drivers/built-in.o section .init.text exceeds stub group size ld: arch/powerpc/kernel/built-in.o section .init.text exceeds stub group size ld: init/built-in.o section .init.text exceeds stub group size ld: net/built-in.o section .text exceeds stub group size ld: drivers/built-in.o section .text exceeds stub group size ld: lib/built-in.o section .text exceeds stub group size ld: block/built-in.o section .text exceeds stub group size ld: crypto/built-in.o section .text exceeds stub group size ld: ipc/built-in.o section .text exceeds stub group size ld: fs/built-in.o section .text exceeds stub group size ld: mm/built-in.o section .text exceeds stub group size ld: kernel/built-in.o section .text exceeds stub group size ld: arch/powerpc/platforms/built-in.o section .text exceeds stub group size ld: arch/powerpc/kernel/built-in.o section .text exceeds stub group size ld: arch/powerpc/kernel/head_64.o section .text exceeds stub group size arch/powerpc/platforms/built-in.o: In function `.get_pmd_regs': cbe_thermal.c:(.text+0x107e0): undefined reference to `.spu_devnode' arch/powerpc/platforms/built-in.o: In function `.thermal_init': cbe_thermal.c:(.init.text+0x4120): undefined reference to `.spu_add_sysdev_attr_group' arch/powerpc/platforms/built-in.o: In function `.thermal_exit': cbe_thermal.c:(.exit.text+0x18): undefined reference to `.spu_remove_sysdev_attr_group' arch/powerpc/oprofile/built-in.o: In function `.get_cached_info': spu_task_sync.c:(.text+0x4b6c): undefined reference to `.spu_get_profile_private_kref' arch/powerpc/oprofile/built-in.o: In function `.spu_active_notify': spu_task_sync.c:(.text+0x4ec0): undefined reference to `.spu_set_profile_private_kref' arch/powerpc/oprofile/built-in.o: In function `.spu_sync_start': (.text+0x5470): undefined reference to `.spu_switch_event_register' arch/powerpc/oprofile/built-in.o: In function `.spu_sync_stop': (.text+0x55bc): undefined reference to `.spu_switch_event_unregister' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2 kexec-tools] ppc64: new relocatble kernel activation ABI
The updates kexec-tools to match the kernel after the patches kexec exit should not use magic numbers and better flag for running relocatable are applied. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- Still proposed change Index: kexec-tools/purgatory/arch/ppc64/v2wrap.S === --- kexec-tools.orig/purgatory/arch/ppc64/v2wrap.S 2008-10-22 06:14:44.0 -0500 +++ kexec-tools/purgatory/arch/ppc64/v2wrap.S 2008-10-22 06:14:48.0 -0500 @@ -45,11 +45,13 @@ orisrn,rn,[EMAIL PROTECTED]; \ ori rn,rn,[EMAIL PROTECTED] -#define KDUMP_SIGNATURE 0xfeed1234 - .machine ppc64 .globl purgatory_start purgatory_start: b master + .org purgatory_start + 0x5c # ABI: possible run_at_load flag at 0x5c +run_at_load: + .long 0 + .size run_at_load, . - run_at_load .org purgatory_start + 0x60 # ABI: slaves start at 60 with r3=phys slave: b $ .org purgatory_start + 0x100# ABI: end of copied region @@ -65,7 +67,6 @@ master: isync mr 17,3# save cpu id to r17 mr 15,4# save physical address in reg15 - mr 18,6# save kdump flag in reg18 LOADADDR(6,my_toc) ld 2,0(6) #setup toc @@ -96,14 +97,6 @@ master: mtctr 4 # prepare branch too mr 3,16# restore dt address - LOADADDR(6,KDUMP_SIGNATURE) - cmpd18,6 - bne regular - li 7,1 - std 7,24(4) # mark kdump flag at kernel -regular: - lwz 7,0(4) # get the first instruction that we stole - stw 7,0(0) # and put it in the slave loop at 0 # skip cache flush, do we care? bctr# start kernel Index: kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h === --- kexec-tools.orig/kexec/arch/ppc64/crashdump-ppc64.h 2008-10-22 06:14:44.0 -0500 +++ kexec-tools/kexec/arch/ppc64/crashdump-ppc64.h 2008-10-22 06:14:48.0 -0500 @@ -23,6 +23,8 @@ void add_usable_mem_rgns(unsigned long l #define _ALIGN_UP(addr,size) (((addr)+((size)-1))(~((size)-1))) #define _ALIGN_DOWN(addr,size) ((addr)(~((size)-1))) +#define KERNEL_RUN_AT_ZERO_MAGIC 0x72756e30/* run0 */ + extern uint64_t crash_base; extern uint64_t crash_size; extern unsigned int rtas_base; Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c === --- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c 2008-10-22 06:14:44.0 -0500 +++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c 2008-10-22 06:14:48.0 -0500 @@ -93,6 +93,7 @@ int elf_ppc64_load(int argc, char **argv uint64_t my_stack, my_backup_start; uint64_t toc_addr; unsigned int slave_code[256/sizeof (unsigned int)], master_entry; + unsigned int run_at_load; #define OPT_APPEND (OPT_ARCH_MAX+0) #define OPT_RAMDISK (OPT_ARCH_MAX+1) @@ -307,6 +308,18 @@ int elf_ppc64_load(int argc, char **argv my_backup_start = info-backup_start; elf_rel_set_symbol(info-rhdr, backup_start, my_backup_start, sizeof(my_backup_start)); + + /* Tell relocatable kernel to run at load address +* via word before slave code in purgatory +*/ + + elf_rel_get_symbol(info-rhdr, run_at_load, run_at_load, + sizeof(run_at_load)); + if (run_at_load == KERNEL_RUN_AT_ZERO_MAGIC) + run_at_load = 1; + /* else it should be a fixed offset image */ + elf_rel_set_symbol(info-rhdr, run_at_load, run_at_load, + sizeof(run_at_load)); } /* Set stack address */ @@ -325,10 +338,13 @@ int elf_ppc64_load(int argc, char **argv my_backup_start = 0; my_stack = 0; toc_addr = 0; + run_at_load = 0; elf_rel_get_symbol(info-rhdr, kernel, my_kernel, sizeof(my_kernel)); elf_rel_get_symbol(info-rhdr, dt_offset, my_dt_offset, sizeof(my_dt_offset)); + elf_rel_get_symbol(info-rhdr, run_at_load, run_at_load, + sizeof(run_at_load)); elf_rel_get_symbol(info-rhdr, panic_kernel, my_panic_kernel, sizeof(my_panic_kernel)); elf_rel_get_symbol(info-rhdr, backup_start, my_backup_start, @@ -341,6 +357,7 @@ int elf_ppc64_load(int argc, char **argv fprintf(stderr, kernel is %llx\n, (unsigned long long)my_kernel); fprintf(stderr, dt_offset is %llx\n, (unsigned long long)my_dt_offset); +
[PATCH 2/2 kexec-tools] ppc64: segemments are sorted
Every time add_segment is called, the segments are sorted. If the first
hole in memory is not big enough for the kernel then something besides
the kernel may be at
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
Found during custom environment testing with several reserved blocks of
memory, not the usual case.
Index: kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c
===
--- kexec-tools.orig/kexec/arch/ppc64/kexec-elf-ppc64.c 2008-10-22
06:14:48.0 -0500
+++ kexec-tools/kexec/arch/ppc64/kexec-elf-ppc64.c 2008-10-22
06:14:54.0 -0500
@@ -86,7 +86,7 @@ int elf_ppc64_load(int argc, char **argv
size_t size;
uint64_t *rsvmap_ptr;
struct bootblock *bb_ptr;
- unsigned int nr_segments, i;
+ unsigned int i;
int result, opt;
uint64_t my_kernel, my_dt_offset;
unsigned int my_panic_kernel;
@@ -187,7 +187,7 @@ int elf_ppc64_load(int argc, char **argv
if (size phdr-p_memsz)
size = phdr-p_memsz;
- hole_addr = (uint64_t)locate_hole(info, size, 0, 0,
+ my_kernel = hole_addr = (uint64_t)locate_hole(info, size, 0, 0,
max_addr, 1);
ehdr.e_phdr[0].p_paddr = hole_addr;
result = elf_exec_load(ehdr, info);
@@ -233,12 +233,10 @@ int elf_ppc64_load(int argc, char **argv
return -1;
}
seg_buf = (unsigned char *)slurp_file(ramdisk, seg_size);
- add_buffer(info, seg_buf, seg_size, seg_size, 0, 0, max_addr,
1);
- hole_addr = (uintptr_t)
- info-segment[info-nr_segments-1].mem;
+ hole_addr = add_buffer(info, seg_buf, seg_size, seg_size,
+ 0, 0, max_addr, 1);
initrd_base = hole_addr;
- initrd_size = (uint64_t)
- info-segment[info-nr_segments-1].memsz;
+ initrd_size = seg_size;
} /* ramdisk */
if (devicetreeblob) {
@@ -248,16 +246,18 @@ int elf_ppc64_load(int argc, char **argv
/* Grab device tree from buffer */
blob_buf =
(unsigned char *)slurp_file(devicetreeblob, blob_size);
- add_buffer(info, blob_buf, blob_size, blob_size, 0, 0,
- max_addr, -1);
+ my_dt_offset = add_buffer(info, blob_buf, blob_size, blob_size,
+ 0, 0, max_addr, -1);
+ seg_buf = blob_buf;
+ seg_size = blob_size;
} else {
/* create from fs2dt */
seg_buf = NULL;
seg_size = 0;
create_flatten_tree(info, (unsigned char **)seg_buf,
(unsigned long *)seg_size,cmdline);
- add_buffer(info, seg_buf, seg_size, seg_size,
+ my_dt_offset = add_buffer(info, seg_buf, seg_size, seg_size,
0, 0, max_addr, -1);
}
@@ -265,27 +265,20 @@ int elf_ppc64_load(int argc, char **argv
* find last entry (both 0) in the reserve mem list. Assume DT
* entry is before this one
*/
- bb_ptr = (struct bootblock *)(
- (unsigned char *)info-segment[(info-nr_segments)-1].buf);
- rsvmap_ptr = (uint64_t *)(
- (unsigned char *)info-segment[(info-nr_segments)-1].buf +
- bb_ptr-off_mem_rsvmap);
+ bb_ptr = (struct bootblock *)(seg_buf);
+ rsvmap_ptr = (uint64_t *)
+ (((char *)seg_buf) + bb_ptr-off_mem_rsvmap);
while (*rsvmap_ptr || *(rsvmap_ptr+1))
rsvmap_ptr += 2;
rsvmap_ptr -= 2;
- *rsvmap_ptr = (uintptr_t)(
- info-segment[(info-nr_segments)-1].mem);
+ *rsvmap_ptr = my_dt_offset;
rsvmap_ptr++;
*rsvmap_ptr = (uint64_t)bb_ptr-totalsize;
- nr_segments = info-nr_segments;
-
/* Set kernel */
- my_kernel = (uintptr_t)info-segment[0].mem;
elf_rel_set_symbol(info-rhdr, kernel, my_kernel,
sizeof(my_kernel));
/* Set dt_offset */
- my_dt_offset = (uintptr_t)info-segment[nr_segments-1].mem;
elf_rel_set_symbol(info-rhdr, dt_offset, my_dt_offset,
sizeof(my_dt_offset));
@@ -293,7 +286,7 @@ int elf_ppc64_load(int argc, char **argv
elf_rel_get_symbol(info-rhdr, purgatory_start, slave_code,
sizeof(slave_code));
master_entry = slave_code[0];
- memcpy(slave_code, info-segment[0].buf, sizeof(slave_code));
+ memcpy(slave_code, phdr-p_data, sizeof(slave_code));
slave_code[0] = master_entry;
elf_rel_set_symbol(info-rhdr, purgatory_start, slave_code,
sizeof(slave_code));
@@ -366,7 +359,7 @@ int elf_ppc64_load(int argc, char **argv
fprintf(stderr, purgatory size is %zu\n,
[PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
The __kdump_flag ABI is overly constraining for future development. As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is the starting point for the master (boot) cpu (entered with r3 pointing to the device tree structure), offset 0x60 is code for the slave cpus (entered with r3 set to their device tree physical id), offset 0x20 is used by the iseries hypervisor, and secondary cpus must be well behaved when the first 256 bytes are copied to address 0. Placing the __kdump_flag at 0x18 is bad because: - It was taking the last 8 bytes before the iseries hypervisor data. - It was 8 bytes for a boolean flag - It had no way of identifying that the flag was present - It does leave any room for the master to add any additional code before branching, which hurts debug. - It will be unnecessarily hard for 32 bit code to be common (8 bytes) Now that we have eliminated the use of __kdump_flag in favor of the standard is_kdump_kernel(), this flag only controls run without relocating the kernel to PHYSICAL_START (0), so rename it __run_at_load. Move the flag to 0x5c, 1 word before the secondary cpu entry point at 0x60. Use the copy at address 0 not the one in the base kernel image to make it easier on kexec-tools. Initialize it with run0 to say it will run at 0 unless it is set to 1. It only exists if we are relocatable. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- I left it global so it appears that way in System.map, but it would not need to be. I kept the guards with CONFIG_CRASH_DUMP for now. They could be relaxed to just CONFIG_RELOCATABLE. Tested with normal kexec (kernel moved to 0) and a custom boot-loader (kernel stayed at loaded 16MB start). Index: next.git/arch/powerpc/kernel/head_64.S === --- next.git.orig/arch/powerpc/kernel/head_64.S 2008-10-22 04:30:08.0 -0500 +++ next.git/arch/powerpc/kernel/head_64.S 2008-10-22 04:59:55.0 -0500 @@ -97,12 +97,6 @@ __secondary_hold_spinloop: __secondary_hold_acknowledge: .llong 0x0 - /* This flag is set by purgatory if we should be a kdump kernel. */ - /* Do not move this variable as purgatory knows about it. */ - .globl __kdump_flag -__kdump_flag: - .llong 0x0 - #ifdef CONFIG_PPC_ISERIES /* * At offset 0x20, there is a pointer to iSeries LPAR data. @@ -112,6 +106,20 @@ __kdump_flag: .llong hvReleaseData-KERNELBASE #endif /* CONFIG_PPC_ISERIES */ +#ifdef CONFIG_CRASH_DUMP + /* This flag is set to 1 by a loader if the kernel should run +* at the loaded address instead of the linked address. This +* is used by kexec-tools to keep the the kdump kernel in the +* crash_kernel region. The loader is responsible for +* observing the alignment requirement. +*/ + /* Do not move this variable as kexec-tools knows about it. */ + . = 0x5c + .globl __run_at_load +__run_at_load: + .long 0x72756e30 /* run0 -- relocate to 0 by default */ +#endif + . = 0x60 /* * The following code is used to hold secondary processors @@ -1391,8 +1399,8 @@ _STATIC(__after_prom_start) lis r25,[EMAIL PROTECTED] /* compute virtual base of kernel */ sldir25,r25,32 #ifdef CONFIG_CRASH_DUMP - ld r7,__kdump_flag-_stext(r26) - cmpldi cr0,r7,1/* kdump kernel ? - stay where we are */ + lwz r7,__run_at_load-_stext(0) + cmplwi cr0,r7,1/* kdump kernel ? - stay where we are */ bne 1f add r25,r25,r26 #endif @@ -1416,11 +1424,11 @@ _STATIC(__after_prom_start) #ifdef CONFIG_CRASH_DUMP /* * Check if the kernel has to be running as relocatable kernel based on the - * variable __kdump_flag, if it is set the kernel is treated as relocatable + * variable __run_at_load, if it is set the kernel is treated as relocatable * kernel, otherwise it will be moved to PHYSICAL_START */ - ld r7,__kdump_flag-_stext(r26) - cmpldi cr0,r7,1 + lwz r7,__run_at_load-_stext(0) + cmplwi cr0,r7,1 bne 3f li r5,__end_interrupts - _stext/* just copy interrupts */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: kexec exit should not use magic numbers
The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246)
added a magic flag value in a register to tell purgatory that it should
be a panic kernel. This part is wrong and is reverted by this patch.
The kernel gets a list of memory blocks and a entry point from user space.
Its job is to copy the blocks into place and then branch to the designated
entry point (after turning off the mmu).
The user space tool inserts a trampoline, called purgatory, that runs
before the user supplied code. Its job is to establish the entry
environment for the new kernel or other application based on the contents
of memory. The purgatory code is compiled and embedded in the tool,
where it is later patched using the elf symbol table using elf symbols.
Since the tool knows it is creating a purgatory that will run after a
kernel crash, it should just patch purgatory (or the kernel directly)
if something needs to happen.
Signed-off-by: Milton Miller [EMAIL PROTECTED]
---
keep the whitespace fix at if(crashing_cpu == -1)
Index: next.git/arch/powerpc/include/asm/kdump.h
===
--- next.git.orig/arch/powerpc/include/asm/kdump.h 2008-10-22
06:53:22.0 -0500
+++ next.git/arch/powerpc/include/asm/kdump.h 2008-10-22 06:54:12.0
-0500
@@ -9,12 +9,6 @@
* Reserve to the end of the FWNMI area, see head_64.S */
#define KDUMP_RESERVE_LIMIT0x1 /* 64K */
-/*
- * Used to differentiate between relocatable kdump kernel and other
- * kernels
- */
-#define KDUMP_SIGNATURE0xfeed1234
-
#ifdef CONFIG_CRASH_DUMP
#define KDUMP_TRAMPOLINE_START 0x0100
Index: next.git/arch/powerpc/kernel/machine_kexec_64.c
===
--- next.git.orig/arch/powerpc/kernel/machine_kexec_64.c2008-10-22
06:53:22.0 -0500
+++ next.git/arch/powerpc/kernel/machine_kexec_64.c 2008-10-22
06:54:12.0 -0500
@@ -255,14 +255,11 @@ static union thread_union kexec_stack
/* Our assembly helper, in kexec_stub.S */
extern NORET_TYPE void kexec_sequence(void *newstack, unsigned long start,
void *image, void *control,
- void (*clear_all)(void),
- unsigned long kdump_flag) ATTRIB_NORET;
+ void (*clear_all)(void)) ATTRIB_NORET;
/* too late to fail here */
void default_machine_kexec(struct kimage *image)
{
- unsigned long kdump_flag = 0;
-
/* prepare control code if any */
/*
@@ -275,8 +272,6 @@ void default_machine_kexec(struct kimage
if (crashing_cpu == -1)
kexec_prepare_cpus();
- else
- kdump_flag = KDUMP_SIGNATURE;
/* switch to a staticly allocated stack. Based on irq stack code.
* XXX: the task struct will likely be invalid once we do the copy!
@@ -289,7 +284,7 @@ void default_machine_kexec(struct kimage
*/
kexec_sequence(kexec_stack, image-start, image,
page_address(image-control_code_page),
- ppc_md.hpte_clear_all, kdump_flag);
+ ppc_md.hpte_clear_all);
/* NOTREACHED */
}
Index: next.git/arch/powerpc/kernel/misc_64.S
===
--- next.git.orig/arch/powerpc/kernel/misc_64.S 2008-10-22 06:53:22.0
-0500
+++ next.git/arch/powerpc/kernel/misc_64.S 2008-10-22 06:54:12.0
-0500
@@ -611,12 +611,10 @@ real_mode:/* assume normal blr return *
/*
- * kexec_sequence(newstack, start, image, control, clear_all(), kdump_flag)
+ * kexec_sequence(newstack, start, image, control, clear_all())
*
* does the grungy work with stack switching and real mode switches
* also does simple calls to other code
- *
- * kdump_flag says whether the next kernel should be a kdump kernel.
*/
_GLOBAL(kexec_sequence)
@@ -649,7 +647,7 @@ _GLOBAL(kexec_sequence)
mr r29,r5 /* image (virt) */
mr r28,r6 /* control, unused */
mr r27,r7 /* clear_all() fn desc */
- mr r26,r8 /* kdump flag */
+ mr r26,r8 /* spare */
lhz r25,PACAHWCPUID(r13)/* get our phys cpu from paca */
/* disable interrupts, we are overwriting kernel data next */
@@ -711,6 +709,5 @@ _GLOBAL(kexec_sequence)
mr r4,r30 # start, aka phys mem offset
mtlr4
li r5,0
- mr r6,r26 /* kdump_flag */
- blr /* image-start(physid, image-start, 0, kdump_flag); */
+ blr /* image-start(physid, image-start, 0); */
#endif /* CONFIG_KEXEC */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Re: [PATCH 2/2 kexec-tools] ppc64: segemments are sorted
On Oct 22, 2008, at 3:39 PM, Milton Miller wrote: Every time add_segment is called, the segments are sorted. If the first hole in memory is not big enough for the kernel then something besides the kernel may be at info-segment[0]. --- Found during custom environment testing with several reserved blocks of memory, not the usual case. milton ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wednesday 22 October 2008, Anton Vorontsov wrote: The board info has another problem though. We can't remove it, thus we can't implement module_exit() for the 'OF glue'. That's not a problem. Why would you want to remove it? And try to solve this problem... maybe then things will begin to move forward. There is another problem: board infos are scanned at the controller registration time only. Right. Such board description data should be made available early in boot. As a rule: before arch_initcall() finishes, so that subsys_initcall() code can use the associated GPIOs. (It's fairly well acknowledged that init dependency handling has a lot of problems. Until that's fixed ... for GPIOs, the general advice is to make sure everything is available by subsys_initcall time, so the subsystems which rely on GPIOs to initialize -- power switches, resets, etc -- can initialize. That can require i2c adapter drivers to use subsys_initcall, for example.) So if we register the board infos after the controller registered, then nobody will probe the board infos. See above. If you're doing it right, there's no problem. That is, scan the OF tables early. Just like PNP tables get scanned early, for example. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 02:04:52PM -0700, David Brownell wrote: On Wednesday 22 October 2008, Anton Vorontsov wrote: The board info has another problem though. We can't remove it, thus we can't implement module_exit() for the 'OF glue'. That's not a problem. Why would you want to remove it? And try to solve this problem... maybe then things will begin to move forward. There is another problem: board infos are scanned at the controller registration time only. Right. Such board description data should be made available early in boot. As a rule: before arch_initcall() finishes, so that subsys_initcall() code can use the associated GPIOs. (It's fairly well acknowledged that init dependency handling has a lot of problems. Until that's fixed ... for GPIOs, the general advice is to make sure everything is available by subsys_initcall time, so the subsystems which rely on GPIOs to initialize -- power switches, resets, etc -- can initialize. That can require i2c adapter drivers to use subsys_initcall, for example.) So if we register the board infos after the controller registered, then nobody will probe the board infos. See above. If you're doing it right, there's no problem. That is, scan the OF tables early. Just like PNP tables get scanned early, for example. Heh. If we don't want to be able to make the OF-parsing code be a module then there is no problem at all. I can use the bus notifiers. And it is most straightforward solution then. But I quite dislike to bloat the kernel image with maybe-never-used-on-this-board code. My aim was to make the OF-parsing part be a module too. Because in the long run we need the OF-parsing stuff for _every_ driver that needs platform data. It's quite expensive to have it always built-in, don't you think? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wednesday 22 October 2008, Anton Vorontsov wrote: So if we register the board infos after the controller registered, then nobody will probe the board infos. See above. If you're doing it right, there's no problem. That is, scan the OF tables early. Just like PNP tables get scanned early, for example. Heh. If we don't want to be able to make the OF-parsing code be a module then there is no problem at all. I can use the bus notifiers. And it is most straightforward solution then. But I quite dislike to bloat the kernel image with maybe-never-used-on-this-board code. So have it live in the __init text section. If you're building a kernel with support for several boards, you know it's necessarily going to be larger than it would be if only one board were supported. But you can shrink kernel size by judicious use of __init sections.. My aim was to make the OF-parsing part be a module too. Because in the long run we need the OF-parsing stuff for _every_ driver that needs platform data. It's quite expensive to have it always built-in, don't you think? If it's discarded early, after translating the data from OF format into what the drivers need, there will be no RAM footprint. - Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote: We are developing a board based on Freescale 8641D which can get 4GB of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. Why would you put the IOs below the 4G point ? It's actually easier to have the IOs up above, like a lot of 4xx do. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Becky Bruce wrote: On Oct 22, 2008, at 1:11 PM, Matt Sealey wrote: Yeah so I saw BookE and e500 stuff go past but nothing specific for e600/XAEN. I mailed Becky and got no response. I'm glad to know it's in there though, somewhere. Huh? I have one mail from you, on Sep 1, to which I responded on Sep 2. Was there another mail I missed, or did you not see my response? Freescale's mail server is unreliable, and since I'm not in the habit of ignoring emails, feel free to nag me anytime if you send me something and don't get a response. Between Freescale's mail server and the trouble we're having with Google right now (along with thousands of others), I am NOT surprised it got lost somewhere along the way. I wasn't bitching :) Just so it has been asked, do you know in a broad sense what it would take to add the non-contiguous memory mapping support? Doesn't ppc64 already have this? PPC64 has SPARSEMEM support, IIRC. It's non-trivial to add for 32-bit, although I haven't scoped it out in any detail. Okay, non-trivial was pretty much what I was looking for, I was just trying to weigh up how much effort is required.. If you actually scope it out in any detail or someone has some 10% time and decides this would be an awesome project, give me a nudge? My MPC8641D is itching to actually do something besides build packages. Actually having 8GB of memory would REALLY help run SUSE Build Service :] -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
Benjamin Herrenschmidt wrote: On Wed, 2008-10-22 at 08:08 -0500, Kumar Gala wrote: We are developing a board based on Freescale 8641D which can get 4GB of ram. So I need 4GB+IOs (~1GB) of physical addressing space. My plan is to put a part of this ram above of 4GB to keep accesses to the IOs below the 4GB limit. It means non-contiguous ram addressing and XAEN features to be working. Why would you put the IOs below the 4G point ? It's actually easier to have the IOs up above, like a lot of 4xx do. Because we're Genesi! And we have a firmware solution that kind of has to keep 32-bit pointers in the unlikely event that someone actually uses the client interface (besides yaboot!). Having I/O in the 36-bit range could cause all sorts of explosions, and we're running real-mode so trapping and faking I/O accesses is REALLy difficult :} -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, Oct 22, 2008 at 02:52:46PM -0700, David Brownell wrote: On Wednesday 22 October 2008, Anton Vorontsov wrote: So if we register the board infos after the controller registered, then nobody will probe the board infos. See above. If you're doing it right, there's no problem. That is, scan the OF tables early. Just like PNP tables get scanned early, for example. Heh. If we don't want to be able to make the OF-parsing code be a module then there is no problem at all. I can use the bus notifiers. And it is most straightforward solution then. But I quite dislike to bloat the kernel image with maybe-never-used-on-this-board code. So have it live in the __init text section. If you're building a kernel with support for several boards, you know it's necessarily going to be larger than it would be if only one board were supported. But you can shrink kernel size by judicious use of __init sections.. Won't work, unfortunately. I2C devices are created by the i2c controllers, via drivers/of_i2c.c of_register_i2c_devices(). There is a good reason to do so, the code needs to know controller's OF node to walk down and register the child nodes (devices). See drivers/i2c/busses/i2c-mpc.c -- it calls of_register_i2c_devices() at the end of the probe(). Since we can't call __init stuff from non-__init, the scheme you purpose won't work. The same is for SPI (drivers/of_spi.c of_register_spi_devices()). My aim was to make the OF-parsing part be a module too. Because in the long run we need the OF-parsing stuff for _every_ driver that needs platform data. It's quite expensive to have it always built-in, don't you think? If it's discarded early, after translating the data from OF format into what the drivers need, there will be no RAM footprint. There is also kernel image size that matters... -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Extended Addressing Mode
On Wed, 2008-10-22 at 17:21 -0500, Matt Sealey wrote: Because we're Genesi! And we have a firmware solution that kind of has to keep 32-bit pointers in the unlikely event that someone actually uses the client interface (besides yaboot!). Having I/O in the 36-bit range could cause all sorts of explosions, and we're running real-mode so trapping and faking I/O accesses is REALLy difficult :} how so ? we have plethora of 32-bit firmwares including OF implementations that can perfectly address 36 bit physical address space. Nothing to do with having 32-bit pointers. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build failure on powerpc with current -git
(Oops, resending in plain text...) On Tue, Oct 21, 2008 at 10:58 PM, Paul Mackerras [EMAIL PROTECTED] wrote: Stephen Rothwell writes: On Tue, 21 Oct 2008 16:33:10 +1100 Paul Mackerras [EMAIL PROTECTED] wrote: It's a bug in older versions of ld (including 2.16.1) that's fixed in the current version (2.18). However, this patch appears to work around the problem - at least, it let me build a 32-bit kernel with a cross-toolchain including a 2.16.1 ld. Let me know if this gets it working for you. With that patch applied I got these errors for a powerpc ppc64_defconfig build (linux-next). /usr/bin/objcopy: Warning: '/dev/null' is not an ordinary file Hmmm, so do I, and in fact the arch/powerpc/boot/wrapper change now seems to be unnecessary with my cross-compile setup (which has ld 2.16.1), whereas yesterday I'm sure it got errors. Weird. Chris, could you try just the following change (my previous patch without the arch/powerpc/boot/wrapper change) and let me know if it fixes things with the ld you use? Works for me. binutils 2.16.1 is the most recent binutils that will build with crosstool, so IMHO it's worth supporting. :) -Hollis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: Fix problem with max number of QPs and CQs in systems with different adapters
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH]IB/ehca:reject dynamic memory add/remove
thanks, applied with a slightly expanded changelog. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: kexec exit should not use magic numbers
[ Added Mohan Kumar to CC list ] On Wed, Oct 22, 2008 at 03:39:18PM -0500, Milton Miller wrote: The relocatable kernel kdump patch (54622f10a6aabb8bb2bdacf3dd070046f03dc246) added a magic flag value in a register to tell purgatory that it should be a panic kernel. This part is wrong and is reverted by this patch. The kernel gets a list of memory blocks and a entry point from user space. Its job is to copy the blocks into place and then branch to the designated entry point (after turning off the mmu). The user space tool inserts a trampoline, called purgatory, that runs before the user supplied code. Its job is to establish the entry environment for the new kernel or other application based on the contents of memory. The purgatory code is compiled and embedded in the tool, where it is later patched using the elf symbol table using elf symbols. Since the tool knows it is creating a purgatory that will run after a kernel crash, it should just patch purgatory (or the kernel directly) if something needs to happen. Hi Milton, All of these patches look fine to me. On the kernel side: Acked-by: Simon Horman [EMAIL PROTECTED] On the kexec-tools side: I'd rather wait until the kernel changes get merged before merging the kexec-tools portion. Please ping me at that point. I'd like to note that these changes really ought to go into the same kernel (and kexec-tools) release that the relocateable kdump patches as they will introduce incompatibility. For example, crash-dump kernels with only the relocatable kdump changes will not be usable if the first-kernel includes these changes. I think that means that this needs to go into 2.6.28 - assuming that Linus accepts the pull request than Ben Herrenschmidt sent recently. -- Simon Horman VA Linux Systems Japan K.K., Sydney, Australia Satellite Office H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ppc64_defconfig build warnings
Hi all, Things are getting better. Here are the messages from a ppc64_defconfig build this morning (Linus' tree plus a merge of DaveM's pending network tree): kernel/trace/ring_buffer.c: In function 'rb_add_time_stamp': kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'u64' kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'u64' kernel/trace/ring_buffer.c:969: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'u64' kernel/cgroup.c: In function 'cgroup_tasks_start': kernel/cgroup.c:2107: warning: unused variable 'i' (The above one already has a fix patch pending) drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_reset_device': drivers/scsi/ibmvscsi/ibmvfc.c:1630: warning: 'evt' may be used uninitialized in this function fs/xfs/xfs_bmap_btree.c: In function 'xfs_bmbt_insrec': fs/xfs/xfs_bmap_btree.c:702: warning: 'nrec.l0' may be used uninitialized in this function drivers/scsi/scsi_transport_iscsi.c: In function 'iscsi_add_session': drivers/scsi/scsi_transport_iscsi.c:704: warning: 'err' may be used uninitialized in this function WARNING: modpost: Found 12 section mismatch(es). -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpbnaSu4tqdg.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: build failure on powerpc with current -git
On Wed, Oct 22, 2008 at 11:50:25AM -0600, Chris Friesen wrote: Hollis Blanchard wrote: binutils 2.16.1 is the most recent binutils that will build with crosstool, so IMHO it's worth supporting. :) I was wondering about thatwasted a bunch of time trying to build something more recent. I built binutils 2.18 for ppc, ppc no-float, ppc64, mips, and i386 yesterday. It worked fine... josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: hugetlbfs for ppc440 - kernel BUG
On Tue, Oct 21, 2008 at 03:50:30PM -0700, Satya wrote: On Tue, Oct 21, 2008 at 3:46 PM, Satya [EMAIL PROTECTED] wrote: Ben, Look here: http://www-unix.mcs.anl.gov/zeptoos/hugepages/ thanks, ./satya On Tue, Oct 21, 2008 at 1:47 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2007-07-10 at 13:38 -0500, Satya wrote: hello, I am trying to implement hugetlbfs on the IBM Bluegene/L IO node (ppc440) and I have a big problem as well as a few questions to ask the group. I patched a 2.6.21.6 linux kernel (manually) with Edi Shmueli's hugetlbfs implementation (found here: http://patchwork.ozlabs.org/linuxppc/patch?id=8427) for this. I did have to make slight changes (described at the end) to make it work. My test program is a shortened version of a sys v shared memory example described in Documentation/vm/hugetlbpage.txt Hi ! The patchwork link unfortunately didn't survive the transition to patchwork 2. Do you know what's the status of Hugetlb support for 44x ? Is there any plan to release that for upstream inclusion ? Cheers, Ben. whoops, sorry for top-posting. Here is a patch that worked at that time: http://www-unix.mcs.anl.gov/zeptoos/hugepages/hugetlbpage_44x.patch I didn't follow up after this to get it merged upstream. Also I don't know if hugetlb core has changed to deal with PTEs in high memory. Ok, had a look at this. It's had some tweaks since I last looked at the bluegene hugepage/440 patch. It still has the rather ugly approach of storing the hugepage PTEs always at the bottom level, and duplicating them umpteen times (including pointing multiple PMDs at a single PTE page when the hugepage size exceeds the area mapped by a PMD). It also has the most serious bug I remember from the old version - the DIRTY and ACCESSED handling is completely bogus, because it doesn't keep the copies of the bits in the many copies of the PTEs in sync. Between the TLB miss rewrite that's happened in the meantime and my patch to handle these from hugetlb_fault() it's at least now easier to fix this bug. Also the patch is arch/ppc based. I'll try to sort this out in the near future. I guess the only big question is whether its important to support hugepage sizes 2M. For hugepage sizes =2M (16M and 256M) we can just make PMD pointers into hugepage pointers with the addition of a suitable size field, as we do for 40x. For page sizes 2M things get more complicated because we need some sort of second level hugepage tables (which may or may not be distinct from the ordinary second level tables). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
In message [EMAIL PROTECTED] you wrote: The __kdump_flag ABI is overly constraining for future development. As of 2.6.27, the kernel entry point has 4 constraints: Offset 0 is the starting point for the master (boot) cpu (entered with r3 pointing to the device tree structure), offset 0x60 is code for the slave cpus (entered with r3 set to their device tree physical id), offset 0x20 is used by the iseries hypervisor, and secondary cpus must be well behaved when the first 256 bytes are copied to address 0. Placing the __kdump_flag at 0x18 is bad because: - It was taking the last 8 bytes before the iseries hypervisor data. - It was 8 bytes for a boolean flag - It had no way of identifying that the flag was present - It does leave any room for the master to add any additional code before branching, which hurts debug. - It will be unnecessarily hard for 32 bit code to be common (8 bytes) Now that we have eliminated the use of __kdump_flag in favor of the standard is_kdump_kernel(), this flag only controls run without relocating the kernel to PHYSICAL_START (0), so rename it __run_at_load. Move the flag to 0x5c, 1 word before the secondary cpu entry point at 0x60. Use the copy at address 0 not the one in the base kernel image to make it easier on kexec-tools. Initialize it with run0 to say it will run at 0 unless it is set to 1. It only exists if we are relocatable. Signed-off-by: Milton Miller [EMAIL PROTECTED] --- I left it global so it appears that way in System.map, but it would not need to be. I kept the guards with CONFIG_CRASH_DUMP for now. They could be relaxed to just CONFIG_RELOCATABLE. Tested with normal kexec (kernel moved to 0) and a custom boot-loader (kernel stayed at loaded 16MB start). Index: next.git/arch/powerpc/kernel/head_64.S === --- next.git.orig/arch/powerpc/kernel/head_64.S 2008-10-22 04:30:08.000 00 -0500 +++ next.git/arch/powerpc/kernel/head_64.S2008-10-22 04:59:55.0 - 0500 @@ -97,12 +97,6 @@ __secondary_hold_spinloop: __secondary_hold_acknowledge: .llong 0x0 - /* This flag is set by purgatory if we should be a kdump kernel. */ - /* Do not move this variable as purgatory knows about it. */ - .globl __kdump_flag -__kdump_flag: - .llong 0x0 - #ifdef CONFIG_PPC_ISERIES /* * At offset 0x20, there is a pointer to iSeries LPAR data. @@ -112,6 +106,20 @@ __kdump_flag: .llong hvReleaseData-KERNELBASE #endif /* CONFIG_PPC_ISERIES */ +#ifdef CONFIG_CRASH_DUMP + /* This flag is set to 1 by a loader if the kernel should run + * at the loaded address instead of the linked address. This + * is used by kexec-tools to keep the the kdump kernel in the + * crash_kernel region. The loader is responsible for + * observing the alignment requirement. + */ + /* Do not move this variable as kexec-tools knows about it. */ + . = 0x5c + .globl __run_at_load +__run_at_load: + .long 0x72756e30 /* run0 -- relocate to 0 by default */ +#endif + . = 0x60 /* * The following code is used to hold secondary processors @@ -1391,8 +1399,8 @@ _STATIC(__after_prom_start) lis r25,[EMAIL PROTECTED] /* compute virtual base of kernel */ sldir25,r25,32 #ifdef CONFIG_CRASH_DUMP - ld r7,__kdump_flag-_stext(r26) - cmpldi cr0,r7,1/* kdump kernel ? - stay where we are */ + lwz r7,__run_at_load-_stext(0) + cmplwi cr0,r7,1/* kdump kernel ? - stay where we are */ Do we really want the flag to always be at 0x5c not 0x5c + kernel offset? Also, comment kdump kernel needs to be updated to reflect the new name. Other than that, the patch series works for me. Mikey bne 1f add r25,r25,r26 #endif @@ -1416,11 +1424,11 @@ _STATIC(__after_prom_start) #ifdef CONFIG_CRASH_DUMP /* * Check if the kernel has to be running as relocatable kernel based on the - * variable __kdump_flag, if it is set the kernel is treated as relocatable + * variable __run_at_load, if it is set the kernel is treated as relocatable * kernel, otherwise it will be moved to PHYSICAL_START */ - ld r7,__kdump_flag-_stext(r26) - cmpldi cr0,r7,1 + lwz r7,__run_at_load-_stext(0) + cmplwi cr0,r7,1 bne 3f li r5,__end_interrupts - _stext/* just copy interrupts */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Milton Miller writes: Move the flag to 0x5c, 1 word before the secondary cpu entry point at 0x60. Use the copy at address 0 not the one in the base kernel image to make it easier on kexec-tools. Why is it easier on kexec-tools? Doesn't kexec-tools know where it put the kernel? I'd much rather keep the flag inside the kdump kernel image, rather than having kexec/kdump start using random fixed locations outside the new kernel image. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: print physical_start for the relocatable kernel
Print physical start address for the relocatable kernel. Also fixes this warning: arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defined Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- arch/powerpc/kernel/setup_64.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) This is on top of Milton's patches kexec patches from here: http://patchwork.ozlabs.org/patch/5382/ Index: linux-2.6-ozlabs/arch/powerpc/kernel/setup_64.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/setup_64.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/setup_64.c @@ -444,9 +444,9 @@ void __init setup_system(void) if (htab_address) printk(htab_address = 0x%p\n, htab_address); printk(htab_hash_mask= 0x%lx\n, htab_hash_mask); -#if PHYSICAL_START 0 - printk(physical_start= 0x%lx\n, PHYSICAL_START); -#endif + if(PHYSICAL_START 0) + printk(physical_start= 0x%lx\n, + PHYSICAL_START); printk(-\n); DBG( - setup_system()\n); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable
Paul Mackerras writes: Milton Miller writes: Move the flag to 0x5c, 1 word before the secondary cpu entry point at 0x60. Use the copy at address 0 not the one in the base kernel image to make it easier on kexec-tools. Why is it easier on kexec-tools? Doesn't kexec-tools know where it put the kernel? I'd much rather keep the flag inside the kdump kernel image, rather than having kexec/kdump start using random fixed locations outside the new kernel image. In fact the cliching argument is that when the kernel is loaded by OF or yaboot, we have no way to tell what will be at location 0x5c, whereas we know that the word at offset 0x5c in the kernel image will have been initialized to 0. So we had better put the flag inside the kernel image. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Work around ld bug in older binutils
Commit 549e8152de8039506f69c677a4546e5427aa6ae7 (powerpc: Make the
64-bit kernel as a position-independent executable) added lines to
vmlinux.lds.S to add the extra sections needed to implement a
relocatable kernel. However, those lines seem to trigger a bug in
older versions of GNU ld (such as 2.16.1) when building a
non-relocatable kernel. Since ld 2.16.1 is still a popular choice for
cross-toolchains, this adds an #ifdef to vmlinux.lds.S so the added
lines are only included when building a relocatable kernel.
Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index b39c27e..384dca5 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -187,6 +187,7 @@ SECTIONS
*(.machine.desc)
__machine_desc_end = . ;
}
+#ifdef CONFIG_RELOCATABLE
. = ALIGN(8);
.dynsym : AT(ADDR(.dynsym) - LOAD_OFFSET) { *(.dynsym) }
.dynstr : AT(ADDR(.dynstr) - LOAD_OFFSET) { *(.dynstr) }
@@ -202,6 +203,7 @@ SECTIONS
__rela_dyn_start = .;
*(.rela*)
}
+#endif
/* Fake ELF header containing RPA note; for addnote */
.fakeelf : AT(ADDR(.fakeelf) - LOAD_OFFSET) { *(.fakeelf) }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] mutex: optimise generic mutex implementations
On Wed, 2008-10-22 at 17:59 +0200, Ingo Molnar wrote: * Nick Piggin [EMAIL PROTECTED] wrote: Speed up generic mutex implementations. - atomic operations which both modify the variable and return something imply full smp memory barriers before and after the memory operations involved (failing atomic_cmpxchg, atomic_add_unless, etc don't imply a barrier because they don't modify the target). See Documentation/atomic_ops.txt. So remove extra barriers and branches. - All architectures support atomic_cmpxchg. This has no relation to __HAVE_ARCH_CMPXCHG. We can just take the atomic_cmpxchg path unconditionally This reduces a simple single threaded fastpath lock+unlock test from 590 cycles to 203 cycles on a ppc970 system. Signed-off-by: Nick Piggin [EMAIL PROTECTED] no objections here. Lets merge these two patches via the ppc tree, so that it gets testing on real hardware as well? Acked-by: Ingo Molnar [EMAIL PROTECTED] Allright but in that case it will be after -rc1 unless I manage to sneak something in tomorrow before linux closes the merge window. I can't get an update today. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wed, 2008-10-22 at 14:04 -0700, David Brownell wrote: So if we register the board infos after the controller registered, then nobody will probe the board infos. See above. If you're doing it right, there's no problem. That is, scan the OF tables early. Just like PNP tables get scanned early, for example. It's still pretty yucky in that case to scan the device-tree to convert it into some kind of fugly board info ... I'd rather have the end drivers that actually use those GPIOs scan the device-tree directly. But then, I'm not a believer in generic drivers for things like GPIOs, i2c devices, etc.. :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
linux-next: rr tree build failure
Hi Rusty,
Today's linux-next build (powerpc ppc64_defconfig) failed like this:
arch/powerpc/platforms/cell/spu_base.c: In function 'mm_needs_global_tlbie':
arch/powerpc/platforms/cell/spu_base.c:117: error: implicit declaration of
function '__cpus_setall'
Caused by commit 20ec1a8465bd6d2e7e68fa5a7b09309c920b4792
(cpumask:add-struct-cpumask) which removed __cpus_setall from
include/linux/cpumask.h.
I applied the hack patch below (which is probably not what we want).
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Thu, 23 Oct 2008 15:36:21 +1100
Subject: [PATCH] powerpc/spu: cpumask updates fallout.
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/platforms/cell/spu_base.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spu_base.c
b/arch/powerpc/platforms/cell/spu_base.c
index a5bdb89..a876904 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -111,10 +111,13 @@ void spu_flush_all_slbs(struct mm_struct *mm)
*/
static inline void mm_needs_global_tlbie(struct mm_struct *mm)
{
- int nr = (NR_CPUS 1) ? NR_CPUS : NR_CPUS + 1;
-
/* Global TLBIE broadcast required with SPEs. */
- __cpus_setall(mm-cpu_vm_mask, nr);
+ if (NR_CPUS 1)
+ cpumask_setall(mm-cpu_vm_mask);
+ else {
+ cpumask_set_cpu(0, mm-cpu_vm_mask);
+ cpumask_set_cpu(1, mm-cpu_vm_mask);
+ }
}
void spu_associate_mm(struct spu *spu, struct mm_struct *mm)
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wednesday 22 October 2008, Anton Vorontsov wrote: So have it live in the __init text section... Won't work, unfortunately. I2C devices are created by the i2c controllers, via drivers/of_i2c.c of_register_i2c_devices(). And I'm pointing out a way to have the normal I2C core code flow do that creation. OF shouldn't need to be so much of a special case. There is a good reason to do so, the code needs to know controller's OF node to walk down and register the child nodes (devices). See drivers/i2c/busses/i2c-mpc.c -- it calls of_register_i2c_devices() at the end of the probe(). I don't get it. (But then, so much of the OF support seems needlessly convoluted to me ... on top of seeming to be insufficient for configuring board-specific details.) There's an OF device tree, distinct from the Linux driver model tree. Why should there be any obstacle to accessing records from that tree before the relevant driver model nodes have been created? Remember that the various board_info structs get registered before the driver model nodes for which they are templates. Just translate the OF tree data to those templates(*), then register them. I understand that it's currently structured differetnly than that ... consulting the OF tree late not early. But that's still newish, and from what I've heard so far it doesn't seem like the best structure either... nothing seems to plug in smoothly. - Dave (*) The role of the board_info structs is very similar to the role of OF device attributes. As is the role of the platform_data ... except that's more specific to the chip involved (and its driver), and expects any callbacks to be in C code not FORTH. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: print physical_start for the relocatable kernel
Print physical start address for the relocatable kernel. Also fixes this warning: arch/powerpc/kernel/setup_64.c:447:5: warning: kernstart_addr is not defin Signed-off-by: Michael Neuling [EMAIL PROTECTED] --- arch/powerpc/kernel/setup_64.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) This fixes a small whitespace issue noticed by sfr. Index: linux-2.6-ozlabs/arch/powerpc/kernel/setup_64.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/setup_64.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/setup_64.c @@ -444,9 +444,9 @@ void __init setup_system(void) if (htab_address) printk(htab_address = 0x%p\n, htab_address); printk(htab_hash_mask= 0x%lx\n, htab_hash_mask); -#if PHYSICAL_START 0 - printk(physical_start= 0x%lx\n, PHYSICAL_START); -#endif + if (PHYSICAL_START 0) + printk(physical_start= 0x%lx\n, + PHYSICAL_START); printk(-\n); DBG( - setup_system()\n); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
