Re: [RFC v2] virtio: add virtio-over-PCI driver
On Thu, Feb 26, 2009 at 3:49 PM, Ira Snyder i...@ovro.caltech.edu wrote: On Thu, Feb 26, 2009 at 09:37:14PM +0100, Arnd Bergmann wrote: If the registers for setting up this window don't logically fit into the same device as the one you already use, the cleanest solution would be to have another device just for this and then make a function call into that driver to set up the window. The registers are part of the board control registers. They don't fit at all in the message unit. Doing this in the bootloader seems like a logical place, but that would require any testers to flash a new U-Boot image into their mpc8349emds boards. Alternately, the board platform code (arch/powerpc/platforms/83xx) is an ideal place for 'fixups'. ie. to setup things that the firmware really should be do, but doesn't. Now, I wouldn't need to access these registers at all if the bootloader could handle it. I just don't know if it is possible to have Linux not use some memory that the bootloader allocated, other than with the mem=XXX trick, which I'm sure wouldn't be acceptable. I've just used regular RAM so this is portable to my custom board (mpc8349emds based) and a regular mpc8349emds. I didn't want to change anything board specific. I would love to have the bootloader allocate (or reserve somewhere in the memory map) 16K of RAM, and not be required to allocate it with dma_alloc_coherent(). It would save me plenty of headaches. I believe you can do that through the memory devices in the device tree, by leaving out a small part of the description of main memory, at putting it into the reg property of your own device. I'll explore this option. I didn't even know you could do this. Is a driver that requires the trick acceptable for mainline inclusion? Just like setting up the 16K PCI window, this is very platform specific. Yup. You wouldn't even need to write any code to do this. Just reduce the memory node's RAM size listed in the .dts file by 16k and add a 16K region to the reg property for the messaging region. Speaking of which, the device tree changes should be adding 2 nodes; 1 node to describe the messaging unit, and 1 node to describe the virtio instance. The messaging unit is a general purpose piece of hardware, so it is not appropriate to write a usage-specific device driver that binds against it. I'm kind of working on this right now, so I'll show you what I mean in patch form when I actually get things running. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
At Mon, 20 Apr 2009 22:54:25 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Johannes Berg johan...@sipsolutions.net Tested-by: Andreas Schwab sch...@linux-m68k.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. Applied now. Thanks. Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
At Mon, 20 Apr 2009 22:56:59 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the ppc keywest sound driver to the new model or it will break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I did not get any test report for this one, but it's relatively simple so I am confident I got it right. Applied this one, too. Thanks. Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
At Tue, 21 Apr 2009 08:34:02 +1000, Paul Mackerras wrote: Jean Delvare writes: Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I really don't think you can remove it from Linus' tree at this stage in the 2.6.30 cycle. If it was going to be removed it should have been removed in the merge window. Removing it now has too much risk of introducing regressions in my opinion. I presume you have a development tree where you queue up commits for the i2c subsystem for the next merge window. I suggest you do the removal there now (or whenever you like) and push it to Linus in the next merge window. At least, the conversion patch Jean posted can be in 2.6.30, I think. As the old API is marked deprecated, it should be fixed sooner or later. Whether to remove the whole old i2c-binding in 2.6.30 is a different question, although I myself feel it's feasible. thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context
From: Anton Vorontsov avoront...@ru.mvista.com Date: Sat, 18 Apr 2009 02:03:48 +0400 This will make the system alot more responsive while ping flooding the ucc_geth ethernet interface. Also set NAPI weight to 64 as this is a common value. Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com Applied to net-next-2.6, thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
Takashi Iwai writes: At least, the conversion patch Jean posted can be in 2.6.30, I think. Really? What regression, security hole or serious bug are you going to tell Linus that it fixes? :) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi, Have you taken care of snd-powermac similarly? Yes I did, see my patch keywest: Convert to new-style i2c driver to the alsa-devel and linuxppc-dev mailing lists: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070884.html Would you be able to test this patch? This would be very welcome. I can resend it to you if it helps. Cool. No, was just wondering, I can't test it, none of my machines can use that (which is why I wrote aoa, heh) johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
On Tue, 21 Apr 2009 11:23:00 +0200, Jean Delvare wrote: On Tue, 21 Apr 2009 08:31:00 +0200, Takashi Iwai wrote: At Mon, 20 Apr 2009 22:56:59 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the ppc keywest sound driver to the new model or it will break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I did not get any test report for this one, but it's relatively simple so I am confident I got it right. Applied this one, too. Thanks. Thanks Takashi. BTW, I forgot to mention again that the new i2c binding model is functional since kernel 2.6.25, so for the external alsa driver tree you will want to guard these changes with appropriate ifdef magic. Err, make that 2.6.30, sorry. While the infrastructure was there since 2.6.25, the way I converted the sound drivers doesn't fit in what earlier kernels considered acceptable (the checks on which driver methods were implemented was a little too strict IMHO). So the converted drivers can only be used with kernels = 2.6.30. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [net, 83xx] ucc_geth.c: Fix upsmr setting in RMII mode
If using the UCC on a MPC8360 in RMII mode, don;t set
UCC_GETH_UPSMR_RPM bit in the upsmr register.
Signed-off-by: Heiko Schocher h...@denx.de
---
drivers/net/ucc_geth.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d3f39e8..44f8392 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1394,7 +1394,8 @@ static int adjust_enet_interface(struct ucc_geth_private
*ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
- upsmr |= UCC_GETH_UPSMR_RPM;
+ if (ugeth-phy_interface != PHY_INTERFACE_MODE_RMII)
+ upsmr |= UCC_GETH_UPSMR_RPM;
switch (ugeth-max_speed) {
case SPEED_10:
upsmr |= UCC_GETH_UPSMR_R10M;
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
Hi Paul, Takashi, On Tue, 21 Apr 2009 08:33:43 +0200, Takashi Iwai wrote: At Tue, 21 Apr 2009 08:34:02 +1000, Paul Mackerras wrote: Jean Delvare writes: Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I really don't think you can remove it from Linus' tree at this stage in the 2.6.30 cycle. If it was going to be removed it should have been removed in the merge window. It would have happened if the developers/maintainers who see deprecation warnings when they build their drivers had paid attention to them. And actually some did, but not all. The remaining drivers are the ones nobody cared about, and this is the reason why I have to take care of them myself, that late in the development cycle. Note that the removal had already been scheduled for 2.6.29, and it did not happen. The set of legacy drivers did shrink a bit between 2.6.29-rc1 and 2.6.30-rc1 (thanks to Hans Verkuil) but not as much as it should have. Basically the number of remaining driver was halved. If the number of remaining drivers is halved with each release cycle, the legacy model is never going to be removed ;) Removing it now has too much risk of introducing regressions in my opinion. Not removing it now has a high risk of developers continuing to ignore the deprecation warnings and adding new legacy drivers, which I then must convert to the new model. This never ends. I know my behavior may seem a bit rude, but apparently this is the only way to get things to actually happen. I've been waiting for over a year already! I don't think the risk is that high, at least not for sound drivers. The conversions are fairly easy and if something really went wrong, fixing it is a matter of minutes. Please note that the removal of the legacy model isn't my goal per se. The fact is that the legacy model needs to be removed for further developments of i2c-core to happen, in particular the support of i2C bus multiplexers. There are patches waiting for inclusion since early February, which I can't take as long as the legacy i2c model is in. This is why I am pushing. I presume you have a development tree where you queue up commits for the i2c subsystem for the next merge window. I suggest you do the removal there now (or whenever you like) and push it to Linus in the next merge window. At least, the conversion patch Jean posted can be in 2.6.30, I think. As the old API is marked deprecated, it should be fixed sooner or later. Whether to remove the whole old i2c-binding in 2.6.30 is a different question, although I myself feel it's feasible. I have converted all remaining drivers by now: http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted It's really only a matter of getting them tested in time now. Given that most drivers are powermac ones, what I really need here is powermac users/maintainers to test my patches and report success or failure. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [net, 83xx] ucc_geth.c: Fix upsmr setting in RMII mode
On Tue, Apr 21, 2009 at 4:36 PM, Heiko Schocher h...@denx.de wrote:
If using the UCC on a MPC8360 in RMII mode, don;t set
UCC_GETH_UPSMR_RPM bit in the upsmr register.
Signed-off-by: Heiko Schocher h...@denx.de
Acked-by: Li Yang le...@freescale.com
---
drivers/net/ucc_geth.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d3f39e8..44f8392 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1394,7 +1394,8 @@ static int adjust_enet_interface(struct
ucc_geth_private *ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
- upsmr |= UCC_GETH_UPSMR_RPM;
+ if (ugeth-phy_interface != PHY_INTERFACE_MODE_RMII)
+ upsmr |= UCC_GETH_UPSMR_RPM;
switch (ugeth-max_speed) {
case SPEED_10:
upsmr |= UCC_GETH_UPSMR_R10M;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] [net, 83xx] ucc_geth.c: Fix upsmr setting in RMII mode
It is correct.
Thanks
-Original Message-
From: Heiko Schocher [mailto:h...@denx.de]
Sent: Tuesday, April 21, 2009 11:37 AM
To: Li Yang-R58472
Cc: Gridish Shlomi-RM96313; Kumar Gala;
net...@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: [PATCH] [net, 83xx] ucc_geth.c: Fix upsmr setting in
RMII mode
If using the UCC on a MPC8360 in RMII mode, don;t set
UCC_GETH_UPSMR_RPM bit in the upsmr register.
Signed-off-by: Heiko Schocher h...@denx.de
---
drivers/net/ucc_geth.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index d3f39e8..44f8392 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -1394,7 +1394,8 @@ static int adjust_enet_interface(struct
ucc_geth_private *ugeth)
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RGMII_TXID) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
- upsmr |= UCC_GETH_UPSMR_RPM;
+ if (ugeth-phy_interface != PHY_INTERFACE_MODE_RMII)
+ upsmr |= UCC_GETH_UPSMR_RPM;
switch (ugeth-max_speed) {
case SPEED_10:
upsmr |= UCC_GETH_UPSMR_R10M;
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
Not removing it now has a high risk of developers continuing to ignore the deprecation warnings and adding new legacy drivers, which I then must convert to the new model. This never ends. I know my behavior may seem a bit rude, but apparently this is the only way to get things to actually happen. I've been waiting for over a year already! I don't think the risk is that high, at least not for sound drivers. The conversions are fairly easy and if something really went wrong, fixing it is a matter of minutes. Please note that the removal of the legacy model isn't my goal per se. The fact is that the legacy model needs to be removed for further developments of i2c-core to happen, in particular the support of i2C bus multiplexers. There are patches waiting for inclusion since early February, which I can't take as long as the legacy i2c model is in. This is why I am pushing. Full ACK! -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers
Hi Johannes, On Mon, 20 Apr 2009 23:04:52 +0200, Johannes Berg wrote: On Mon, 2009-04-20 at 22:54 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the AOA codec drivers to the new model or they'll break. Signed-off-by: Jean Delvare kh...@linux-fr.org Tested-by: Johannes Berg johan...@sipsolutions.net Tested-by: Andreas Schwab sch...@linux-m68k.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. Have you taken care of snd-powermac similarly? Yes I did, see my patch keywest: Convert to new-style i2c driver to the alsa-devel and linuxppc-dev mailing lists: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/070884.html Would you be able to test this patch? This would be very welcome. I can resend it to you if it helps. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
At Tue, 21 Apr 2009 19:33:00 +1000, Paul Mackerras wrote: Takashi Iwai writes: At least, the conversion patch Jean posted can be in 2.6.30, I think. Really? What regression, security hole or serious bug are you going to tell Linus that it fixes? :) Build warning fixes :) Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
On Tue, 21 Apr 2009 08:31:00 +0200, Takashi Iwai wrote: At Mon, 20 Apr 2009 22:56:59 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the ppc keywest sound driver to the new model or it will break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I did not get any test report for this one, but it's relatively simple so I am confident I got it right. Applied this one, too. Thanks. Thanks Takashi. BTW, I forgot to mention again that the new i2c binding model is functional since kernel 2.6.25, so for the external alsa driver tree you will want to guard these changes with appropriate ifdef magic. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] keywest: Convert to new-style i2c driver
At Tue, 21 Apr 2009 11:23:00 +0200, Jean Delvare wrote: On Tue, 21 Apr 2009 08:31:00 +0200, Takashi Iwai wrote: At Mon, 20 Apr 2009 22:56:59 +0200, Jean Delvare wrote: The legacy i2c binding model is going away soon, so convert the ppc keywest sound driver to the new model or it will break. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Takashi Iwai ti...@suse.de --- Takashi, please push this patch to Linus quickly, as this is blocking the removal of the legacy i2c binding model, which is scheduled for 2.6.30. I did not get any test report for this one, but it's relatively simple so I am confident I got it right. Applied this one, too. Thanks. Thanks Takashi. BTW, I forgot to mention again that the new i2c binding model is functional since kernel 2.6.25, so for the external alsa driver tree you will want to guard these changes with appropriate ifdef magic. I thought some patch (applied on 2.6.30) was needed to get them working properly? Anyway, I already added ifdef in alsa-driver external tree to make 2.6.29 and earlier building with the old i2c code. thanks, Takashi ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
Mark Ware schrieb: Recent DMA changes result in a BUG() when NULL is passed to dma_alloc_coherent in place of a device. This seems to have happened in 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be. Signed-off-by: Mark Ware mw...@elphinstone.net Acked-by: Jochen Friedrich joc...@scram.de Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
Recent DMA changes result in a BUG() when NULL is passed to
dma_alloc_coherent in place of a device.
Signed-off-by: Mark Ware mw...@elphinstone.net
---
This patch fixes the BUG() during boot that has appeared during the
2.6.30 window. It has been tested and appears correct on my 8280 based
board.
Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it belongs.
drivers/i2c/busses/i2c-cpm.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index 3fcf78e..83276d2 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -532,7 +532,8 @@ static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
for (i = 0; i CPM_MAXBD; i++) {
cpm-rxbuf[i] = dma_alloc_coherent(
- NULL, CPM_MAX_READ + 1, cpm-rxdma[i], GFP_KERNEL);
+ cpm-ofdev-dev, CPM_MAX_READ + 1, cpm-rxdma[i],
+ GFP_KERNEL);
if (!cpm-rxbuf[i]) {
ret = -ENOMEM;
goto out_muram;
@@ -540,7 +541,8 @@ static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
out_be32(rbdf[i].cbd_bufaddr, ((cpm-rxdma[i] + 1) ~1));
cpm-txbuf[i] = (unsigned char *)dma_alloc_coherent(
- NULL, CPM_MAX_READ + 1, cpm-txdma[i], GFP_KERNEL);
+ cpm-ofdev-dev, CPM_MAX_READ + 1, cpm-txdma[i],
+ GFP_KERNEL);
if (!cpm-txbuf[i]) {
ret = -ENOMEM;
goto out_muram;
@@ -585,10 +587,10 @@ static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)
out_muram:
for (i = 0; i CPM_MAXBD; i++) {
if (cpm-rxbuf[i])
- dma_free_coherent(NULL, CPM_MAX_READ + 1,
+ dma_free_coherent(cpm-ofdev-dev, CPM_MAX_READ + 1,
cpm-rxbuf[i], cpm-rxdma[i]);
if (cpm-txbuf[i])
- dma_free_coherent(NULL, CPM_MAX_READ + 1,
+ dma_free_coherent(cpm-ofdev-dev, CPM_MAX_READ + 1,
cpm-txbuf[i], cpm-txdma[i]);
}
cpm_muram_free(cpm-dp_addr);
@@ -619,9 +621,9 @@ static void cpm_i2c_shutdown(struct cpm_i2c *cpm)
/* Free all memory */
for (i = 0; i CPM_MAXBD; i++) {
- dma_free_coherent(NULL, CPM_MAX_READ + 1,
+ dma_free_coherent(cpm-ofdev-dev, CPM_MAX_READ + 1,
cpm-rxbuf[i], cpm-rxdma[i]);
- dma_free_coherent(NULL, CPM_MAX_READ + 1,
+ dma_free_coherent(cpm-ofdev-dev, CPM_MAX_READ + 1,
cpm-txbuf[i], cpm-txdma[i]);
}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] IB/ehca: Perfomance improvment for creation of queue pairs
This patchset contains performance improvments for ehca driver. It will skip code which is not necessary for userspace queue pairs and will replace vmalloc() calls with kmalloc(). Because of this fundamental code change we will also increment the version number. They should apply cleanly against 2.6.30 git tree. Thanks Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc
From: Anton Blanchard antonb at au1.ibm.com
To improve performance of driver ressource allocation,
replace the vmalloc() call with kmalloc().
Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
---
drivers/infiniband/hw/ehca/ipz_pt_fn.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
index c3a3284..a260559 100644
--- a/drivers/infiniband/hw/ehca/ipz_pt_fn.c
+++ b/drivers/infiniband/hw/ehca/ipz_pt_fn.c
@@ -220,7 +220,7 @@ int ipz_queue_ctor(struct ehca_pd *pd, struct ipz_queue
*queue,
queue-small_page = NULL;
/* allocate queue page pointers */
- queue-queue_pages = vmalloc(nr_of_pages * sizeof(void *));
+ queue-queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL);
if (!queue-queue_pages) {
ehca_gen_err(Couldn't allocate queue page list);
return 0;
@@ -240,7 +240,7 @@ int ipz_queue_ctor(struct ehca_pd *pd, struct ipz_queue
*queue,
ipz_queue_ctor_exit0:
ehca_gen_err(Couldn't alloc pages queue=%p
nr_of_pages=%x, queue, nr_of_pages);
- vfree(queue-queue_pages);
+ kfree(queue-queue_pages);
return 0;
}
@@ -262,7 +262,7 @@ int ipz_queue_dtor(struct ehca_pd *pd, struct ipz_queue
*queue)
free_page((unsigned long)queue-queue_pages[i]);
}
- vfree(queue-queue_pages);
+ kfree(queue-queue_pages);
return 1;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] i2c-cpm: Pass dev ptr to dma_*_coherent rather than NULL
On Apr 21, 2009, at 7:49 AM, Mark Ware wrote: Recent DMA changes result in a BUG() when NULL is passed to dma_alloc_coherent in place of a device. Signed-off-by: Mark Ware mw...@elphinstone.net --- This patch fixes the BUG() during boot that has appeared during the 2.6.30 window. It has been tested and appears correct on my 8280 based board. Sent to both linuxppc-dev and linux-i2c, since I'm not sure where it belongs. drivers/i2c/busses/i2c-cpm.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org Ben, I'm expecting you to pick this up unless you tell me otherwise. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] IB/ehca: Remove unnecessary memory operations for userspace queue pairs
The queue map for flush completion circumvention is only used for
kernel space queue pairs. This patch skips the allocation of the queue maps
in case the QP is created for userspace. In addition, this patch
does not iomap the galpas for kernel usage if the queue pair is only used
in userspace. These changes will improve the performance of creation
of userspace queue pairs.
Signed-off-by: Stefan Roscher stefan.roscher at de.ibm.com
---
drivers/infiniband/hw/ehca/ehca_qp.c | 94 ++--
drivers/infiniband/hw/ehca/hcp_if.c |6 +-
drivers/infiniband/hw/ehca/hcp_if.h |2 +-
drivers/infiniband/hw/ehca/hcp_phyp.c | 11 +++--
drivers/infiniband/hw/ehca/hcp_phyp.h |2 +-
5 files changed, 65 insertions(+), 50 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index 00c1081..ead4e71 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -461,7 +461,7 @@ static struct ehca_qp *internal_create_qp(
ib_device);
struct ib_ucontext *context = NULL;
u64 h_ret;
- int is_llqp = 0, has_srq = 0;
+ int is_llqp = 0, has_srq = 0, is_user = 0;
int qp_type, max_send_sge, max_recv_sge, ret;
/* h_call's out parameters */
@@ -609,9 +609,6 @@ static struct ehca_qp *internal_create_qp(
}
}
- if (pd-uobject udata)
- context = pd-uobject-context;
-
my_qp = kmem_cache_zalloc(qp_cache, GFP_KERNEL);
if (!my_qp) {
ehca_err(pd-device, pd=%p not enough memory to alloc qp, pd);
@@ -619,6 +616,11 @@ static struct ehca_qp *internal_create_qp(
return ERR_PTR(-ENOMEM);
}
+ if (pd-uobject udata) {
+ is_user = 1;
+ context = pd-uobject-context;
+ }
+
atomic_set(my_qp-nr_events, 0);
init_waitqueue_head(my_qp-wait_completion);
spin_lock_init(my_qp-spinlock_s);
@@ -707,7 +709,7 @@ static struct ehca_qp *internal_create_qp(
(parms.squeue.is_small || parms.rqueue.is_small);
}
- h_ret = hipz_h_alloc_resource_qp(shca-ipz_hca_handle, parms);
+ h_ret = hipz_h_alloc_resource_qp(shca-ipz_hca_handle, parms, is_user);
if (h_ret != H_SUCCESS) {
ehca_err(pd-device, h_alloc_resource_qp() failed h_ret=%lli,
h_ret);
@@ -769,18 +771,20 @@ static struct ehca_qp *internal_create_qp(
goto create_qp_exit2;
}
- my_qp-sq_map.entries = my_qp-ipz_squeue.queue_length /
-my_qp-ipz_squeue.qe_size;
- my_qp-sq_map.map = vmalloc(my_qp-sq_map.entries *
- sizeof(struct ehca_qmap_entry));
- if (!my_qp-sq_map.map) {
- ehca_err(pd-device, Couldn't allocate squeue
-map ret=%i, ret);
- goto create_qp_exit3;
+ if (!is_user) {
+ my_qp-sq_map.entries = my_qp-ipz_squeue.queue_length /
+ my_qp-ipz_squeue.qe_size;
+ my_qp-sq_map.map = vmalloc(my_qp-sq_map.entries *
+ sizeof(struct
ehca_qmap_entry));
+ if (!my_qp-sq_map.map) {
+ ehca_err(pd-device, Couldn't allocate squeue
+map ret=%i, ret);
+ goto create_qp_exit3;
+ }
+ INIT_LIST_HEAD(my_qp-sq_err_node);
+ /* to avoid the generation of bogus flush CQEs */
+ reset_queue_map(my_qp-sq_map);
}
- INIT_LIST_HEAD(my_qp-sq_err_node);
- /* to avoid the generation of bogus flush CQEs */
- reset_queue_map(my_qp-sq_map);
}
if (HAS_RQ(my_qp)) {
@@ -792,20 +796,21 @@ static struct ehca_qp *internal_create_qp(
and pages ret=%i, ret);
goto create_qp_exit4;
}
-
- my_qp-rq_map.entries = my_qp-ipz_rqueue.queue_length /
- my_qp-ipz_rqueue.qe_size;
- my_qp-rq_map.map = vmalloc(my_qp-rq_map.entries *
- sizeof(struct ehca_qmap_entry));
- if (!my_qp-rq_map.map) {
- ehca_err(pd-device, Couldn't allocate squeue
- map ret=%i, ret);
- goto create_qp_exit5;
+ if (!is_user) {
+ my_qp-rq_map.entries = my_qp-ipz_rqueue.queue_length /
+ my_qp-ipz_rqueue.qe_size;
+ my_qp-rq_map.map = vmalloc(my_qp-rq_map.entries *
+
[PATCH 3/3] IB/ehca: Increment version number
Signed-off-by: Stefan Roscher stefan.rosc...@de.ibm.com --- drivers/infiniband/hw/ehca/ehca_main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c index 368311c..85905ab 100644 --- a/drivers/infiniband/hw/ehca/ehca_main.c +++ b/drivers/infiniband/hw/ehca/ehca_main.c @@ -52,7 +52,7 @@ #include ehca_tools.h #include hcp_if.h -#define HCAD_VERSION 0026 +#define HCAD_VERSION 0027 MODULE_LICENSE(Dual BSD/GPL); MODULE_AUTHOR(Christoph Raisch rai...@de.ibm.com); -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/5] powerpc: Use sg-dma_length in sg_dma_len() macro on 32-bit
On Apr 20, 2009, at 3:06 PM, Kumar Gala wrote:
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote:
Currently, the 32-bit code uses sg-length instead of sg-dma_lentgh
to report sg_dma_len. However, since the default dma code for 32-bit
(the dma_direct case) sets dma_length and length to the same thing,
we should be able to use dma_length there as well. This gets rid of
some 32-vs-64-bit ifdefs, and is needed by the swiotlb code which
actually distinguishes between dma_length and length.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/include/asm/scatterlist.h |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/scatterlist.h b/arch/powerpc/
include/asm/scatterlist.h
index fcf7d55..912bf59 100644
--- a/arch/powerpc/include/asm/scatterlist.h
+++ b/arch/powerpc/include/asm/scatterlist.h
@@ -21,7 +21,7 @@ struct scatterlist {
unsigned int offset;
unsigned int length;
can we get rid of length?
No - they're both used by the iotlb code and are conceptually
different. dma_length can get set to less than length to indicate
that something went wrong with a dma request - the iotlb code sets it
to 0 if we can't allocate a bounce buffer, for example. It probably
has other uses as well - this is just the one I'm familiar with. In
most cases they are equal.
Cheers,
B
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn
On Apr 20, 2009, at 8:10 PM, David Gibson wrote:
On Mon, Apr 20, 2009 at 11:26:47AM -0500, Becky Bruce wrote:
The new dts places most of the devices in physical address space
above 32-bits, which allows us to have more than 4GB of RAM present.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597 ++
++
1 files changed, 597 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts b/arch/
powerpc/boot/dts/mpc8641_hpcn_36b.dts
new file mode 100644
index 000..baa3dba
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
@@ -0,0 +1,597 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
[snip]
+ soc8...@fffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
Uh, you definitely need something more specific in the compatible
property before simple-bus.
This is a copy of the existing mpc8641hpcn dts file, with just
physical address changes, so if there's a problem here it definitely
exists in the current 8641hpcn dts, and possibly other dts files as
well. I think the correct solution is for me to go look at that .dts
(and any others that may be similar), and put out a followup to fix
them all.
Thanks,
Becky
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Performance differences with IRQ_ALL_CPUS
Hi, I have board with MPC8572E (dual core PPC). I have one board running kernel with IRQ_ALL_CPUS set to Y and another with that option turned off. Kernel version #2.6.26 With IRQ_ALL_CPUS turned off ( Here interrupts all go to CPU0 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18:1394100 0 OpenPIC Edge ide0 With IRQ_ALL_CPUS turned on I see (Here interrupts go to CPU0 and CPU1 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18: 44951 54765 OpenPIC Edge ide0 I expected that with IRQ_ALL_CPUS -- interrupt sharing I would be able to get higher througput but I see things otherway around. Would someone care to enlighten me as to why when I set IRQ_ALL_CPUS disk I/O performance goes down so much? Under what circumstances should one then turn on IRQ_ALL_CPUS option on PPC platform? Regards, /Subodh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PCI changes 2.6.26 = 2.6.28
I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
If the firmware missed to initialize the PHY correctly,
Linux may hang up on socrates while eth0/eth1 interface
startup (caused by continuous unacknowledged PHY interrupt).
This patch adds PHY fixup to socrates platform code to
ensure the PHY is pre-initialized correctly. It is needed
to be compatible with older firmware.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
use macros instead of register numbers as
suggested by Anton
Kumar, could you please consider this patch for
inclusion into 2.6.30? Thanks!
arch/powerpc/platforms/85xx/socrates.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/socrates.c
b/arch/powerpc/platforms/85xx/socrates.c
index d0e8443..bde0a97 100644
--- a/arch/powerpc/platforms/85xx/socrates.c
+++ b/arch/powerpc/platforms/85xx/socrates.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/seq_file.h
#include linux/of_platform.h
+#include linux/phy.h
#include asm/system.h
#include asm/time.h
@@ -78,6 +79,23 @@ static void __init socrates_pic_init(void)
of_node_put(np);
}
+#define MII_M1011_IMASK0x12
+#define MII_M1011_IEVENT 0x13
+static int socrates_m88e1121_fixup(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_M1011_IMASK, 0);
+ if (err 0)
+ return err;
+
+ err = phy_read(phydev, MII_M1011_IEVENT);
+ if (err 0)
+ return err;
+
+ return 0;
+}
+
/*
* Setup the architecture
*/
@@ -105,6 +123,8 @@ static struct of_device_id __initdata socrates_of_bus_ids[]
= {
static void __init socrates_init(void)
{
of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
+ phy_register_fixup_for_uid(0x1410cb0, 0xff0,
+ socrates_m88e1121_fixup);
}
/*
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc/pasemi: Fix no SMP build error
On Fri, Apr 17, 2009 at 09:36:37AM -0700, Geoff Levand wrote: A non-SMP version of smp_send_stop() is now included in smp.h. Remove the unneeded def in the pasemi setup.c. Fixes build errors like these when CONFIG_SMP=n: arch/powerpc/platforms/pasemi/setup.c:48: error: redefinition of ???smp_send_stop??? include/linux/smp.h:125: error: previous definition of 'smp_send_stop' was here Thanks for taking care of this. Reported-by: subr...@linux.vnet.ibm.com Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com Acked-by: Olof Johansson o...@lixom.net -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] IB/ehca: Perfomance improvment for creation of queue pairs
Because of this fundamental code change we will also increment the version number. So this is 2.6.31-targeted stuff I assume? (Too late in the 2.6.30 cycle for fundamental code change of course) - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc
+queue-queue_pages = kmalloc(nr_of_pages * sizeof(void *), GFP_KERNEL); How big might this buffer be? Any chance of allocation failure due to memory fragmentation? - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[BUILD FAILURE 01/12] Next April 21 : PPC64 randconfig [arch/powerpc/platforms/pasemi/setup.o]
Observed the following build error. Reported this earlier on 9th April: http://lkml.org/lkml/2009/4/9/225, Geoff Levand geoffrey.lev...@am.sony.com provided a patch on 17th April. This needs to be merged to the tree. http://lkml.org/lkml/2009/4/17/313, CC arch/powerpc/platforms/pasemi/setup.o arch/powerpc/platforms/pasemi/setup.c:48: error: redefinition of ‘smp_send_stop’ include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’ was here make[2]: *** [arch/powerpc/platforms/pasemi/setup.o] Error 1 make[1]: *** [arch/powerpc/platforms/pasemi] Error 2 make: *** [arch/powerpc/platforms] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 03:35:28 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y # CONFIG_SMP is not set CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_TRACE=y CONFIG_RCU_FANOUT=64 CONFIG_RCU_FANOUT_EXACT=y CONFIG_TREE_RCU_TRACE=y # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_CGROUP_MEM_RES_CTLR=y CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y CONFIG_MM_OWNER=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_IPC_NS is not set CONFIG_USER_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set CONFIG_SLUB_ALLOCATOR=y CONFIG_SLUB=y # CONFIG_SLQB_ALLOCATOR is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y
[BUILD FAILURE 02/12] Next April 21 : PPC64 randconfig [drivers/net/ni65.c]
I am observing this for the first time: CC drivers/net/ni65.o drivers/net/ni65.c: In function ‘ni65_init_lance’: drivers/net/ni65.c:585: error: implicit declaration of function ‘isa_virt_to_bus’ drivers/net/ni65.c: In function ‘ni65_stop_start’: drivers/net/ni65.c:757: error: implicit declaration of function ‘isa_bus_to_virt’ make[2]: *** [drivers/net/ni65.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 03:35:31 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_TRACE is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_EXACT=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y # CONFIG_CGROUP_NS is not set CONFIG_CGROUP_FREEZER=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_INTEGRITY=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=deadline CONFIG_FREEZER=y CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_CHRP=y CONFIG_PPC_MPC512x=y CONFIG_PPC_MPC5121=y # CONFIG_MPC5121_ADS is not set CONFIG_MPC5121_GENERIC=y CONFIG_PPC_MPC52xx=y # CONFIG_PPC_MPC5200_SIMPLE is not set CONFIG_PPC_EFIKA=y CONFIG_PPC_LITE5200=y # CONFIG_PPC_MEDIA5200 is not set
[BUILD FAILURE 03/12] Next April 21 : PPC64 randconfig [arch/powerpc/kernel/of_platform.o]
Reported this earlier on 14th April 2009: http://lkml.org/lkml/2009/4/14/480, Michael, Any fix in sight ? http://lkml.org/lkml/2009/4/14/676, CC arch/powerpc/kernel/of_platform.o arch/powerpc/kernel/of_platform.c: In function ‘of_pci_phb_probe’: arch/powerpc/kernel/of_platform.c:270: error: implicit declaration of function ‘pci_devs_phb_init_dynamic’ arch/powerpc/kernel/of_platform.c:279: error: implicit declaration of function ‘scan_phb’ arch/powerpc/kernel/of_platform.c:295: error: implicit declaration of function ‘pci_bus_add_devices’ make[1]: *** [arch/powerpc/kernel/of_platform.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 03:35:34 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y # CONFIG_VIRT_CPU_ACCOUNTING is not set # CONFIG_SMP is not set CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y # CONFIG_ARCH_MAY_HAVE_PC_FDC is not set CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SYSVIPC is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_RT_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_STRIP_ASM_SYMS is not set # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB_ALLOCATOR is not set CONFIG_SLUB_ALLOCATOR=y CONFIG_SLUB=y # CONFIG_SLQB_ALLOCATOR is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set # CONFIG_BLOCK is not set # CONFIG_FREEZER is not set # # Platform support # CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_SCANLOG=y CONFIG_LPARCFG=y # CONFIG_PPC_PSERIES_DEBUG is not set CONFIG_PPC_SMLPAR=y # CONFIG_CMM is not set CONFIG_DTL=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_PS3 is not set CONFIG_PPC_CELL=y CONFIG_PPC_CELL_COMMON=y CONFIG_PPC_CELL_NATIVE=y CONFIG_PPC_IBM_CELL_BLADE=y # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_CELL_QPACE is not set # # Cell Broadband Engine options # CONFIG_SPU_FS=y # CONFIG_SPU_FS_64K_LS is not set # CONFIG_SPU_TRACE is not set CONFIG_SPU_BASE=y # CONFIG_CBE_RAS is not set CONFIG_PPC_IBM_CELL_POWERBUTTON=y
[BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
Reported this earlier on 14th April: http://lkml.org/lkml/2009/4/14/490, Is there a solution available ? CC drivers/macintosh/mediabay.o In file included from drivers/macintosh/mediabay.c:21: include/linux/ide.h:610: error: field ‘sense_rq’ has incomplete type make[2]: *** [drivers/macintosh/mediabay.o] Error 1 make[1]: *** [drivers/macintosh] Error 2 make: *** [drivers] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 03:35:47 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_SMP is not set CONFIG_NOT_COHERENT_CACHE=y CONFIG_CHECK_CACHE_COHERENCY=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_DEFAULT_UIMAGE=y CONFIG_HIBERNATE_32=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=m CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_NS is not set CONFIG_CGROUP_FREEZER=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y # CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set # CONFIG_SLQB_ALLOCATOR is not set CONFIG_SLOB=y # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_CLK=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set CONFIG_MODULE_SRCVERSION_ALL=y # CONFIG_BLOCK is not set CONFIG_FREEZER=y CONFIG_PPC_MSI_BITMAP=y # # Platform support # CONFIG_PPC_CHRP=y CONFIG_PPC_MPC512x=y CONFIG_PPC_MPC5121=y CONFIG_MPC5121_ADS=y CONFIG_MPC5121_GENERIC=y CONFIG_PPC_MPC52xx=y # CONFIG_PPC_MPC5200_SIMPLE is not set # CONFIG_PPC_EFIKA is not set # CONFIG_PPC_LITE5200 is not set CONFIG_PPC_MEDIA5200=y CONFIG_PPC_MPC5200_BUGFIX=y # CONFIG_PPC_MPC5200_GPIO is not set CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set CONFIG_PPC_82xx=y # CONFIG_MPC8272_ADS is not set CONFIG_PQ2FADS=y # CONFIG_EP8248E is not set # CONFIG_MGCOGE is not set CONFIG_PQ2ADS=y CONFIG_8260=y CONFIG_PQ2_ADS_PCI_PIC=y # CONFIG_PPC_83xx is not set #
[BUILD FAILURE 08/12] Next April 21 : PPC64 randconfig [drivers/net/pasemi_mac_driver.ko]
Reported this on 9th April earlier: http://lkml.org/lkml/2009/4/9/276, I hope the following Patch will solve this problem as well: Geoff Levand geoffrey.lev...@am.sony.com provided a patch on 17th April. http://lkml.org/lkml/2009/4/17/313, WRAParch/powerpc/boot/zImage.pmac strip -s -R .comment vmlinux -o arch/powerpc/boot/zImage.iseries printf \x02 | dd of=arch/powerpc/boot/zImage.iseries conv=notrunc bs=1 seek=17 1+0 records in 1+0 records out 1 byte (1 B) copied, 0.0358298 s, 0.0 kB/s Building modules, stage 2. MODPOST 338 modules ERROR: .lro_receive_skb [drivers/net/pasemi_mac_driver.ko] undefined! ERROR: .lro_flush_all [drivers/net/pasemi_mac_driver.ko] undefined! WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 03:35:41 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_PPC_BOOK3S=y CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y CONFIG_RD_LZMA=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB_ALLOCATOR is not set # CONFIG_SLUB_ALLOCATOR is not set CONFIG_SLQB_ALLOCATOR=y CONFIG_SLQB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_BLOCK=y CONFIG_BLK_DEV_INTEGRITY=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=m CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=m # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set CONFIG_DEFAULT_NOOP=y CONFIG_DEFAULT_IOSCHED=noop # CONFIG_FREEZER is not set CONFIG_PPC_MSI_BITMAP=y
[BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
Observing this for the first time: CC drivers/usb/host/ohci-hcd.o In file included from drivers/usb/host/ohci-hcd.c:1060: drivers/usb/host/ohci-ppc-of.c:242:2: error: #error No endianess selected for ppc-of-ohci make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 make[2]: *** [drivers/usb/host] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 06:12:59 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set # CONFIG_RT_GROUP_SCHED is not set # CONFIG_USER_SCHED is not set CONFIG_CGROUP_SCHED=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_NS=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_CGROUP_MEM_RES_CTLR is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_USER_NS=y # CONFIG_PID_NS is not set # CONFIG_NET_NS is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y # CONFIG_SIGNALFD is not set # CONFIG_TIMERFD is not set # CONFIG_EVENTFD is not set CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB_ALLOCATOR=y CONFIG_SLAB=y # CONFIG_SLUB_ALLOCATOR is not set # CONFIG_SLQB_ALLOCATOR is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_FORCE_LOAD=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_STOP_MACHINE=y # CONFIG_BLOCK is not set CONFIG_FREEZER=y # # Platform support # CONFIG_PPC_CHRP=y CONFIG_PPC_MPC512x=y CONFIG_PPC_MPC5121=y CONFIG_MPC5121_ADS=y # CONFIG_MPC5121_GENERIC is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set CONFIG_PPC_82xx=y CONFIG_MPC8272_ADS=y CONFIG_PQ2FADS=y CONFIG_EP8248E=y CONFIG_MGCOGE=y CONFIG_PQ2ADS=y CONFIG_8260=y CONFIG_8272=y CONFIG_PQ2_ADS_PCI_PIC=y # CONFIG_PPC_83xx is not set CONFIG_PPC_86xx=y # CONFIG_MPC8641_HPCN is not set # CONFIG_SBC8641D is not set CONFIG_MPC8610_HPCD=y
[BUILD FAILURE 12/12] Next April 21 : PPC64 randconfig [crypto/async_tx/async_xor.o]
Observing this also for the first time: CC crypto/async_tx/async_xor.o crypto/async_tx/async_xor.c: In function ‘async_xor_init’: crypto/async_tx/async_xor.c:310: error: size of array ‘type name’ is negative make[2]: *** [crypto/async_tx/async_xor.o] Error 1 make[1]: *** [crypto/async_tx] Error 2 make: *** [crypto] Error 2 --- Regards-- Subrata # # Automatically generated make config: don't edit # Linux kernel version: 2.6.30-rc2 # Tue Apr 21 06:18:52 2009 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y CONFIG_PPC_FPU=y CONFIG_PTE_64BIT=y CONFIG_PHYS_64BIT=y CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set CONFIG_SMP=y CONFIG_NR_CPUS=4 CONFIG_NOT_COHERENT_CACHE=y CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_LOCKBREAK=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_DEFAULT_UIMAGE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # # CONFIG_CLASSIC_RCU is not set # CONFIG_TREE_RCU is not set CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y # CONFIG_FAIR_GROUP_SCHED is not set CONFIG_RT_GROUP_SCHED=y CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_RELAY=y CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_EMBEDDED=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_STRIP_ASM_SYMS=y CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB_ALLOCATOR is not set CONFIG_SLUB_ALLOCATOR=y CONFIG_SLUB=y # CONFIG_SLQB_ALLOCATOR is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_HAVE_CLK=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_BSG=y CONFIG_BLK_DEV_INTEGRITY=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # CONFIG_FREEZER is not set # # Platform support # CONFIG_PPC_CHRP=y CONFIG_PPC_MPC512x=y CONFIG_PPC_MPC5121=y CONFIG_MPC5121_ADS=y CONFIG_MPC5121_GENERIC=y CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y # CONFIG_PPC_EFIKA is not set # CONFIG_PPC_LITE5200 is not set CONFIG_PPC_MEDIA5200=y CONFIG_PPC_MPC5200_BUGFIX=y # CONFIG_PPC_MPC5200_GPIO is not set CONFIG_PPC_PMAC=y # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_82xx is not set # CONFIG_PQ2ADS is not set #
Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
On Tuesday 21 April 2009 20:51:15 Subrata Modak wrote: Reported this earlier on 14th April: http://lkml.org/lkml/2009/4/14/490, Is there a solution available ? Perfect timing. I was just going through overdue reports. CC drivers/macintosh/mediabay.o In file included from drivers/macintosh/mediabay.c:21: include/linux/ide.h:610: error: field ‘sense_rq’ has incomplete type make[2]: *** [drivers/macintosh/mediabay.o] Error 1 make[1]: *** [drivers/macintosh] Error 2 make: *** [drivers] Error 2 --- From: Bartlomiej Zolnierkiewicz bzoln...@gmail.com Subject: [PATCH] mediabay: fix build for CONFIG_BLOCK=n On Tuesday 14 April 2009 20:31:21 Subrata Modak wrote: Observed the following build error: --- CC drivers/macintosh/mediabay.o In file included from drivers/macintosh/mediabay.c:21: include/linux/ide.h:605: error: field ‘request_sense_rq’ has incomplete type make[2]: *** [drivers/macintosh/mediabay.o] Error 1 make[1]: *** [drivers/macintosh] Error 2 make: *** [drivers] Error 2 --- mediabay shouldn't include linux/ide.h unconditionally so remove the superfluous include from mediabay.c (asm/mediabay.h will pull linux/ide.h in for CONFIG_BLK_DEV_IDE_PMAC=y). Reported-by: Subrata Modak subr...@linux.vnet.ibm.com Cc: Paul Mackerras pau...@samba.org Signed-off-by: Bartlomiej Zolnierkiewicz bzoln...@gmail.com --- drivers/macintosh/mediabay.c |1 - 1 file changed, 1 deletion(-) Index: b/drivers/macintosh/mediabay.c === --- a/drivers/macintosh/mediabay.c +++ b/drivers/macintosh/mediabay.c @@ -18,7 +18,6 @@ #include linux/timer.h #include linux/stddef.h #include linux/init.h -#include linux/ide.h #include linux/kthread.h #include linux/mutex.h #include asm/prom.h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 07/12] Next April 14 : PPC64 randconfig [drivers/ide/pmac.c]
On Tuesday 14 April 2009 20:29:19 Subrata Modak wrote: Observed the following build error: --- CC [M] drivers/ide/pmac.o drivers/ide/pmac.c: In function ‘pmac_ide_init_dev’: drivers/ide/pmac.c:955: error: implicit declaration of function ‘check_media_bay_by_base’ drivers/ide/pmac.c: In function ‘pmac_ide_setup_device’: drivers/ide/pmac.c:1090: error: implicit declaration of function ‘media_bay_set_ide_infos’ make[2]: *** [drivers/ide/pmac.o] Error 1 make[1]: *** [drivers/ide] Error 2 make: *** [drivers] Error 2 --- Should be fixed by: From: Bartlomiej Zolnierkiewicz bzoln...@gmail.com Subject: [PATCH] ide-pmac: fix modular build for CONFIG_PMAC_MEDIABAY=y On Tuesday 14 April 2009 20:29:19 Subrata Modak wrote: Observed the following build error: --- CC [M] drivers/ide/pmac.o drivers/ide/pmac.c: In function ‘pmac_ide_init_dev’: drivers/ide/pmac.c:955: error: implicit declaration of function ‘check_media_bay_by_base’ drivers/ide/pmac.c: In function ‘pmac_ide_setup_device’: drivers/ide/pmac.c:1090: error: implicit declaration of function ‘media_bay_set_ide_infos’ make[2]: *** [drivers/ide/pmac.o] Error 1 make[1]: *** [drivers/ide] Error 2 make: *** [drivers] Error 2 --- IDE PMAC host driver can be modular now so we need to export check_media_bay_by_base() and media_bay_set_ide_infos(). Reported-by: Subrata Modak subr...@linux.vnet.ibm.com Cc: Paul Mackerras pau...@samba.org Signed-off-by: Bartlomiej Zolnierkiewicz bzoln...@gmail.com --- drivers/macintosh/mediabay.c |2 ++ 1 file changed, 2 insertions(+) Index: b/drivers/macintosh/mediabay.c === --- a/drivers/macintosh/mediabay.c +++ b/drivers/macintosh/mediabay.c @@ -447,6 +447,7 @@ int check_media_bay_by_base(unsigned lon return -ENODEV; } +EXPORT_SYMBOL_GPL(check_media_bay_by_base); int media_bay_set_ide_infos(struct device_node* which_bay, unsigned long base, int irq, ide_hwif_t *hwif) @@ -486,6 +487,7 @@ int media_bay_set_ide_infos(struct devic return -ENODEV; } +EXPORT_SYMBOL_GPL(media_bay_set_ide_infos); #endif /* CONFIG_BLK_DEV_IDE_PMAC */ static void media_bay_step(int i) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Tuesday 21 April 2009, Subrata Modak wrote: Observing this for the first time: CC drivers/usb/host/ohci-hcd.o In file included from drivers/usb/host/ohci-hcd.c:1060: drivers/usb/host/ohci-ppc-of.c:242:2: error: #error No endianess Hmm, scripts/get_maintainer.pl doesn't report the PPC folk who maintain that file and its kbuild infrastructure. Can we have some PPC folk look at (and fix) this? selected for ppc-of-ohci make[3]: *** [drivers/usb/host/ohci-hcd.o] Error 1 make[2]: *** [drivers/usb/host] Error 2 make[1]: *** [drivers/usb] Error 2 make: *** [drivers] Error 2 --- Regards-- Subrata ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
INET_LRO as tristate and use from modules (was: Re: [BUILD FAILURE 08/12] Next April 21 : PPC64 randconfig [drivers/net/pasemi_mac_driver.ko])
On Wed, Apr 22, 2009 at 12:23:03AM +0530, Subrata Modak wrote: Reported this on 9th April earlier: http://lkml.org/lkml/2009/4/9/276, I hope the following Patch will solve this problem as well: Geoff Levand geoffrey.lev...@am.sony.com provided a patch on 17th April. http://lkml.org/lkml/2009/4/17/313, No, that's a separate issue. MODPOST 338 modules ERROR: .lro_receive_skb [drivers/net/pasemi_mac_driver.ko] undefined! ERROR: .lro_flush_all [drivers/net/pasemi_mac_driver.ko] undefined! WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 This seems to be a problem with all tristate-capable drivers that use LRO (and uses select INET_LRO in their Kconfig): INET_LRO is a tristate and can thus be a module. Looks like it needs to be a bool instead? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Set error_state to pci_channel_io_normal in eeh_report_reset()
Paul Mackerras wrote: Mike Mason writes: diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c b/arch/powerpc/platforms/pseries/eeh_driver.c index 380420f..9a2a6e3 100644 --- a/arch/powerpc/platforms/pseries/eeh_driver.c +++ b/arch/powerpc/platforms/pseries/eeh_driver.c @@ -182,6 +182,8 @@ static void eeh_report_reset(struct pci_dev *dev, void *userdata) if (!driver) return; + dev-error_state = pci_channel_io_normal; + eeh_enable_irq(dev); if (!driver-err_handler || Your mail client totally mangled the whitespace. I fixed it up and applied it, since the patch was small, but in future please fix your mail client so it doesn't do that. Sorry about that. It sounds like this patch needs to be applied to earlier kernel versions -- do you agree? Maybe. The only drivers that care at this point are the emulex and qlogic drivers with native eeh support. How far back would you typically apply a patch like this? I'm submitting it for inclusion in SLES 10 11 and RHEL 5. Mike Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Performance differences with IRQ_ALL_CPUS
On Apr 21, 2009, at 10:56 AM, Subodh Nijsure wrote: Hi, I have board with MPC8572E (dual core PPC). I have one board running kernel with IRQ_ALL_CPUS set to Y and another with that option turned off. Kernel version #2.6.26 With IRQ_ALL_CPUS turned off ( Here interrupts all go to CPU0 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18:1394100 0 OpenPIC Edge ide0 With IRQ_ALL_CPUS turned on I see (Here interrupts go to CPU0 and CPU1 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18: 44951 54765 OpenPIC Edge ide0 I expected that with IRQ_ALL_CPUS -- interrupt sharing I would be able to get higher througput but I see things otherway around. Would someone care to enlighten me as to why when I set IRQ_ALL_CPUS disk I/O performance goes down so much? Under what circumstances should one then turn on IRQ_ALL_CPUS option on PPC platform? Regards, /Subodh This is probably because you are getting ill defined behavior on 8572. The 8572 (and any FSL MPIC) doesn't actually support having the PIC distribute interrupts to the different CPUs. Its technically illegal to set more than one destination processor. If you want to try and distribute interrupts than I suggest looking at irqbalance. I'll look at a patch to deal with IRQ_ALL_CPUS to not setup the insane HW scenario. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 10/12] Next April 21 : PPC64 randconfig [drivers/mtd/maps/sbc8240.o]
Subrata Modak wrote: This is a very old one. Doesn´t seem to go away. Reported this earlier on 14th April: http://lkml.org/lkml/2009/4/14/483, CC [M] drivers/mtd/maps/sbc8240.o drivers/mtd/maps/sbc8240.c:31:1: warning: DEBUG redefined In file included from drivers/mtd/maps/sbc8240.c:23: include/linux/mtd/mtd.h:339:1: warning: this is the location of the previous definition drivers/mtd/maps/sbc8240.c: In function ‘init_sbc8240_mtd’: drivers/mtd/maps/sbc8240.c:172: error: ‘sbc8240_mtd’ undeclared (first use in this function) drivers/mtd/maps/sbc8240.c:172: error: (Each undeclared identifier is reported only once drivers/mtd/maps/sbc8240.c:172: error: for each function it appears in.) drivers/mtd/maps/sbc8240.c: In function ‘cleanup_sbc8240_mtd’: drivers/mtd/maps/sbc8240.c:233: error: ‘sbc8240_mtd’ undeclared (first use in this function) This looks like an arch/ppc orphan. It's not enabled by any defconfig, and it doesn't look like it does anything that physmap_of can't do. I'd just remove it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas The difference seems to be in how the PCI bus gets mapped. In the working, 2.6.26 based kernel, 'lspci -v' shows this: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at cc00 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=128M] Memory at cc143100 (64-bit, non-prefetchable) [size=1] Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 22 Memory at cc12 (32-bit, non-prefetchable) [size=64K] Memory at cc13 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at cc14 (32-bit, non-prefetchable) [size=4K] Memory at cc10 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at c800 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc141000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc142000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI]) Subsystem: Philips Semiconductors USB 2.0 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc143000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 This is what 2.6.28 shows: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at unassigned (64-bit, prefetchable) Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 16 Memory at c402 (32-bit, non-prefetchable) [size=64K] Memory at c403 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at c404 (32-bit, non-prefetchable) [size=4K] Memory at c400 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 22 [virtual] Memory at c000 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4041000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4042000 (32-bit, non-prefetchable) [size=4K]
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: Gary Thomas wrote: I had a stable port of 2.6.26 for my 834x hardware, with a frame buffer on a PCI device. After I upgraded to 2.6.28, this isn't working any more. The frame buffer code is happily writing to a mapped [memory] space on the PCI card, but nothing is happening. Did something [subtle] change in how the PCI is handled in this timeframe? Perhaps with how PCI devices are mapped or enabled? I've looked at the changes between the two versions, but nothing leaps out at me. n.b. I have other devices on the PCI bus, such as a SATA controller, which work the same in both versions. Thanks for any ideas The difference seems to be in how the PCI bus gets mapped. In the working, 2.6.26 based kernel, 'lspci -v' shows this: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at cc00 (32-bit, non-prefetchable) [size=1M] Memory at c000 (64-bit, prefetchable) [size=128M] Memory at cc143100 (64-bit, non-prefetchable) [size=1] Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 22 Memory at cc12 (32-bit, non-prefetchable) [size=64K] Memory at cc13 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 23 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at cc14 (32-bit, non-prefetchable) [size=4K] Memory at cc10 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 24 Memory at c800 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc141000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc142000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.2 USB Controller: Philips Semiconductors USB 2.0 Host Controller (rev 11) (prog-if 20 [EHCI]) Subsystem: Philips Semiconductors USB 2.0 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 25 Memory at cc143000 (32-bit, non-prefetchable) [size=256] Capabilities: [dc] Power Management version 2 This is what 2.6.28 shows: 00:00.0 Bridge: Unknown device 1957:0084 (rev 11) Flags: bus master, 66MHz, fast devsel, latency 0 Memory at unassigned (64-bit, prefetchable) Memory at unassigned (64-bit, non-prefetchable) Capabilities: [48] #06 [] 00:0a.0 Network controller: Unknown device 001c:0001 (rev 02) Subsystem: Unknown device 001c:0004 Flags: medium devsel, IRQ 16 Memory at c402 (32-bit, non-prefetchable) [size=64K] Memory at c403 (32-bit, non-prefetchable) [size=64K] 00:0b.0 Mass storage controller: Promise Technology, Inc. PDC40775 (SATA 300 TX2plus) (rev 02) Subsystem: Promise Technology, Inc. Unknown device 3573 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 21 I/O ports at 1000 [size=128] I/O ports at 1100 [size=256] Memory at c404 (32-bit, non-prefetchable) [size=4K] Memory at c400 (32-bit, non-prefetchable) [size=128K] Capabilities: [60] Power Management version 2 00:0c.0 Display controller: Fujitsu Limited. Unknown device 2019 (rev 01) Flags: bus master, medium devsel, latency 0, IRQ 22 [virtual] Memory at c000 (32-bit, non-prefetchable) [size=64M] 00:0d.0 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master, medium devsel, latency 0, IRQ 23 Memory at c4041000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 00:0d.1 USB Controller: Philips Semiconductors USB 1.1 Host Controller (rev 11) (prog-if 10 [OHCI]) Subsystem: Philips Semiconductors USB 1.1 Host Controller Flags: bus master,
Re: PCI changes 2.6.26 = 2.6.28
On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsl_rio: Pass the proper device to dma mapping routines
On Apr 18, 2009, at 12:48 PM, Anton Vorontsov wrote: The driver should pass a device that specifies internal DMA ops, but currently NULL pointer is passed, therefore following bug appears during boot up: [ cut here ] Kernel BUG at c0018a7c [verbose debug info unavailable] Oops: Exception in kernel mode, sig: 5 [#1] [...] NIP [c0018a7c] fsl_rio_doorbell_init+0x34/0x60 LR [c0018a70] fsl_rio_doorbell_init+0x28/0x60 Call Trace: [ef82bda0] [c0018a70] fsl_rio_doorbell_init+0x28/0x60 (unreliable) [ef82bdc0] [c0019160] fsl_rio_setup+0x6b8/0x84c [ef82be20] [c02d28ac] fsl_of_rio_rpn_probe+0x30/0x50 [ef82be40] [c0234f20] of_platform_device_probe+0x5c/0x84 [...] ---[ end trace 561bb236c800851f ]--- This patch fixes the issue. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/sysdev/fsl_rio.c | 28 +--- 1 files changed, 17 insertions(+), 11 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD
On Apr 20, 2009, at 10:54 AM, Timur Tabi wrote: The ULI 1575 PCI quirk function for the Freescale MPC8610 HPCD was disabling the SATA INTx interrupt, even when SATA support was enabled. This was safe, because the SATA driver re-enabled it. But with commit a5bfc471 (ahci: drop intx manipulation on msi enable), the driver no longer does this, and so SATA support on the 8610 HPCD is broken. The original quirk function disabled INTx because it caused some other interrupt problem during early development on this board, but no one remembers any more what that problem was, and it doesn't seem to occur any more. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/platforms/fsl_uli1575.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote: On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. About what I gleaned from lspci. The working 2.6.26 kernel has space mapped in the controller (exposed memory window, I think) and the video card got moved down accordingly. -- 2.6.26 c000-cfff : /p...@ff008500 c000-c7ff : :00:00.0 c800-cbff : :00:0c.0 c800-cbff : CoralP_fb cc00-cc0f : :00:00.0 cc10-cc11 : :00:0b.0 cc12-cc12 : :00:0a.0 cc13-cc13 : :00:0a.0 cc14-cc140fff : :00:0b.0 cc14-cc140fff : sata_promise cc141000-cc141fff : :00:0d.0 cc141000-cc141fff : ohci_hcd cc142000-cc142fff : :00:0d.1 cc142000-cc142fff : ohci_hcd cc143000-cc1430ff : :00:0d.2 cc143000-cc1430ff : ehci_hcd cc143100-cc143100 : :00:00.0 f000-f1ff : f000.flash ff000200-ff0002ff : wdt ff003000-ff0030ff : i2c ff003100-ff0031ff : i2c ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet -- 2.6.28 c000-cfff : /p...@ff008500 c000-c3ff : :00:0c.0 c000-c3ff : CoralP_fb c400-c401 : :00:0b.0 c402-c402 : :00:0a.0 c403-c403 : :00:0a.0 c404-c4040fff : :00:0b.0 c404-c4040fff : sata_promise c4041000-c4041fff : :00:0d.0 c4041000-c4041fff : ohci_hcd c4042000-c4042fff : :00:0d.1 c4042000-c4042fff : ohci_hcd c4043000-c40430ff : :00:0d.2 c4043000-c40430ff : ehci_hcd f000-f1ff : f000.flash ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn
On Apr 20, 2009, at 11:26 AM, Becky Bruce wrote: The new dts places most of the devices in physical address space above 32-bits, which allows us to have more than 4GB of RAM present. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597 +++ + 1 files changed, 597 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts applied to next. We can deal with any simple-bus issues in a follow up patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc/85xx: Add P2020DS board support
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters ted.pet...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/boot/dts/p2020ds.dts| 668 ++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 35 ++-
arch/powerpc/platforms/fsl_uli1575.c |1 +
arch/powerpc/sysdev/fsl_pci.c|2 +
include/linux/pci_ids.h |2 +
5 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds.dts
diff --git a/arch/powerpc/boot/dts/p2020ds.dts
b/arch/powerpc/boot/dts/p2020ds.dts
new file mode 100644
index 000..8c564a4
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -0,0 +1,668 @@
+/*
+ * P2020 DS Device Tree Source
+ *
+ * Copyright 2007-2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020DS;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ pci2 = pci2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ ranges = 0x0 0x0 0x0 0xe800 0x0800
+ 0x1 0x0 0x0 0xe000 0x0800
+ 0x2 0x0 0x0 0xffa0 0x0004
+ 0x3 0x0 0x0 0xffdf 0x8000
+ 0x4 0x0 0x0 0xffa4 0x0004
+ 0x5 0x0 0x0 0xffa8 0x0004
+ 0x6 0x0 0x0 0xffac 0x0004;
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x800;
+ bank-width = 2;
+ device-width = 1;
+
+ ramd...@0 {
+ reg = 0x0 0x0300;
+ read-only;
+ };
+
+ diagnos...@300 {
+ reg = 0x0300 0x00e0;
+ read-only;
+ };
+
+ d...@3e0 {
+ reg = 0x03e0 0x0020;
+ read-only;
+ };
+
+ ker...@400 {
+ reg = 0x0400 0x0040;
+ read-only;
+ };
+
+ jf...@440 {
+ reg = 0x0440 0x03b0;
+ };
+
+ d...@7f0 {
+ reg = 0x07f0 0x0008;
+ read-only;
+ };
+
+ u-b...@7f8 {
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ n...@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elbc-fcm-nand;
+ reg = 0x2 0x0 0x4;
+
+ u-b...@0 {
+ reg = 0x0 0x0200;
+ read-only;
+ };
+
+ jf...@200 {
Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Apr 21, 2009, at 2:03 PM, David Brownell wrote: On Tuesday 21 April 2009, Subrata Modak wrote: Observing this for the first time: CC drivers/usb/host/ohci-hcd.o In file included from drivers/usb/host/ohci-hcd.c:1060: drivers/usb/host/ohci-ppc-of.c:242:2: error: #error No endianess Hmm, scripts/get_maintainer.pl doesn't report the PPC folk who maintain that file and its kbuild infrastructure. Can we have some PPC folk look at (and fix) this? The problem is in the drivers/usb/host/Kconfig: config USB_OHCI_HCD_PPC_OF_BE bool Support big endian HC depends on USB_OHCI_HCD_PPC_OF default y select USB_OHCI_BIG_ENDIAN_DESC select USB_OHCI_BIG_ENDIAN_MMIO config USB_OHCI_HCD_PPC_OF_LE bool Support little endian HC depends on USB_OHCI_HCD_PPC_OF default n select USB_OHCI_LITTLE_ENDIAN Since its feasible to say 'n' to both we get the compile error. How do we enforce having at least one set? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'merge' branch for 2.6.30
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updates:
arch/powerpc/configs/85xx/mpc8536_ds_defconfig | 1802
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 1802
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 1309 -
arch/powerpc/configs/85xx/mpc8572_ds_defconfig | 1794
arch/powerpc/configs/mpc85xx_defconfig | 252 +--
arch/powerpc/configs/mpc85xx_smp_defconfig | 1829 +
arch/powerpc/platforms/fsl_uli1575.c |5
arch/powerpc/sysdev/fsl_rio.c | 28
8 files changed, 1959 insertions(+), 6862 deletions(-)
Anton Vorontsov (1):
fsl_rio: Pass the proper device to dma mapping routines
Kumar Gala (4):
powerpc/85xx: Updated generic mpc85xx_defconfig
powerpc/85xx: Enabled a bunch of FSL specific drivers/options
powerpc/85xx: Added SMP defconfig
powerpc/85xx: Remove defconfigs that mpc85xx_{smp_}defconfig cover
Timur Tabi (1):
powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
If the firmware missed to initialize the PHY correctly,
Linux may hang up on socrates while eth0/eth1 interface
startup (caused by continuous unacknowledged PHY interrupt).
This patch adds PHY fixup to socrates platform code to
ensure the PHY is pre-initialized correctly. It is needed
to be compatible with older firmware.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
use macros instead of register numbers as
suggested by Anton
Kumar, could you please consider this patch for
inclusion into 2.6.30? Thanks!
Sorry. I dont think this is board specific and should at a minimum be
done in m88e1011_config_init in drivers/net/phy/marvell.c. Not sure
how 88E1011 differs from 88E, but I'm wondering if you really want
to set config_init for m88e1011 to m88e_config_init
- k
arch/powerpc/platforms/85xx/socrates.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/socrates.c b/arch/powerpc/
platforms/85xx/socrates.c
index d0e8443..bde0a97 100644
--- a/arch/powerpc/platforms/85xx/socrates.c
+++ b/arch/powerpc/platforms/85xx/socrates.c
@@ -28,6 +28,7 @@
#include linux/delay.h
#include linux/seq_file.h
#include linux/of_platform.h
+#include linux/phy.h
#include asm/system.h
#include asm/time.h
@@ -78,6 +79,23 @@ static void __init socrates_pic_init(void)
of_node_put(np);
}
+#define MII_M1011_IMASK0x12
+#define MII_M1011_IEVENT 0x13
+static int socrates_m88e1121_fixup(struct phy_device *phydev)
+{
+ int err;
+
+ err = phy_write(phydev, MII_M1011_IMASK, 0);
+ if (err 0)
+ return err;
+
+ err = phy_read(phydev, MII_M1011_IEVENT);
+ if (err 0)
+ return err;
+
+ return 0;
+}
+
/*
* Setup the architecture
*/
@@ -105,6 +123,8 @@ static struct of_device_id __initdata
socrates_of_bus_ids[] = {
static void __init socrates_init(void)
{
of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
+ phy_register_fixup_for_uid(0x1410cb0, 0xff0,
+ socrates_m88e1121_fixup);
}
/*
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Performance differences with IRQ_ALL_CPUS
From: Kumar Gala Sent: Tuesday, April 21, 2009 1:02 PM On Apr 21, 2009, at 10:56 AM, Subodh Nijsure wrote: Hi, I have board with MPC8572E (dual core PPC). I have one board running kernel with IRQ_ALL_CPUS set to Y and another with that option turned off. Kernel version #2.6.26 With IRQ_ALL_CPUS turned off ( Here interrupts all go to CPU0 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18:1394100 0 OpenPIC Edge ide0 With IRQ_ALL_CPUS turned on I see (Here interrupts go to CPU0 and CPU1 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18: 44951 54765 OpenPIC Edge ide0 I expected that with IRQ_ALL_CPUS -- interrupt sharing I would be able to get higher througput but I see things otherway around. Would someone care to enlighten me as to why when I set IRQ_ALL_CPUS disk I/O performance goes down so much? Under what circumstances should one then turn on IRQ_ALL_CPUS option on PPC platform? Regards, /Subodh This is probably because you are getting ill defined behavior on 8572. The 8572 (and any FSL MPIC) doesn't actually support having the PIC distribute interrupts to the different CPUs. Its technically illegal to set more than one destination processor. If you want to try and distribute interrupts than I suggest looking at irqbalance. Kumar, thanks for the info. Okay I will research irqbalance (from http://irqbalance.org/?) and see how that goes. If I want to lock say ethernet interrupts to (core0) CPU0 and Ide interrupts to (core1) CPU1 is there a way to fix that using device-tree specification? I will look through the MPC8572 programmer's manual and see if there is such a thing in processor itself. /Subodh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote: On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote: If the firmware missed to initialize the PHY correctly, Linux may hang up on socrates while eth0/eth1 interface startup (caused by continuous unacknowledged PHY interrupt). This patch adds PHY fixup to socrates platform code to ensure the PHY is pre-initialized correctly. It is needed to be compatible with older firmware. Signed-off-by: Anatolij Gustschin ag...@denx.de --- Changes since first version: use macros instead of register numbers as suggested by Anton Kumar, could you please consider this patch for inclusion into 2.6.30? Thanks! Sorry. I dont think this is board specific and should at a minimum be done in m88e1011_config_init in drivers/net/phy/marvell.c. Not sure how 88E1011 differs from 88E, but I'm wondering if you really want to set config_init for m88e1011 to m88e_config_init - k I got confused by the #'s.. I think we should have a struct in marvell.c for m88e1121 which I'm guessing is the PHY you are using. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Performance differences with IRQ_ALL_CPUS
On Apr 21, 2009, at 5:01 PM, Subodh Nijsure wrote: From: Kumar Gala Sent: Tuesday, April 21, 2009 1:02 PM On Apr 21, 2009, at 10:56 AM, Subodh Nijsure wrote: Hi, I have board with MPC8572E (dual core PPC). I have one board running kernel with IRQ_ALL_CPUS set to Y and another with that option turned off. Kernel version #2.6.26 With IRQ_ALL_CPUS turned off ( Here interrupts all go to CPU0 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 3048 MB in 2.00 seconds = 1523.79 MB/sec Timing buffered disk reads: 10 MB in 3.07 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18:1394100 0 OpenPIC Edge ide0 With IRQ_ALL_CPUS turned on I see (Here interrupts go to CPU0 and CPU1 ) hdparm -tT /dev/hda /dev/hda: Timing cached reads: 1076 MB in 2.00 seconds = 538.01 MB/sec Timing buffered disk reads: 10 MB in 3.08 seconds = 3.25 MB/sec cat /proc/interrupts CPU0 CPU1 18: 44951 54765 OpenPIC Edge ide0 I expected that with IRQ_ALL_CPUS -- interrupt sharing I would be able to get higher througput but I see things otherway around. Would someone care to enlighten me as to why when I set IRQ_ALL_CPUS disk I/O performance goes down so much? Under what circumstances should one then turn on IRQ_ALL_CPUS option on PPC platform? Regards, /Subodh This is probably because you are getting ill defined behavior on 8572. The 8572 (and any FSL MPIC) doesn't actually support having the PIC distribute interrupts to the different CPUs. Its technically illegal to set more than one destination processor. If you want to try and distribute interrupts than I suggest looking at irqbalance. Kumar, thanks for the info. Okay I will research irqbalance (from http://irqbalance.org/?) and see how that goes. If I want to lock say ethernet interrupts to (core0) CPU0 and Ide interrupts to (core1) CPU1 is there a way to fix that using device-tree specification? No. We've actively avoided trying to convene such affinity in the device tree. However you can do: cat 1 /proc/irq/ENET_IRQ_NUM/affinity cat 2 /proc/irq/IDE_IRQ/affinity at boot time. This will get you affinity binding to a core. The affinity file is bitmask related to core # (with lsb being core0 and msb being core31) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Gary Thomas wrote: Kumar Gala wrote: On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. About what I gleaned from lspci. The working 2.6.26 kernel has space mapped in the controller (exposed memory window, I think) and the video card got moved down accordingly. -- 2.6.26 c000-cfff : /p...@ff008500 c000-c7ff : :00:00.0 c800-cbff : :00:0c.0 c800-cbff : CoralP_fb cc00-cc0f : :00:00.0 cc10-cc11 : :00:0b.0 cc12-cc12 : :00:0a.0 cc13-cc13 : :00:0a.0 cc14-cc140fff : :00:0b.0 cc14-cc140fff : sata_promise cc141000-cc141fff : :00:0d.0 cc141000-cc141fff : ohci_hcd cc142000-cc142fff : :00:0d.1 cc142000-cc142fff : ohci_hcd cc143000-cc1430ff : :00:0d.2 cc143000-cc1430ff : ehci_hcd cc143100-cc143100 : :00:00.0 f000-f1ff : f000.flash ff000200-ff0002ff : wdt ff003000-ff0030ff : i2c ff003100-ff0031ff : i2c ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet -- 2.6.28 c000-cfff : /p...@ff008500 c000-c3ff : :00:0c.0 c000-c3ff : CoralP_fb c400-c401 : :00:0b.0 c402-c402 : :00:0a.0 c403-c403 : :00:0a.0 c404-c4040fff : :00:0b.0 c404-c4040fff : sata_promise c4041000-c4041fff : :00:0d.0 c4041000-c4041fff : ohci_hcd c4042000-c4042fff : :00:0d.1 c4042000-c4042fff : ohci_hcd c4043000-c40430ff : :00:0d.2 c4043000-c40430ff : ehci_hcd f000-f1ff : f000.flash ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) It most definitely has something to do with 0xC000 being assigned to the video card. I changed my DTS to move everything up (started the whole space at 0xC400) and the video card came to life! Of course, I'm not interested in this hack, so the simplest thing would be to figure out why 2.6.26 allocated that outgoing window and 2.6.28 doesn't -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
On Apr 21, 2009, at 5:22 PM, Gary Thomas wrote: Gary Thomas wrote: Kumar Gala wrote: On Apr 21, 2009, at 3:30 PM, Gary Thomas wrote: The [two] big differences I see are that the video card (00:0d.0) is being assigned 0xC000, which lspci marks as virtual. I think I've had trouble in the past with memory regions which started at 0 relative to the PCI space. Also virtual concerns me. Does this spark any ideas from anyone? Doesn't ring any bells. What does cat /proc/iomem look like between the two kernels. About what I gleaned from lspci. The working 2.6.26 kernel has space mapped in the controller (exposed memory window, I think) and the video card got moved down accordingly. -- 2.6.26 c000-cfff : /p...@ff008500 c000-c7ff : :00:00.0 c800-cbff : :00:0c.0 c800-cbff : CoralP_fb cc00-cc0f : :00:00.0 cc10-cc11 : :00:0b.0 cc12-cc12 : :00:0a.0 cc13-cc13 : :00:0a.0 cc14-cc140fff : :00:0b.0 cc14-cc140fff : sata_promise cc141000-cc141fff : :00:0d.0 cc141000-cc141fff : ohci_hcd cc142000-cc142fff : :00:0d.1 cc142000-cc142fff : ohci_hcd cc143000-cc1430ff : :00:0d.2 cc143000-cc1430ff : ehci_hcd cc143100-cc143100 : :00:00.0 f000-f1ff : f000.flash ff000200-ff0002ff : wdt ff003000-ff0030ff : i2c ff003100-ff0031ff : i2c ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet -- 2.6.28 c000-cfff : /p...@ff008500 c000-c3ff : :00:0c.0 c000-c3ff : CoralP_fb c400-c401 : :00:0b.0 c402-c402 : :00:0a.0 c403-c403 : :00:0a.0 c404-c4040fff : :00:0b.0 c404-c4040fff : sata_promise c4041000-c4041fff : :00:0d.0 c4041000-c4041fff : ohci_hcd c4042000-c4042fff : :00:0d.1 c4042000-c4042fff : ohci_hcd c4043000-c40430ff : :00:0d.2 c4043000-c40430ff : ehci_hcd f000-f1ff : f000.flash ff004500-ff004507 : serial ff004600-ff004607 : serial ff022000-ff022fff : usb ff022000-ff022fff : ehci_hcd ff023000-ff023fff : usb ff023000-ff023fff : usb ff023000-ff023fff : ehci_hcd ff024000-ff024fff : ethernet ff024520-ff02453f : mdio ff025000-ff025fff : ethernet I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) It most definitely has something to do with 0xC000 being assigned to the video card. I changed my DTS to move everything up (started the whole space at 0xC400) and the video card came to life! Of course, I'm not interested in this hack, so the simplest thing would be to figure out why 2.6.26 allocated that outgoing window and 2.6.28 doesn't So I think the difference is due to the change in PCI code between 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in . 26 you have: c000-c7ff : :00:00.0 and in .28 its gone. This accounts for the allocation differences. What I don't get is why the behavior would vary based on address. Can you dump out the PCI inbound/outbound registers. I have a theory as to what's going on and want to confirm it. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
Kumar Gala wrote: On Apr 21, 2009, at 2:03 PM, David Brownell wrote: On Tuesday 21 April 2009, Subrata Modak wrote: Observing this for the first time: CC drivers/usb/host/ohci-hcd.o In file included from drivers/usb/host/ohci-hcd.c:1060: drivers/usb/host/ohci-ppc-of.c:242:2: error: #error No endianess Hmm, scripts/get_maintainer.pl doesn't report the PPC folk who maintain that file and its kbuild infrastructure. Can we have some PPC folk look at (and fix) this? The problem is in the drivers/usb/host/Kconfig: config USB_OHCI_HCD_PPC_OF_BE bool Support big endian HC depends on USB_OHCI_HCD_PPC_OF default y select USB_OHCI_BIG_ENDIAN_DESC select USB_OHCI_BIG_ENDIAN_MMIO config USB_OHCI_HCD_PPC_OF_LE bool Support little endian HC depends on USB_OHCI_HCD_PPC_OF default n select USB_OHCI_LITTLE_ENDIAN Since its feasible to say 'n' to both we get the compile error. How do we enforce having at least one set? Looks like using choice without optional would do it. See Documentation/kbuild/kconfig-language.txt and various examples in Kconfig* files. -- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
I'm still looking into how the PCI address register for the video card did not get written, even though the system obviously thinks it did (hence virtual) It most definitely has something to do with 0xC000 being assigned to the video card. I changed my DTS to move everything up (started the whole space at 0xC400) and the video card came to life! Of course, I'm not interested in this hack, so the simplest thing would be to figure out why 2.6.26 allocated that outgoing window and 2.6.28 doesn't So I think the difference is due to the change in PCI code between 2.6.26 and .28 for 83xx. If you notice we exclude the FSL device in .26 you have: c000-c7ff : :00:00.0 and in .28 its gone. This accounts for the allocation differences. What I don't get is why the behavior would vary based on address. Can you dump out the PCI inbound/outbound registers. I have a theory as to what's going on and want to confirm it. Also, what's your .dts look like for the PCI node. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: 85xx: Add PHY fixup to socrates board code
Kumar Gala wrote:
On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote:
On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
If the firmware missed to initialize the PHY correctly,
Linux may hang up on socrates while eth0/eth1 interface
startup (caused by continuous unacknowledged PHY interrupt).
This patch adds PHY fixup to socrates platform code to
ensure the PHY is pre-initialized correctly. It is needed
to be compatible with older firmware.
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Changes since first version:
use macros instead of register numbers as
suggested by Anton
Kumar, could you please consider this patch for
inclusion into 2.6.30? Thanks!
Sorry. I dont think this is board specific and should at a minimum be
done in m88e1011_config_init in drivers/net/phy/marvell.c. Not sure
how 88E1011 differs from 88E, but I'm wondering if you really want
to set config_init for m88e1011 to m88e_config_init
- k
I got confused by the #'s.. I think we should have a struct in marvell.c
for m88e1121 which I'm guessing is the PHY you are using.
yes, m88e1121 is correct. In 2.6.30-rc2 there is already a m88e1121
struct in marvell_drivers[] in drivers/net/phy/marvell.c.
The reason I'm not doing the m88e1121 pre-init stuff in config_init
is as follows:
m88e1121 is a multi-PHY device with two PHY ports and each port
could signal an interrupt. This PHY device can be pin-strapped to use
shared interrupt pin for both PHY ports (as used on socrates board).
PHY specific config_init will be called e.g. while eth0 startup in
phy_attach() which is called from phy_connect() in drivers/net/phy/phy_device.c.
phy_connect() then calls phy_start_interrupts() which registers the
interrupt handler and enables the interrupts for the PHY-port config_init
is called for. Now interrupts can be cleared/acknowledged for this
PHY-port (eth0 interface), but interrupts from the another PHY-port
can not be acknowledged as eth1 was not brought up yet.
Placing this fixup in drivers/net/phy/marvell.c as in config_init callback
could be done, but this will add more overhead as the fixup routine have
to do more work:
acquire 'struct mii_bus' pointer and walk through all registered PHYs
searching for the PHY which use the same interrupt, then getting
the address of this PHY on the bus and disable and clear PHY irqs
by writing/reading to/from this PHY, (but only in the case it was
not already brought up and has interrupts enabled!) e.g.:
struct mii_bus *bus = phydev-bus;
int addr;
for (addr = 0; addr PHY_MAX_ADDR; addr++) {
struct phy_device *phy = bus-phy_map[addr];
if (addr != phydev-addr bus-irq[addr] == phydev-irq
(phy-phy_id 0x0ff0) == 0x01410cb0
!(phy-interrupts PHY_INTERRUPT_ENABLED)) {
int imask = phy_read(phy, MII_M1011_IMASK);
if (imask) {
phy_write(phy, 0x12, 0); /* disable */
phy_read(phy, 0x13); /* clear */
}
}
}
All this to allow support for multiple m88e1121 devices.
Otherwise, after registering first phy interrupt handler
and enabling interrupt pending irq on other PHY port or
other PHY device will lock up the board.
The fixup in this patch will only be done while mdio bus scan
before registering a PHY device.
Anatolij
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote: I found the difference - in 2.6.28 the inbound/outbound windows don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge' was common among architectures and ended up calling 'setup_pci_atmu' which created those mappings. In 2.6.28, the 83xx PCI setup code has been refactored. It uses 'mpc83xx_add_bridge' instead of 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-( I'm sure this is the problem. Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code calling setup_pci_atmu(). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI changes 2.6.26 = 2.6.28
Kumar Gala wrote: On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote: I found the difference - in 2.6.28 the inbound/outbound windows don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge' was common among architectures and ended up calling 'setup_pci_atmu' which created those mappings. In 2.6.28, the 83xx PCI setup code has been refactored. It uses 'mpc83xx_add_bridge' instead of 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-( I'm sure this is the problem. Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code calling setup_pci_atmu(). It did not directly; it called 'fsl_add_bridge' which in turn called 'setup_pci_atmu' I modified the 2.6.28 driver to also call this function. Now the inbound/outbound windows are set up, but the bridge still has no allocations, so the problem remains. I need to move on; I may just live with sliding the PCI space up for now (doesn't really hurt anything, just seems like a hack) -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/85xx: Add P2020DS board support
On Tue, 21 Apr 2009 16:19:22 -0500
Kumar Gala ga...@kernel.crashing.org wrote:
+ cry...@3 {
+ compatible = fsl,sec3.0, fsl,sec2.4, fsl,sec2.2,
+ fsl,sec2.1, fsl,sec2.0;
should be:
compatible = fsl,sec3.1, fsl,sec3.0, fsl,sec2.4,
fsl,sec2.2, fsl,sec2.1, fsl,sec2.0;
+ fsl,exec-units-mask = 0x9fe;
and:
fsl,exec-units-mask = 0xbfe;
to include the SNOW unit.
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 09/12] Next April 21 : PPC64 randconfig [drivers/staging/comedi/drivers.o]
On Wed, 2009-04-22 at 00:23 +0530, Subrata Modak wrote: Reported this error on 14th April: http://lkml.org/lkml/2009/4/14/488, CC [M] drivers/staging/comedi/drivers.o drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’: drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’ undeclared (first use in this function) drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier is reported only once drivers/staging/comedi/drivers.c:496: error: for each function it appears in.) make[3]: *** [drivers/staging/comedi/drivers.o] Error 1 make[2]: *** [drivers/staging/comedi] Error 2 make[1]: *** [drivers/staging] Error 2 make: *** [drivers] Error 2 Subrata, unless someone says otherwise, please do not send randconfig failures for drivers in staging - those drivers have bigger problems than randconfig failures. To avoid them, do this: # make randconfig # sed -i -e 's/^\(CONFIG_STAGING\)=y/# \1 is not set/' .config # make oldconfig cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] powerpc: Add 36-bit device tree for mpc8641hpcn
On Tue, Apr 21, 2009 at 10:33:34AM -0500, Becky Bruce wrote:
On Apr 20, 2009, at 8:10 PM, David Gibson wrote:
On Mon, Apr 20, 2009 at 11:26:47AM -0500, Becky Bruce wrote:
The new dts places most of the devices in physical address space
above 32-bits, which allows us to have more than 4GB of RAM present.
Signed-off-by: Becky Bruce bec...@kernel.crashing.org
---
arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts | 597 ++
++
1 files changed, 597 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts b/arch/
powerpc/boot/dts/mpc8641_hpcn_36b.dts
new file mode 100644
index 000..baa3dba
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn_36b.dts
@@ -0,0 +1,597 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
[snip]
+ soc8...@fffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
Uh, you definitely need something more specific in the compatible
property before simple-bus.
This is a copy of the existing mpc8641hpcn dts file, with just physical
address changes, so if there's a problem here it definitely exists in the
current 8641hpcn dts, and possibly other dts files as well. I think the
correct solution is for me to go look at that .dts (and any others that
may be similar), and put out a followup to fix them all.
Ok, fair enough.
--
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 v2] powerpc/85xx: Add P2020DS board support
On Tue, Apr 21, 2009 at 04:19:22PM -0500, Kumar Gala wrote:
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe
controllers.
[snip]
+ s...@ffe0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
If I understood the description correctly, this one doesn't have the
excuse of being a copy of an already broken device tree. There needs
to be a soc-variant specific string in the compatible property here.
--
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: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
On Tuesday 21 April 2009, Randy Dunlap wrote: Since its feasible to say 'n' to both we get the compile error. How do we enforce having at least one set? Looks like using choice without optional would do it. See Documentation/kbuild/kconfig-language.txt and various examples in Kconfig* files. That won't quite work ... at least one includes two (i.e. a PCI card in little-endian, a native controller in big-endian). Real-world systems need such configs, or so I'm told, and that's why their supported. Is there maybe a way to force Kconfig to just reject such illegal configs -- neither option set -- rather than trying some how to fix it? Or maybe ... if neither one is set, have the header force both on, and issue a warning. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
David Brownell wrote: On Tuesday 21 April 2009, Randy Dunlap wrote: Since its feasible to say 'n' to both we get the compile error. How do we enforce having at least one set? Looks like using choice without optional would do it. See Documentation/kbuild/kconfig-language.txt and various examples in Kconfig* files. That won't quite work ... at least one includes two (i.e. a PCI card in little-endian, a native controller in big-endian). Real-world systems need such configs, or so I'm told, and that's why their supported. Yes, I see. Is there maybe a way to force Kconfig to just reject such illegal configs -- neither option set -- rather than trying some how to fix it? Not that I know of. cc-ing Sam. Or maybe ... if neither one is set, have the header force both on, and issue a warning. That should be doable. We'd prefer to catch it via Kconfig, but that doesn't look promising just now. -- ~Randy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v3] powerpc/85xx: Add P2020DS board support
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters ted.pet...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fixed soc node compat to have p2020-immr
* Fixed up SEC node per Kim's comments
- k
arch/powerpc/boot/dts/p2020ds.dts| 668 ++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 35 ++-
arch/powerpc/platforms/fsl_uli1575.c |1 +
arch/powerpc/sysdev/fsl_pci.c|2 +
include/linux/pci_ids.h |2 +
5 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds.dts
diff --git a/arch/powerpc/boot/dts/p2020ds.dts
b/arch/powerpc/boot/dts/p2020ds.dts
new file mode 100644
index 000..ea46f7a
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -0,0 +1,668 @@
+/*
+ * P2020 DS Device Tree Source
+ *
+ * Copyright 2007-2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020DS;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ pci2 = pci2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ ranges = 0x0 0x0 0x0 0xe800 0x0800
+ 0x1 0x0 0x0 0xe000 0x0800
+ 0x2 0x0 0x0 0xffa0 0x0004
+ 0x3 0x0 0x0 0xffdf 0x8000
+ 0x4 0x0 0x0 0xffa4 0x0004
+ 0x5 0x0 0x0 0xffa8 0x0004
+ 0x6 0x0 0x0 0xffac 0x0004;
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x800;
+ bank-width = 2;
+ device-width = 1;
+
+ ramd...@0 {
+ reg = 0x0 0x0300;
+ read-only;
+ };
+
+ diagnos...@300 {
+ reg = 0x0300 0x00e0;
+ read-only;
+ };
+
+ d...@3e0 {
+ reg = 0x03e0 0x0020;
+ read-only;
+ };
+
+ ker...@400 {
+ reg = 0x0400 0x0040;
+ read-only;
+ };
+
+ jf...@440 {
+ reg = 0x0440 0x03b0;
+ };
+
+ d...@7f0 {
+ reg = 0x07f0 0x0008;
+ read-only;
+ };
+
+ u-b...@7f8 {
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ n...@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elbc-fcm-nand;
+ reg = 0x2 0x0 0x4;
+
+ u-b...@0 {
+ reg = 0x0 0x0200;
+
Re: PCI changes 2.6.26 = 2.6.28
On Apr 21, 2009, at 6:45 PM, Gary Thomas wrote: Kumar Gala wrote: On Apr 21, 2009, at 6:00 PM, Gary Thomas wrote: I found the difference - in 2.6.28 the inbound/outbound windows don't seem to be set up at all. In 2.6.26, the function 'fsl_add_bridge' was common among architectures and ended up calling 'setup_pci_atmu' which created those mappings. In 2.6.28, the 83xx PCI setup code has been refactored. It uses 'mpc83xx_add_bridge' instead of 'fsl_add_bridge' and 'setup_pci_atmu' is not called at all :-( I'm sure this is the problem. Looking at a diff between 2.6.26 and .28 I don't see the 83xx pci code calling setup_pci_atmu(). It did not directly; it called 'fsl_add_bridge' which in turn called 'setup_pci_atmu' Don't ever see 83xx boards calling fsl_add_bridge -- that is 85xx/86xx only in 83xx. I modified the 2.6.28 driver to also call this function. Now the inbound/outbound windows are set up, but the bridge still has no allocations, so the problem remains. I need to move on; I may just live with sliding the PCI space up for now (doesn't really hurt anything, just seems like a hack) It is and you are glossing over a real bug. Are you using u-boot to boot? If so is the board port public? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
Bartlomiej Zolnierkiewicz writes: mediabay shouldn't include linux/ide.h unconditionally so remove the superfluous include from mediabay.c (asm/mediabay.h will pull linux/ide.h in for CONFIG_BLK_DEV_IDE_PMAC=y). I don't like relying on second-hand imports like that. I prefer the previous patch, that made mediabay depend on CONFIG_BLOCK. BTW, if including linux/ide.h causes an error when CONFIG_BLOCK=n, then there is a bug in linux/ide.h, IMO. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v3] powerpc/85xx: Add P2020DS board support
+ L2: l2-cache-control...@2 {
+ compatible = fsl,p2020-l2-cache-controller;
+ reg = 0x2 0x1000;
+ cache-line-size = 32; // 32 bytes
+ cache-size = 0x10; // L2, 1M
+ interrupt-parent = mpic;
+ interrupts = 16 2;
+ };
One nit --here should be 512KB L2 cache
+ u...@22000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = fsl-usb2-mph;
+ reg = 0x22000 0x1000;
+ interrupt-parent = mpic;
+ interrupts = 28 0x2;
+ phy_type = ulpi;
+ };
It should be fsl-usb2-dr
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] powerpc/85xx: Add P2020DS board support
The P2020 is a dual e500v2 core based SOC with:
* 3 PCIe controllers
* 2 General purpose DMA controllers
* 2 sRIO controllers
* 3 eTSECS
* USB 2.0
* SDHC
* SPI, I2C, DUART
* enhanced localbus
* and optional Security (P2020E) security w/XOR acceleration
The p2020 DS reference board is pretty similar to the existing MPC85xx
DS boards and has a ULI 1575 connected on one of the PCIe controllers.
Signed-off-by: Ted Peters ted.pet...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
* Fixed copyright
* fixed l2-cache size
* Fixed usb compat prop
- k
arch/powerpc/boot/dts/p2020ds.dts| 668 ++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 35 ++-
arch/powerpc/platforms/fsl_uli1575.c |1 +
arch/powerpc/sysdev/fsl_pci.c|2 +
include/linux/pci_ids.h |2 +
5 files changed, 707 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/p2020ds.dts
diff --git a/arch/powerpc/boot/dts/p2020ds.dts
b/arch/powerpc/boot/dts/p2020ds.dts
new file mode 100644
index 000..66acb19
--- /dev/null
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -0,0 +1,668 @@
+/*
+ * P2020 DS Device Tree Source
+ *
+ * Copyright 2009 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = fsl,P2020;
+ compatible = fsl,P2020DS;
+ #address-cells = 2;
+ #size-cells = 2;
+
+ aliases {
+ ethernet0 = enet0;
+ ethernet1 = enet1;
+ ethernet2 = enet2;
+ serial0 = serial0;
+ serial1 = serial1;
+ pci0 = pci0;
+ pci1 = pci1;
+ pci2 = pci2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,p2...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ next-level-cache = L2;
+ };
+
+ PowerPC,p2...@1 {
+ device_type = cpu;
+ reg = 0x1;
+ next-level-cache = L2;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ };
+
+ local...@ffe05000 {
+ #address-cells = 2;
+ #size-cells = 1;
+ compatible = fsl,elbc, simple-bus;
+ reg = 0 0xffe05000 0 0x1000;
+ interrupts = 19 2;
+ interrupt-parent = mpic;
+
+ ranges = 0x0 0x0 0x0 0xe800 0x0800
+ 0x1 0x0 0x0 0xe000 0x0800
+ 0x2 0x0 0x0 0xffa0 0x0004
+ 0x3 0x0 0x0 0xffdf 0x8000
+ 0x4 0x0 0x0 0xffa4 0x0004
+ 0x5 0x0 0x0 0xffa8 0x0004
+ 0x6 0x0 0x0 0xffac 0x0004;
+
+ n...@0,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = cfi-flash;
+ reg = 0x0 0x0 0x800;
+ bank-width = 2;
+ device-width = 1;
+
+ ramd...@0 {
+ reg = 0x0 0x0300;
+ read-only;
+ };
+
+ diagnos...@300 {
+ reg = 0x0300 0x00e0;
+ read-only;
+ };
+
+ d...@3e0 {
+ reg = 0x03e0 0x0020;
+ read-only;
+ };
+
+ ker...@400 {
+ reg = 0x0400 0x0040;
+ read-only;
+ };
+
+ jf...@440 {
+ reg = 0x0440 0x03b0;
+ };
+
+ d...@7f0 {
+ reg = 0x07f0 0x0008;
+ read-only;
+ };
+
+ u-b...@7f8 {
+ reg = 0x07f8 0x0008;
+ read-only;
+ };
+ };
+
+ n...@2,0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elbc-fcm-nand;
+ reg = 0x2 0x0 0x4;
+
+ u-b...@0 {
+ reg = 0x0 0x0200;
+ read-only;
+
