RE: Re: mpc5200b configure nand driver via dts
On Mon, Jan 12, 2009 at 2:07 AM, florian.bel...@freenet.de
wrote:
hello,
I have some problems with an mpc5200b based board. It's nearly
compatible to
the lite5200b board.
I connected an samsung k9k8g08u0a nand flash via the lpb bus. This
works
fine with an self written nand driver.
Now I try to use the standard nand driver from linux and configure
it via
the dts file. But this doesn't work and I get
the following output:
n...@1,0 { //cs1
compatible = samsung, k9k8g08u08, cfi-flash;
^
NAND Flash is not a CFI flash device. The cfi-flash driver won't
work with it.
Which compatible mode whould you choose ?
Now my questions are:
Is there any error in the dts configuration?
Is it principle posible to configure a nand flash via the dts
file (in
combination with mpc5200b)?
It is possible to *describe* the NAND flash via the dts file. The
dts
file doesn't configure anything. It just describes the hardware
layout so that you can write or bind the appropriate driver to the
device. I don't know if a device tree binding has been defined for
NAND flash yet.
I find 3 MTD NAND drivers with OF bindings in
linux-2.6/drivers/mtd/nand
$ grep -l of_device *.c
fsl_elbc_nand.c
fsl_upm.c
pasemi_nand.c
The bindings for the FSL UPM are described in
http://lxr.linux.no/linux http://lxr.linux.no/linux%3C/font%3E
v2.6.28/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt.
Something similar is needed for his board (NAND connected to lpb) as
well.
Am I wrong or is the MTD_NAND_FSL_UPM only useable with PPC_83xx or
PPC_85xx?
I read in some forums that the nand flash must be activated in
the u-boot
before it can be configured via dts.
You definitely need to set up the CS line for the NAND before using
it
in Linux. Typically this is done in U-Boot, but in a pinch it can
be
done in the platform support code (arch/powerpc/platforms/52xx/*)
Yep, and also the R/B pin should be handled somehow, preferably using
the OF GPIO interface.
I set the upper named points in the u-boot, now.
+++ b/board/ybox/ybox.c
@@ -282,6 +282,32 @@ void flash_preinit(void)
* executing in flash.
*/
*(vu_long *)MPC5XXX_BOOTCS_CFG = ~0x1; /* clear RO */
+
+
+ /* Configure PSC3_6 as ChipSelect for NAND Flash chip
+set PSC3_6 pin as GPIO output */
+*(vu_long *)MPC5XXX_GPIO_ENABLE |= 0x1000; /*enable GPIO*/
+*(vu_long *)MPC5XXX_GPIO_ODE = ~0x1000; /* no OpenDrain
*/
+*(vu_long *)MPC5XXX_GPIO_DIR |= 0x1000; /* Direction =
output */
+*(vu_long *)MPC5XXX_GPIO_DATA_O |= 0x1000; /* Set CS to 1
(low active)*/
+ /* NAND config*/
+ /* Configure IRQ_0 as input for Ready/Busy pin*/
+*(vu_long *)MPC5XXX_ICTL_EXT = ~0x0800; /*disable IRQ_0
interrupt */
+*(vu_long *)MPC5XXX_ICTL_EXT |= 0x00C0; /*low active */
+ *(vu_long *)MPC5XXX_ADDECR = ~0x0002; /*disable cs1 */
+
+/* Configure the ChipSelect 1 on LocalPlusBus for data
transfers
+there is a config chip select function allready, but beter do
all for nand
+at one place */
+/*CS1 start / end address*/
+*(vu_long *)MPC5XXX_CS1_START = 0x7000;
+*(vu_long *)MPC5XXX_CS1_STOP = (0x7000 + 0x100);
+/*CS1 master enable */
+*(vu_long *)MPC5XXX_CS_CTRL = 0x01;
+*(vu_long *)MPC5XXX_CS1_CFG = 0x0f0f1800;
+ *(vu_long *)MPC5XXX_ADDECR |= ~0x0002; /*enable cs1 */
+/*enable PIN as ChipSelect*/
+*(vu_long *)MPC5XXX_GPS_PORT_CONFIG |= 0x8000;
}
Thanks for your replays
Best regards
Florian Belser
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mpc5200b configure nand driver via dts
florian.bel...@freenet.de wrote:
On Mon, Jan 12, 2009 at 2:07 AM, florian.bel...@freenet.de
wrote:
hello,
I have some problems with an mpc5200b based board. It's nearly
compatible to
the lite5200b board.
I connected an samsung k9k8g08u0a nand flash via the lpb bus. This
works
fine with an self written nand driver.
Now I try to use the standard nand driver from linux and configure
it via
the dts file. But this doesn't work and I get
the following output:
n...@1,0 { //cs1
compatible = samsung, k9k8g08u08, cfi-flash;
^
NAND Flash is not a CFI flash device. The cfi-flash driver won't
work with it.
Which compatible mode whould you choose ?
There is no mode/driver ready to use. You need to implement a MTD NAND
driver supporting the compatible fsl,lpb-nand, similar to:
http://lxr.linux.no/linux+v2.6.28/arch/powerpc/boot/dts/mpc836x_rdk.dts#L390
Now my questions are:
Is there any error in the dts configuration?
Is it principle posible to configure a nand flash via the dts
file (in
combination with mpc5200b)?
It is possible to *describe* the NAND flash via the dts file. The
dts
file doesn't configure anything. It just describes the hardware
layout so that you can write or bind the appropriate driver to the
device. I don't know if a device tree binding has been defined for
NAND flash yet.
I find 3 MTD NAND drivers with OF bindings in
linux-2.6/drivers/mtd/nand
$ grep -l of_device *.c
fsl_elbc_nand.c
fsl_upm.c
pasemi_nand.c
The bindings for the FSL UPM are described in
http://lxr.linux.no/linux
v2.6.28/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt.
Something similar is needed for his board (NAND connected to lpb) as
well.
Am I wrong or is the MTD_NAND_FSL_UPM only useable with PPC_83xx or
PPC_85xx?
That's right. The MPC5200 does *not* have an UPM.
I read in some forums that the nand flash must be activated in
the u-boot
before it can be configured via dts.
You definitely need to set up the CS line for the NAND before using
it
in Linux. Typically this is done in U-Boot, but in a pinch it can
be
done in the platform support code (arch/powerpc/platforms/52xx/*)
Yep, and also the R/B pin should be handled somehow, preferably using
the OF GPIO interface.
I set the upper named points in the u-boot, now.
+++ b/board/ybox/ybox.c
@@ -282,6 +282,32 @@ void flash_preinit(void)
* executing in flash.
*/
*(vu_long *)MPC5XXX_BOOTCS_CFG = ~0x1; /* clear RO */
+
+
+ /* Configure PSC3_6 as ChipSelect for NAND Flash chip
+set PSC3_6 pin as GPIO output */
+*(vu_long *)MPC5XXX_GPIO_ENABLE |= 0x1000; /*enable GPIO*/
+*(vu_long *)MPC5XXX_GPIO_ODE = ~0x1000; /* no OpenDrain
*/
+*(vu_long *)MPC5XXX_GPIO_DIR |= 0x1000; /* Direction =
output */
+*(vu_long *)MPC5XXX_GPIO_DATA_O |= 0x1000; /* Set CS to 1
(low active)*/
+ /* NAND config*/
+ /* Configure IRQ_0 as input for Ready/Busy pin*/
+*(vu_long *)MPC5XXX_ICTL_EXT = ~0x0800; /*disable IRQ_0
interrupt */
+*(vu_long *)MPC5XXX_ICTL_EXT |= 0x00C0; /*low active */
+ *(vu_long *)MPC5XXX_ADDECR = ~0x0002; /*disable cs1 */
+
+/* Configure the ChipSelect 1 on LocalPlusBus for data
transfers
+there is a config chip select function allready, but beter do
all for nand
+at one place */
+/*CS1 start / end address*/
+*(vu_long *)MPC5XXX_CS1_START = 0x7000;
+*(vu_long *)MPC5XXX_CS1_STOP = (0x7000 + 0x100);
+/*CS1 master enable */
+*(vu_long *)MPC5XXX_CS_CTRL = 0x01;
+*(vu_long *)MPC5XXX_CS1_CFG = 0x0f0f1800;
+ *(vu_long *)MPC5XXX_ADDECR |= ~0x0002; /*enable cs1 */
+/*enable PIN as ChipSelect*/
+*(vu_long *)MPC5XXX_GPS_PORT_CONFIG |= 0x8000;
}
You need a dedicated MTD NAND driver for U-Boot as well.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add init_dummy_netdev() and fix EMAC driver using it
On Wed, 14 Jan 2009, Benjamin Herrenschmidt wrote:
This adds an init_dummy_netdev() function that gets a network device
structure (allocation and lifetime entirely under caller's control) and
initialize the minimum amount of fields so it can be used to schedule
NAPI polls without registering a full blown interface. This is to be
used by drivers that need to tie several hardware interfaces to a single
NAPI poll scheduler due to HW limitations.
It also updates the ibm_newemac driver to use that, this fixing the
oops on 2.6.29 due to passing NULL as dev to netif_napi_add()
Symbol is exported GPL only a I don't think we want binary drivers doing
that sort of acrobatics (if we want them at all).
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Thanks, this fixed my Sequoia!
Tested-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com
--- linux-work.orig/include/linux/netdevice.h 2009-01-13 16:13:41.0
+1100
+++ linux-work/include/linux/netdevice.h 2009-01-14 14:13:24.0
+1100
@@ -4434,6 +4434,45 @@ err_uninit:
}
/**
+ * init_dummy_netdev - init a dummy network device for NAPI
+ * @dev: device to init
+ *
+ * This takes a network device structure and initialize the minimum
^^
initializes
+ * amount of fields so it can be used to schedule NAPI polls without
+ * registering a full blown interface. This is to be used by drivers
+ * that need to tie several hardware interfaces to a single NAPI
+ * poll scheduler due to HW limitations.
+ */
+int init_dummy_netdev(struct net_device *dev)
+{
+ /* Clear everything. Note we don't initialize spinlocks
+ * are they aren't supposed to be taken by any of the
^^^
as
+ * NAPI code and this dummy netdev is supposed to be
+ * only ever used for NAPI polls
+ */
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: geert.uytterhoe...@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] dts-bindings/fsl/dma.txt: fix IRQ number in mpc83xx dma example
The DMAC IRQ number of the mpc8349 is 71 and not 47, according to
http://www.freescale.com/files/32bit/doc/ref_manual/MPC8349EARMAD.pdf
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
Documentation/powerpc/dts-bindings/fsl/dma.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt
b/Documentation/powerpc/dts-bindings/fsl/dma.txt
index cc45311..3df1552 100644
--- a/Documentation/powerpc/dts-bindings/fsl/dma.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt
@@ -38,7 +38,7 @@ Example:
reg = 82a8 4;
ranges = 0 8100 1a4;
interrupt-parent = ipic;
- interrupts = 47 8;
+ interrupts = 71 8;
cell-index = 0;
dma-chan...@0 {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dts-bindings/fsl/dma.txt: fix IRQ number in mpc83xx dma example
Hi Peter, On Wed, Jan 14, 2009 at 03:14:13PM +0100, Peter Korsgaard wrote: The DMAC IRQ number of the mpc8349 is 71 and not 47, according to http://www.freescale.com/files/32bit/doc/ref_manual/MPC8349EARMAD.pdf Signed-off-by: Peter Korsgaard jac...@sunsite.dk --- Documentation/powerpc/dts-bindings/fsl/dma.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/powerpc/dts-bindings/fsl/dma.txt index cc45311..3df1552 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt @@ -38,7 +38,7 @@ Example: reg = 82a8 4; ranges = 0 8100 1a4; interrupt-parent = ipic; - interrupts = 47 8; + interrupts = 71 8; 0x47 = 71 ;-) The example is in the dts-v0 format, all the numbers are hexadecimal. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dts-bindings/fsl/dma.txt: fix IRQ number in mpc83xx dma example
On Jan 14, 2009, at 8:21 AM, Anton Vorontsov wrote: Hi Peter, On Wed, Jan 14, 2009 at 03:14:13PM +0100, Peter Korsgaard wrote: The DMAC IRQ number of the mpc8349 is 71 and not 47, according to http://www.freescale.com/files/32bit/doc/ref_manual/MPC8349EARMAD.pdf Signed-off-by: Peter Korsgaard jac...@sunsite.dk --- Documentation/powerpc/dts-bindings/fsl/dma.txt |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/ Documentation/powerpc/dts-bindings/fsl/dma.txt index cc45311..3df1552 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt @@ -38,7 +38,7 @@ Example: reg = 82a8 4; ranges = 0 8100 1a4; interrupt-parent = ipic; - interrupts = 47 8; + interrupts = 71 8; 0x47 = 71 ;-) The example is in the dts-v0 format, all the numbers are hexadecimal. I'm all for changing the docs to dts-v1 syntax but if you are going to do that. Do it completely for the file. (reg, ranges, etc..) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsldma: print correct IRQ on mpc83xx
The mpc83xx variant uses a shared IRQ for all channels, so the individual channel nodes don't have an interrupt property. Fix the code to print the controller IRQ instead if there isn't any for the channel. Signed-off-by: Peter Korsgaard jac...@sunsite.dk --- drivers/dma/fsldma.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c index ca70a21..61b6e08 100644 --- a/drivers/dma/fsldma.c +++ b/drivers/dma/fsldma.c @@ -875,7 +875,8 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev, } dev_info(fdev-dev, #%d (%s), irq %d\n, new_fsl_chan-id, - compatible, new_fsl_chan-irq); +compatible, +new_fsl_chan-irq != NO_IRQ ? new_fsl_chan-irq : fdev-irq); return 0; -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] dts-bindings/fsl/dma.txt: fix IRQ number in mpc83xx dma example
Anton == Anton Vorontsov avoront...@ru.mvista.com writes: Hi, interrupt-parent = ipic; - interrupts = 47 8; + interrupts = 71 8; Anton 0x47 = 71 ;-) The example is in the dts-v0 format, all the numbers Anton are hexadecimal. Ahh ;) -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] dts-bindings/fsl/dma.txt: convert to dts-v1 syntax
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
Documentation/powerpc/dts-bindings/fsl/dma.txt | 34
1 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt
b/Documentation/powerpc/dts-bindings/fsl/dma.txt
index cc45311..0732cdd 100644
--- a/Documentation/powerpc/dts-bindings/fsl/dma.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/dma.txt
@@ -35,30 +35,30 @@ Example:
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc8349-dma, fsl,elo-dma;
- reg = 82a8 4;
- ranges = 0 8100 1a4;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a4;
interrupt-parent = ipic;
- interrupts = 47 8;
+ interrupts = 71 8;
cell-index = 0;
dma-chan...@0 {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
cell-index = 0;
- reg = 0 80;
+ reg = 0 0x80;
};
dma-chan...@80 {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
cell-index = 1;
- reg = 80 80;
+ reg = 0x80 0x80;
};
dma-chan...@100 {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
cell-index = 2;
- reg = 100 80;
+ reg = 0x100 0x80;
};
dma-chan...@180 {
compatible = fsl,mpc8349-dma-channel,
fsl,elo-dma-channel;
cell-index = 3;
- reg = 180 80;
+ reg = 0x180 0x80;
};
};
@@ -93,36 +93,36 @@ Example:
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc8540-dma, fsl,eloplus-dma;
- reg = 21300 4;
- ranges = 0 21100 200;
+ reg = 0x21300 4;
+ ranges = 0 0x21100 0x200;
cell-index = 0;
dma-chan...@0 {
compatible = fsl,mpc8540-dma-channel,
fsl,eloplus-dma-channel;
- reg = 0 80;
+ reg = 0 0x80;
cell-index = 0;
interrupt-parent = mpic;
- interrupts = 14 2;
+ interrupts = 20 2;
};
dma-chan...@80 {
compatible = fsl,mpc8540-dma-channel,
fsl,eloplus-dma-channel;
- reg = 80 80;
+ reg = 0x80 0x80;
cell-index = 1;
interrupt-parent = mpic;
- interrupts = 15 2;
+ interrupts = 21 2;
};
dma-chan...@100 {
compatible = fsl,mpc8540-dma-channel,
fsl,eloplus-dma-channel;
- reg = 100 80;
+ reg = 0x100 0x80;
cell-index = 2;
interrupt-parent = mpic;
- interrupts = 16 2;
+ interrupts = 22 2;
};
dma-chan...@180 {
compatible = fsl,mpc8540-dma-channel,
fsl,eloplus-dma-channel;
- reg = 180 80;
+ reg = 0x180 0x80;
cell-index = 3;
interrupt-parent = mpic;
- interrupts = 17 2;
+ interrupts = 23 2;
};
};
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Fix Freescale TBI PHY detection
On Tue, Jan 13, 2009 at 07:05:13PM +0300, Anton Vorontsov wrote:
Freescale on-chip TBI PHYs reports PHY ID as 0x0, but as of
commit 3ee82383f0098a2e13acc8cf1be8e47512f41e5a
Author: Giulio Benetti giulio.bene...@micronovasrl.com
Date: Thu Nov 13 21:53:13 2008 +
phy: fix phy address bug
PHYID returns 0x and not 0x when not found and in some
case(at91sam9263) 0x0. Maybe this patch could be useful.
phy_device.c treats PHY ID == 0x0 as bogus IDs, and that results in
gianfar driver failure to see the TBI PHYs. This code snippet triggers:
if (!priv-tbiphy) {
printk(KERN_WARNING SGMII mode requires that the device
tree specify a tbi-handle\n);
return;
}
Although tbi-handle is specified in the device tree.
Btw, technically PHY ID == 0x0 is a valid ID (if we ever see a PHY
manufactured by Xerox :-).
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
There is one thing I don't actually understand though...
Andy, were you testing the TBI support on a hardware where PHY ID
!= 0x0 or maybe your TBI PHY support patch (commit b31a1d8b41513b,
dated Tue Dec 16 15:29:15 2008) was based on a bit outdated kernel
version? Because according to the git timestamps, the TBI support
was not working since the submission.
Just in case, the hardware I'm seeing the PHY ID == 0x0 is
MPC8378E-MDS.
I think I got it. Probably the TBI support patch was based on the
powerpc.git next, and the commit that broke the TBI support
was in the net-next-2.6 tree.
That explains why nobody noticed the issue.
drivers/net/phy/phy_device.c |9 -
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e354601..0a06e4f 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -231,15 +231,6 @@ struct phy_device * get_phy_device(struct mii_bus *bus,
int addr)
if ((phy_id 0x1fff) == 0x1fff)
return NULL;
- /*
- * Broken hardware is sometimes missing the pull-up resistor on the
- * MDIO line, which results in reads to non-existent devices returning
- * 0 rather than 0x. Catch this here and treat 0 as a non-existent
- * device as well.
- */
- if (phy_id == 0)
- return NULL;
-
dev = phy_device_create(bus, addr, phy_id);
return dev;
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: When do i need to allocate DMA buffer
Hi Showair ,Note that my target is to transfer data from memory location to another memory location it will be an overhead if i copy the data from the src to the DMA buffer then from the DMA buffer to the Destination. isn't there any other way to avoid using that DMA buffer to copy data from src to dest directly? I doubt that your concept of dma transfer and dma memory operation is not very clear .Please excuse me thats what i got reading your concern . you dont need to copy the data fromsrc to destinationthat the dma engine would take care . i dont think there could be a better way of implementing the same in other way .The engine would copy the data block to the destination andgenerate an end of transfer interrupt .I dont think you have to allocate memory for that you just have to give the virtual address corresponding to the physical address using ioremap() and size to the dma engine and it will transfer the data from source to destination offcource other channel and EOTconfiguration needs to be done in driver init or else where .ThanksRegards,Misbah_EmSySDivision,LarsenToubroLimited,KIADBindusrialarea,Hebbal,Hootagalli.Mysore,India570018Phone:08212405398Extn:5172_Thismailisclassifiedas:(X)LTEmSySProprietary()LTEmSySConfidential()LTEmSySInternalUse()LTEmSySGeneralBusiness-linuxppc-dev-bounces+misbahullah.khan=lntemsys@ozlabs.org wrote: -To: linuxppc-dev@ozlabs.orgFrom: wael showair showair2...@yahoo.comSent by: linuxppc-dev-bounces+misbahullah.khan=lntemsys@ozlabs.orgDate: 01/12/2009 05:33PMSubject: When do i need to allocate DMA bufferHi All,i have MPC8555 processor, also i have linux-kernel 2.6.19-rc5 on my board.iwant to use the DMA on my board, just a simple example is enough for me butduring my reading on how to use the DMA i have some questions:1. The DMA buffer is always needed for all kind of buses or not? (I thinkthis is valid in the ISA bus but not in the PCI bus, plz correct me if i mwrong?)Note that my target is to transfer data from memory location to anothermemory location it will be an overhead if i copy the data from the src tothe DMA buffer then from the DMA buffer to the Destination.isn't there any other way to avoid using that DMA buffer to copy data fromsrc to dest directly?i read the documentation of my board it tells me that it contain DMAengine which "is capable of transferring blocks of data from any legaladdress range to anyother legal address range."2. i have read DMA-API.txt in the linux Documentation folder but i m littleconfused about the APIs that exist in this file. Actually, it is stated inthis file the following:"This document describes the DMA API.This API is split into two pieces. Part I describes the API and the corresponding pci_ API".so if the DMA controller is connected to the PCI bus, am i obligated to usethe pci_API for any other case (like ISA bus or any other bus types) shalli use this generic API?also what r the benefits of these APIs over the normal kmalloc? speciallythat i have read the following section in the DMA-mapping.txt:"If you acquired your memory via the page allocator(i.e. __get_free_page*()) or the generic memory allocators(i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/fromthat memory using the addresses returned from those routines."thanks in advance for ur help-- View this message in context: http://www.nabble.com/When-do-i-need-to-allocate-DMA-buffer-tp21413193p21413193.htmlSent from the linuxppc-dev mailing list archive at Nabble.com.___Linuxppc-dev mailing listLinuxppc-dev@ozlabs.orghttps://ozlabs.org/mailman/listinfo/linuxppc-dev___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Peter Korsgaard wrote: @@ -875,7 +875,8 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev, } dev_info(fdev-dev, #%d (%s), irq %d\n, new_fsl_chan-id, - compatible, new_fsl_chan-irq); + compatible, + new_fsl_chan-irq != NO_IRQ ? new_fsl_chan-irq : fdev-irq); Wouldn't it be better to make sure that, on 83xx, new_fsl_chan-irq has the same value as fdev-irq before we get here? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Timur == Timur Tabi ti...@freescale.com writes: Timur Peter Korsgaard wrote: @@ -875,7 +875,8 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev, } dev_info(fdev-dev, #%d (%s), irq %d\n, new_fsl_chan-id, - compatible, new_fsl_chan-irq); +compatible, +new_fsl_chan-irq != NO_IRQ ? new_fsl_chan-irq : fdev-irq); Timur Wouldn't it be better to make sure that, on 83xx, Timur new_fsl_chan-irq has the same value as fdev-irq before we Timur get here? Why? Does it buy us anything to request_irq again for each channel? Now we're at it, it seems like there's a check for != NO_IRQ missing in fsl_dma_chan_remove(). -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] fsldma: check for NO_IRQ in fsl_dma_chan_remove()
There's no per-channel IRQ on mpc83xx, so only call free_irq if we have one.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
drivers/dma/fsldma.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index ca70a21..f48c0e6 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -890,7 +890,8 @@ err_no_reg:
static void fsl_dma_chan_remove(struct fsl_dma_chan *fchan)
{
- free_irq(fchan-irq, fchan);
+ if (fchan-irq != NO_IRQ)
+ free_irq(fchan-irq, fchan);
list_del(fchan-common.device_node);
iounmap(fchan-reg_base);
kfree(fchan);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Peter Korsgaard wrote: Why? Does it buy us anything to request_irq again for each channel? Now we're at it, it seems like there's a check for != NO_IRQ missing in fsl_dma_chan_remove(). If the device tree doesn't specify an interrupts property in the device channel, then I think that's an error. All the device trees already do that. So where do you see this problem? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Timur == Timur Tabi ti...@freescale.com writes: Timur Peter Korsgaard wrote: Why? Does it buy us anything to request_irq again for each channel? Now we're at it, it seems like there's a check for != NO_IRQ missing in fsl_dma_chan_remove(). Timur If the device tree doesn't specify an interrupts property in Timur the device channel, then I think that's an error. All the Timur device trees already do that. So where do you see this Timur problem? Documentation/powerpc/dts-bindings/fsl/dma.txt and The NO_IRQ check in fsldma.c:fsl_dma_chan_probe() And it makes sense, there's no per-channel DMAC interrupts on mpc83xx. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Peter Korsgaard wrote:
Documentation/powerpc/dts-bindings/fsl/dma.txt and
The NO_IRQ check in fsldma.c:fsl_dma_chan_probe()
And it makes sense, there's no per-channel DMAC interrupts on mpc83xx.
But the device trees do have IRQs in the channels:
arch/powerpc/boot/dts/mpc836x_mds.dts:
d...@82a8 {
...
interrupt-parent = ipic;
interrupts = 71 8;
dma-chan...@0 {
compatible = fsl,mpc8360-dma-channel, fsl,elo-dma-channel;
reg = 0 0x80;
cell-index = 0;
interrupt-parent = ipic;
interrupts = 71 8;
};
...
So I don't see what bug you're trying to fix. If you're saying that the
interrupts should not be specific DMA channels, then the proper fix is to have
the DMA driver pick up the interrupts from the DMA controller's node when
necessary. Hacking up a printk doesn't fix anything.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
ADS5121 how to use /dev/ttyPSC
Hi I'm new to Kernel 2.6 and OF. I'm using a ADS5121 board with kernel from denx (ads5121 branch from linux-2.6-denx). According to my dts file both PSC3 and PSC4 should be accessible through /dev/ttyPSC0 and /dev/ttyPSC1 respectively. When I simply try to run: $ echo Hello /dev/ttyPSC* I can't see any data coming out from the ports. And when trying to initialize the ports using termios commands I'm getting the Error Inappropriate ioctl for device. I'm not even getting a negative voltage on the TX Pin (idle state). But I can see the driver ttyPSC with major 204 in /proc/devices and I can also open the device successfully. I am also able to configure either port as CONSOLE in U-Boot so the Hardware is ok. Any ideas? Many thanks, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Fix Freescale TBI PHY detection
On Jan 14, 2009, at 9:03 AM, Anton Vorontsov wrote: There is one thing I don't actually understand though... Andy, were you testing the TBI support on a hardware where PHY ID != 0x0 or maybe your TBI PHY support patch (commit b31a1d8b41513b, dated Tue Dec 16 15:29:15 2008) was based on a bit outdated kernel version? Because according to the git timestamps, the TBI support was not working since the submission. Just in case, the hardware I'm seeing the PHY ID == 0x0 is MPC8378E-MDS. I think I got it. Probably the TBI support patch was based on the powerpc.git next, and the commit that broke the TBI support was in the net-next-2.6 tree. That explains why nobody noticed the issue. Yeah, I dropped the ball. I saw the patch go in, thought that might break something, but I didn't find time to look into it. Thanks for finding and reverting this bug. Acked-by: Andy Fleming aflem...@freescale.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: is_hugepage_only_range() must account for both 4kB and 64kB slices
powerpc: is_hugepage_only_range() must account for both 4kB and 64kB slices
The subpage_prot syscall fails on second and subsequent calls for a given
region, because is_hugepage_only_range() is mis-identifying the 4 kB
slices when the process has a 64 kB page size.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
Cc: Paul Mackerras pau...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index db44e02..ba51948 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -710,9 +710,18 @@ int is_hugepage_only_range(struct mm_struct *mm, unsigned
long addr,
unsigned long len)
{
struct slice_mask mask, available;
+ unsigned int psize = mm-context.user_psize;
mask = slice_range_to_mask(addr, len);
- available = slice_mask_for_size(mm, mm-context.user_psize);
+ available = slice_mask_for_size(mm, psize);
+#ifdef CONFIG_PPC_64K_PAGES
+ /* We need to account for 4k slices too */
+ if (psize == MMU_PAGE_64K) {
+ struct slice_mask compat_mask;
+ compat_mask = slice_mask_for_size(mm, MMU_PAGE_4K);
+ or_mask(available, compat_mask);
+ }
+#endif
#if 0 /* too verbose */
slice_dbg(is_hugepage_only_range(mm=%p, addr=%lx, len=%lx)\n,
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Timur == Timur Tabi ti...@freescale.com writes: Timur Peter Korsgaard wrote: Documentation/powerpc/dts-bindings/fsl/dma.txt and The NO_IRQ check in fsldma.c:fsl_dma_chan_probe() And it makes sense, there's no per-channel DMAC interrupts on mpc83xx. Timur But the device trees do have IRQs in the channels: Timur arch/powerpc/boot/dts/mpc836x_mds.dts: Timur So I don't see what bug you're trying to fix. If you're Timur saying that the interrupts should not be specific DMA Timur channels, then the proper fix is to have the DMA driver pick Timur up the interrupts from the DMA controller's node when Timur necessary. Hacking up a printk doesn't fix anything. Ok, let me try again. SOME device trees indeed have an interrupt property per channel, but the bindings (Documentation/powerpc/dts-bindings/fsl/dma.txt) and the probe code in fsldma.c doesn't require it. The only minor issues we have is the cosmetic problem of the driver printing NO_IRQ (E.G. this patch), and the driver calling free_irq(NO_IRQ) (E.G. the other patch I sent today) in the release path. -- Bye, Peter Korsgaard ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Peter Korsgaard wrote: The only minor issues we have is the cosmetic problem of the driver printing NO_IRQ (E.G. this patch), and the driver calling free_irq(NO_IRQ) (E.G. the other patch I sent today) in the release path. Ok, I understand. ACK on the patches. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mmc: Add driver for Freescale eSDHC controllers
From: Xie Xiaobo x@freescale.com
This patch adds support for the Freescale Enhanced Secure Digital
Host Controller Interface as found in some Freescale PowerPC
microprocessors (e.g. MPC837x SOCs).
Signed-off-by: Xie Xiaobo x@freescale.com
Signed-off-by: Konjin Lai konjin@freescale.com
Signed-off-by: Joe D'Abbraccio Joe.D'abbrac...@freescale.com
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
drivers/mmc/host/Kconfig |9 +
drivers/mmc/host/Makefile |1 +
drivers/mmc/host/esdhc.c | 1321 +
drivers/mmc/host/esdhc.h | 255 +
4 files changed, 1586 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/esdhc.c
create mode 100644 drivers/mmc/host/esdhc.h
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index dfa585f..941975c 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -65,6 +65,15 @@ config MMC_RICOH_MMC
If unsure, say Y.
+config MMC_ESDHC
+ tristate Freescale Enhanced SD Host Controller Interface support
+ depends on FSL_SOC
+ help
+ This selects the Freescale Enhanced SD Host Controller Interface
+ as found in some Freescale PowerPC microprocessors.
+
+ If unsure, say N.
+
config MMC_OMAP
tristate TI OMAP Multimedia Card Interface support
depends on ARCH_OMAP
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index f485328..031489f 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_MMC_IMX) += imxmmc.o
obj-$(CONFIG_MMC_SDHCI)+= sdhci.o
obj-$(CONFIG_MMC_SDHCI_PCI)+= sdhci-pci.o
obj-$(CONFIG_MMC_RICOH_MMC)+= ricoh_mmc.o
+obj-$(CONFIG_MMC_ESDHC)+= esdhc.o
obj-$(CONFIG_MMC_WBSD) += wbsd.o
obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
obj-$(CONFIG_MMC_OMAP) += omap.o
diff --git a/drivers/mmc/host/esdhc.c b/drivers/mmc/host/esdhc.c
new file mode 100644
index 000..c97689d
--- /dev/null
+++ b/drivers/mmc/host/esdhc.c
@@ -0,0 +1,1321 @@
+/*
+ * Freescale Enhanced Secure Digital Host Controller driver.
+ *
+ * Copyright (C) 2005-2008 Pierre Ossman, All Rights Reserved.
+ * Copyright (C) 2007-2009 Freescale Semiconductor, Inc. All rights reserved.
+ * Copyright (C) 2008-2009 MontaVista Software, Inc. All rights reserved.
+ *
+ * Author: Xiaobo Xie x@freescale.com
+ *
+ * Derived from sdhci driver by Pierre Ossman drz...@drzeus.cx
+ *
+ * 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.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/ioport.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/highmem.h
+#include linux/dma-mapping.h
+#include linux/scatterlist.h
+#include linux/uaccess.h
+#include linux/irq.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/mmc/host.h
+#include esdhc.h
+
+#define DBG(fmt, args...) pr_debug([%s] fmt \n, __func__, ## args)
+
+static unsigned int debug_nodma;
+module_param(debug_nodma, uint, 0444);
+MODULE_PARM_DESC(debug_nodma, Forcefully disable DMA transfers.);
+
+static unsigned int debug_forcedma;
+module_param(debug_forcedma, uint, 0444);
+MODULE_PARM_DESC(debug_forcedma, Forcefully enable DMA transfers.);
+
+#define ESDHC_QUIRK_CLOCK_BEFORE_RESET (1 0)
+#define ESDHC_QUIRK_FORCE_DMA (1 1)
+#define ESDHC_QUIRK_NO_CARD_NO_RESET (1 2)
+#define ESDHC_QUIRK_SINGLE_POWER_WRITE (1 3)
+
+static unsigned int debug_quirks;
+module_param(debug_quirks, uint, 0444);
+MODULE_PARM_DESC(debug_quirks, Force certain quirks.);
+
+static void esdhc_dumpregs(struct esdhc_host *host)
+{
+ DBG(= REGISTER DUMP ==);
+ DBG(Sysaddr: 0x%08x | Blkattr: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_DMA_ADDRESS),
+ fsl_readl(host-ioaddr + ESDHC_BLOCK_ATTR));
+ DBG(Argument: 0x%08x | COMMAND: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_ARGUMENT),
+ fsl_readl(host-ioaddr + ESDHC_COMMAND));
+ DBG(Present: 0x%08x | DMA ctl: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_PRESENT_STATE),
+ fsl_readl(host-ioaddr + ESDHC_DMA_SYSCTL));
+ DBG(PROCTL: 0x%08x | SYSCTL: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_PROTOCOL_CONTROL),
+ fsl_readl(host-ioaddr + ESDHC_SYSTEM_CONTROL));
+ DBG(Int stat: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_INT_STATUS));
+ DBG(Intenab: 0x%08x | Sigenab: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_INT_ENABLE),
+ fsl_readl(host-ioaddr + ESDHC_SIGNAL_ENABLE));
+ DBG(AC12 err: 0x%08x | Version: 0x%08x,
+ fsl_readl(host-ioaddr + ESDHC_ACMD12_ERR),
+
Re: [PATCH v3] powerpc: Unify opcode definitions and support
On Tue, Jan 13, 2009 at 4:14 PM, Kumar Gala ga...@kernel.crashing.org wrote: Create a new header that becomes a single location for defining PowerPC opcodes used by code that is either generationg instructions at runtime (fixups, debug, etc.), emulating instructions, or just compiling instructions old assemblers don't know about. We currently don't handle the floating point emulation or alignment decode as both are better handled by the specific decode support they already have. Added support for the new dcbzl, dcbal, msgsnd, tlbilx, wait instructions since older assemblers don't know about them. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- * Added PPC_ prefixes to everything to ensure namespace * removed defines from traps.c arch/powerpc/include/asm/code-patching.h |4 +- arch/powerpc/include/asm/ppc-opcode.h| 68 ++ arch/powerpc/include/asm/ppc_asm.h |6 +-- arch/powerpc/kernel/crash_dump.c |2 +- arch/powerpc/kernel/entry_32.S |8 ++-- arch/powerpc/kernel/ftrace.c |8 ++-- arch/powerpc/kernel/head_booke.h |2 +- arch/powerpc/kernel/module_64.c |2 +- arch/powerpc/kernel/traps.c | 58 - arch/powerpc/lib/feature-fixups.c|4 +- 10 files changed, 101 insertions(+), 61 deletions(-) create mode 100644 arch/powerpc/include/asm/ppc-opcode.h Shouldn't arch/powerpc/include/asm/disassemble.h be integrated with this? -Hollis ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Restore PCI IO space behind Freescale pseudo-bridge
When I moved from 2.6.27 to 2.6.28, one of my devices didn't work
until I devised the attached patch. The kernel disallowed PCI I/O
space resources behind the pseudo-bridge in the Freescale MPC8545
because that bridge's config-space registers incorrectly report that
it doesn't forward I/O space transactions.
Checking for a specific vendor ID is hacky, but it got my system going
again with only a few perturbed lines. Is there a more correct way to
achieve this?
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index f36936d..f9f0048 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -985,6 +985,7 @@ static int __devinit
pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
struct pci_dev *dev = bus-self;
resource_size_t offset;
u16 command;
+ u16 vendor;
int i;
/* We don't do anything if PCI_PROBE_ONLY is set */
@@ -1030,7 +1031,16 @@ static int __devinit
pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
* starting at low addresses -is- valid. What we do instead if
that
* we consider as unassigned anything that doesn't have IO
enabled
* in the PCI command register, and that's it.
+* However, we don't do that if the bridge is internal to a
Freescale
+* CPU, as such bridges break the rules by, for example, not
populating
+* the PCI_COMMAND_IO bit.
*/
+ pci_read_config_word(dev, PCI_VENDOR_ID, vendor);
+ if (vendor == PCI_VENDOR_ID_MOTOROLA ||
+ vendor == PCI_VENDOR_ID_FREESCALE) {
+ return 0;
+ }
+
pci_read_config_word(dev, PCI_COMMAND, command);
if (command PCI_COMMAND_IO)
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Restore PCI IO space behind Freescale pseudo-bridge
On Wed, 2009-01-14 at 11:48 -0800, Andrew Klossner wrote:
When I moved from 2.6.27 to 2.6.28, one of my devices didn't work
until I devised the attached patch. The kernel disallowed PCI I/O
space resources behind the pseudo-bridge in the Freescale MPC8545
because that bridge's config-space registers incorrectly report that
it doesn't forward I/O space transactions.
Checking for a specific vendor ID is hacky, but it got my system going
again with only a few perturbed lines. Is there a more correct way to
achieve this?
A few things yes.
First, can't you just set the PCI_COMMAND_IO bit from a quirk or at init
time rather than adding to code to cope with it being cleared later on ?
Also, the fact that it's detected as uninitialized shouldn't have broken
access to your device. If there is need for some IO space, for example
because a device requests some, the kernel should have re-opened that
window of the bridge.
Thus if that failed, it would be useful to track it down a bit more. You
can try enabling DEBUG in pci-common.c and pci-64.c, boot with debug
on the kernel command line and and send the resulting dmesg log
Ben.
diff --git a/arch/powerpc/kernel/pci-common.c
b/arch/powerpc/kernel/pci-common.c
index f36936d..f9f0048 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -985,6 +985,7 @@ static int __devinit
pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
struct pci_dev *dev = bus-self;
resource_size_t offset;
u16 command;
+ u16 vendor;
int i;
/* We don't do anything if PCI_PROBE_ONLY is set */
@@ -1030,7 +1031,16 @@ static int __devinit
pcibios_uninitialized_bridge_resource(struct pci_bus *bus,
* starting at low addresses -is- valid. What we do instead if
that
* we consider as unassigned anything that doesn't have IO
enabled
* in the PCI command register, and that's it.
+ * However, we don't do that if the bridge is internal to a
Freescale
+ * CPU, as such bridges break the rules by, for example, not
populating
+ * the PCI_COMMAND_IO bit.
*/
+ pci_read_config_word(dev, PCI_VENDOR_ID, vendor);
+ if (vendor == PCI_VENDOR_ID_MOTOROLA ||
+ vendor == PCI_VENDOR_ID_FREESCALE) {
+ return 0;
+ }
+
pci_read_config_word(dev, PCI_COMMAND, command);
if (command PCI_COMMAND_IO)
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] phylib: Fix Freescale TBI PHY detection
From: Andy Fleming aflem...@freescale.com Date: Wed, 14 Jan 2009 12:20:35 -0600 On Jan 14, 2009, at 9:03 AM, Anton Vorontsov wrote: There is one thing I don't actually understand though... Andy, were you testing the TBI support on a hardware where PHY ID != 0x0 or maybe your TBI PHY support patch (commit b31a1d8b41513b, dated Tue Dec 16 15:29:15 2008) was based on a bit outdated kernel version? Because according to the git timestamps, the TBI support was not working since the submission. Just in case, the hardware I'm seeing the PHY ID == 0x0 is MPC8378E-MDS. I think I got it. Probably the TBI support patch was based on the powerpc.git next, and the commit that broke the TBI support was in the net-next-2.6 tree. That explains why nobody noticed the issue. Yeah, I dropped the ball. I saw the patch go in, thought that might break something, but I didn't find time to look into it. Thanks for finding and reverting this bug. Acked-by: Andy Fleming aflem...@freescale.com Patch applied, thanks everyone. I was worried when I applied the patch causing this, that some device would in fact trigger that specific test. Turns out my worries were warranted :) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/13] powerpc/ps3: set_dabr takes an unsigned long
Hi Stephen, Thanks for working through it and making these fixups. I tested the set applied onto Ben's powerpc tree and they seem to work OK (with ps3_defconfig). Stephen Rothwell wrote: Also silences this warning: arch/powerpc/platforms/ps3/setup.c:275: warning: initialization from incompatible pointer type Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/platforms/ps3/setup.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 02/13] powerpc/ps3: use dma_addr_t down through the stack
Stephen Rothwell wrote: Push the dma_addr_t type usage all the way down to where the actual values are manipulated. Now that u64 is unsigned long long, this removes warnings like: arch/powerpc/platforms/ps3/system-bus.c:532: warning: passing argument 4 of 'ps3_dma_map' from incompatible pointer type arch/powerpc/platforms/ps3/system-bus.c:649: warning: passing argument 4 of 'ps3_dma_map' from incompatible pointer type Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/include/asm/ps3.h |8 +++--- arch/powerpc/platforms/ps3/mm.c | 32 -- arch/powerpc/platforms/ps3/system-bus.c |4 +- 3 files changed, 23 insertions(+), 21 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/13] powerpc/ps3: clear_bit/set_bit operate on unsigned longs
Stephen Rothwell wrote: This fixes these compiler warning: arch/powerpc/platforms/ps3/interrupt.c:109: warning: passing argument 2 of 'clear_bit' from incompatible pointer type arch/powerpc/platforms/ps3/interrupt.c:130: warning: passing argument 2 of 'set_bit' from incompatible pointer type Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/platforms/ps3/interrupt.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 05/13] powerpc/ps3: ps3_repository_read_mm_info takes u64 * arguments
Stephen Rothwell wrote: Fixes compiler warnings: arch/powerpc/platforms/ps3/mm.c:1205: warning: passing argument 2 of 'ps3_repository_read_mm_info' from incompatible pointer type arch/powerpc/platforms/ps3/mm.c:1205: warning: passing argument 3 of 'ps3_repository_read_mm_info' from incompatible pointer type Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/platforms/ps3/mm.c | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 03/13] powerpc/ps3: the lv1_ routines have u64 parameters
Stephen Rothwell wrote: We just fix up the reference parameters as the others are dealt with by arithmetic promotion rules and don't cause warnings. This removes warnings like this: arch/powerpc/platforms/ps3/interrupt.c:327: warning: passing argument 1 of 'lv1_construct_event_receive_port' from incompatible pointer type Also, these: drivers/ps3/ps3-vuart.c:462: warning: passing argument 4 of 'ps3_vuart_raw_read' from incompatible pointer type drivers/ps3/ps3-vuart.c:592: warning: passing argument 4 of 'ps3_vuart_raw_read' from incompatible pointer type Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/platforms/ps3/interrupt.c |8 +++--- arch/powerpc/platforms/ps3/mm.c | 38 +- arch/powerpc/platforms/ps3/spu.c| 12 ++--- arch/powerpc/platforms/ps3/system-bus.c |4 ++- drivers/ps3/ps3-vuart.c | 24 ++- 5 files changed, 49 insertions(+), 37 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 09/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: sound/ppc
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- sound/ppc/snd_ps3.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 13/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/video
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/video/ps3fb.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 12/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/scsi
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/scsi/ps3rom.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 08/13] powerpc/ps3: printing fixups for l64 to ll64 convserion: drivers/char
Stephen Rothwell wrote: Also a couple of min - min_t changes. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/char/ps3flash.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/ps3
Stephen Rothwell wrote: Also some min - mint_t conversion. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/ps3/ps3-lpm.c | 16 drivers/ps3/ps3-vuart.c |8 drivers/ps3/ps3stor_lib.c | 14 +++--- 3 files changed, 19 insertions(+), 19 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 07/13] powerpc/ps3: printing fixups for l64 to ll64 conversion: drivers/block
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/block/ps3disk.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/13] powerpc/ps3: printing fixups for l64 to ll64 convserion: drivers/net
Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/net/ps3_gelic_wireless.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Acked-by: Geoff Levand geoffrey.lev...@am.sony.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] mmc: Add driver for Freescale eSDHC controllers
This patch adds support for the Freescale Enhanced Secure Digital Host Controller Interface as found in some Freescale PowerPC microprocessors (e.g. MPC837x SOCs). The Freescale ESDHC controller is basically compatible with the standard SDHC controller. but the eshdc expand some bits. The esdhc.c is much like the orignal sdhci.c. it is possible to merge them. Thanks, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: get the number of SLBs from slb-size property
The PAPR says that the property for specifying the number of SLBs should
be called slb-size. We currently only look for ibm,slb-size because
this is what firmware actually presents.
This patch makes us look for the slb-size property as well and in
preference to the ibm,slb-size. This should future proof us if
firmware changes to match PAPR.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/kernel/prom.c |5 +
1 file changed, 5 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
@@ -590,6 +590,11 @@ static void __init check_cpu_slb_size(un
{
u32 *slb_size_ptr;
+ slb_size_ptr = of_get_flat_dt_prop(node, slb-size, NULL);
+ if (slb_size_ptr != NULL) {
+ mmu_slb_size = *slb_size_ptr;
+ return;
+ }
slb_size_ptr = of_get_flat_dt_prop(node, ibm,slb-size, NULL);
if (slb_size_ptr != NULL) {
mmu_slb_size = *slb_size_ptr;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mmc: Add driver for Freescale eSDHC controllers
On Thu, Jan 15, 2009 at 07:37:00AM +0800, Liu Dave wrote: This patch adds support for the Freescale Enhanced Secure Digital Host Controller Interface as found in some Freescale PowerPC microprocessors (e.g. MPC837x SOCs). The Freescale ESDHC controller is basically compatible with the standard SDHC controller. but the eshdc expand some bits. The esdhc.c is much like the orignal sdhci.c. it is possible to merge them. Ah. I wonder why Freescale just didn't write some patches for sdhci, but copied the code instead... Thanks for the info, I'll look into merging the driver into sdhci. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH RFC v5] net: add PCINet driver
On Tue, Jan 13, 2009 at 06:42:53PM +0100, Arnd Bergmann wrote:
On Tuesday 13 January 2009, Ira Snyder wrote:
So do you program one channel of the DMA engine from the host side and
another channel from the guest side?
Yes.
I tried to avoid having the host program the DMA controller at all.
Using the DMAEngine API on the guest did better than I could achieve by
programming the registers manually. I didn't use chaining or any of the
fancier features in my tests, though.
Our driver unfortunately does not use the DMA API, but it clearly
should. What this means in your case is that you would need to port
the freescale DMA engine driver to the host side, to operate on the
PCI device. Not sure about how specifically this would work on fsl
hardware, but it seems generally doable.
The only problem with that is that you cannot route interrupts from the
DMA controller over PCI with the PowerPC core running. Which makes it
mostly useless for this case.
It /could/ work with polling mmio reads of the DMA controller register,
but as you said, mmio reads are slow, and that would be best avoided. I
don't think porting the driver is the right way to go.
If I haven't said it before, let me say it now: the DMA controller can
access all of the host's memory as well as all of the guest's memory.
I have been studying the virtio and virtio_ring systems, and I now have
a good idea about how to implement virtio-over-pci. I'm having trouble
coming up with a good scheme to use the DMA controller for all the data
transfers, though.
It is fairly easy to use the DMA controller in the virtio_net case,
since the virtio_net driver allocates all of the RX buffers ahead of
time. The guest can DMA directly from host TX into guest RX, then mark
the host TX buffers consumed. The same is true in reverse: the guest can
DMA directly from it's TX into the host RX, then mark the host RX
buffers consumed.
I'm not sure how to handle the bidirectional virtqueue case, though.
Such as the upcoming changes to virtio_net or virtio_blk. It seems like
you'd need to copy pages in this case, since you want to use the DMA to
transfer them.
I have come up with a nice scheme to maintain the buffer descriptor
tables in both host and guest memory without doing anything except mmio
writes. The scheme is almost identical to virtio_ring, with the
exception that both machines need a copy of vring-desc's flags and next
fields, to avoid the reads in virtio_rings detach_buf().
Maybe I'm overoptimistic in thinking that two instances of virtio_net
could talk to each other if the RX and TX queues were hooked up
accordingly in the find_vq() function. Has anyone actually tried this?
To anyone that is trying to learn virtio, I dummied up this mock driver
that registers a virtio_device for every MPC8349EMDS board in the
system. The virtqueues don't actually do anything, but they do print
messages so you know when they're used. It is almost certainly buggy and
horrible code. I'm only reproducing it here because it helped me get
started.
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/pci.h
#include linux/virtio.h
#include linux/virtio_config.h
#include linux/virtio_net.h
#include pcinet_hw.h
static const char driver_name[] = vdev;
struct vpt_dev {
struct virtio_device vdev;
u8 status;
void __iomem *immr;
void __iomem *netregs;
#define NUM_VQS 4
struct virtqueue *vqs[NUM_VQS];
unsigned int in;
unsigned int out;
};
#define vdev_to_vpt(vdev) container_of(vdev, struct vpt_dev, vdev)
/**/
/* struct virtqueue_ops infrastructure*/
/**/
static int vpt_vq_add_buf(struct virtqueue *vq,
struct scatterlist sg[],
unsigned int out_num,
unsigned int in_num,
void *data)
{
struct virtio_device *vdev = vq-vdev;
struct vpt_dev *priv = vdev_to_vpt(vdev);
pr_info(%s: vq=0x%p sg=0x%p, out=%u in=%d data=0x%p\n,
__func__, vq, sg, out_num, in_num, data);
priv-in += in_num;
priv-out += out_num;
if (priv-in 10 || priv-out 10) {
pr_info(%s: vq=0x%p buffers filled\n, __func__, vq);
return -ENOMEM;
}
return 0;
}
static void *vpt_vq_get_buf(struct virtqueue *vq, unsigned int *len)
{
pr_info(%s: vq=0x%p\n, __func__, vq);
return NULL;
}
static void vpt_vq_kick(struct virtqueue *vq)
{
pr_info(%s: vq=0x%p\n, __func__, vq);
}
static void vpt_vq_disable_cb(struct virtqueue *vq)
{
pr_info(%s: vq=0x%p\n, __func__, vq);
}
static bool vpt_vq_enable_cb(struct virtqueue *vq)
{
pr_info(%s: vq=0x%p\n, __func__,
Re: [PATCH 02/11][v3] async_tx: add support for asynchronous GF multiplication
On Mon, Jan 12, 2009 at 5:43 PM, Yuri Tikhonov y...@emcraft.com wrote:
This adds support for doing asynchronous GF multiplication by adding
four additional functions to async_tx API:
async_pq() does simultaneous XOR of sources and XOR of sources
GF-multiplied by given coefficients.
async_pq_zero_sum() checks if results of calculations match given
ones.
async_gen_syndrome() does sumultaneous XOR and R/S syndrome of sources.
async_syndrome_zerosum() checks if results of XOR/syndrome calculation
matches given ones.
Latter two functions just use async_pq() with the approprite coefficients
in asynchronous case but have significant optimizations if synchronous
case.
To support this API dmaengine driver should set DMA_PQ and
DMA_PQ_ZERO_SUM capabilities and provide device_prep_dma_pq and
device_prep_dma_pqzero_sum methods in dma_device structure.
Signed-off-by: Yuri Tikhonov y...@emcraft.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
crypto/async_tx/Kconfig |4 +
crypto/async_tx/Makefile|1 +
crypto/async_tx/async_pq.c | 615
+++
crypto/async_tx/async_xor.c |2 +-
include/linux/async_tx.h| 46 +++-
include/linux/dmaengine.h | 30 ++-
6 files changed, 693 insertions(+), 5 deletions(-)
create mode 100644 crypto/async_tx/async_pq.c
diff --git a/crypto/async_tx/Kconfig b/crypto/async_tx/Kconfig
index d8fb391..cb6d731 100644
--- a/crypto/async_tx/Kconfig
+++ b/crypto/async_tx/Kconfig
@@ -14,3 +14,7 @@ config ASYNC_MEMSET
tristate
select ASYNC_CORE
+config ASYNC_PQ
+ tristate
+ select ASYNC_CORE
+
diff --git a/crypto/async_tx/Makefile b/crypto/async_tx/Makefile
index 27baa7d..1b99265 100644
--- a/crypto/async_tx/Makefile
+++ b/crypto/async_tx/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_ASYNC_CORE) += async_tx.o
obj-$(CONFIG_ASYNC_MEMCPY) += async_memcpy.o
obj-$(CONFIG_ASYNC_MEMSET) += async_memset.o
obj-$(CONFIG_ASYNC_XOR) += async_xor.o
+obj-$(CONFIG_ASYNC_PQ) += async_pq.o
diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
new file mode 100644
index 000..5871651
--- /dev/null
+++ b/crypto/async_tx/async_pq.c
@@ -0,0 +1,615 @@
+/*
+ * Copyright(c) 2007 Yuri Tikhonov y...@emcraft.com
+ *
+ * Developed for DENX Software Engineering GmbH
+ *
+ * Asynchronous GF-XOR calculations ASYNC_TX API.
+ *
+ * based on async_xor.c code written by:
+ * Dan Williams dan.j.willi...@intel.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along
with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution in
the
+ * file called COPYING.
+ */
+#include linux/kernel.h
+#include linux/interrupt.h
+#include linux/dma-mapping.h
+#include linux/raid/xor.h
+#include linux/async_tx.h
+
+#include ../drivers/md/raid6.h
+
+/**
+ * The following static variables are used in cases of synchronous
+ * zero sum to save the values to check. Two pages used for zero sum and
+ * the third one is for dumb P destination when calling gen_syndrome()
+ */
+static spinlock_t spare_lock;
+static struct page *spare_pages[3];
+
+/**
+ * do_async_pq - asynchronously calculate P and/or Q
+ */
+static struct dma_async_tx_descriptor *
+do_async_pq(struct dma_chan *chan, struct page **blocks, unsigned char *scfs,
+ unsigned int offset, int src_cnt, size_t len, enum async_tx_flags
flags,
+ struct dma_async_tx_descriptor *depend_tx,
+ dma_async_tx_callback cb_fn, void *cb_param)
+{
+ struct dma_device *dma = chan-device;
+ dma_addr_t dma_dest[2], dma_src[src_cnt];
+ struct dma_async_tx_descriptor *tx = NULL;
+ dma_async_tx_callback _cb_fn;
+ void *_cb_param;
+ unsigned char *scf = NULL;
+ int i, src_off = 0;
+ unsigned short pq_src_cnt;
+ enum async_tx_flags async_flags;
+ enum dma_ctrl_flags dma_flags = 0;
+
+ /* If we won't handle src_cnt in one shot, then the following
+* flag(s) will be set only on the first pass of prep_dma
+*/
+ if (flags ASYNC_TX_PQ_ZERO_P)
+ dma_flags |= DMA_PREP_ZERO_P;
+ if (flags ASYNC_TX_PQ_ZERO_Q)
+ dma_flags |=
Re: [PATCH 03/11][v3] async_tx: add support for asynchronous RAID6 recovery operations
On Mon, Jan 12, 2009 at 5:43 PM, Yuri Tikhonov y...@emcraft.com wrote:
+ /* (2) Calculate Q+Qxy */
+ lptrs[0] = ptrs[failb];
+ lptrs[1] = ptrs[disks-1];
+ lptrs[2] = NULL;
+ tx = async_pq(lptrs, NULL, 0, 1, bytes, ASYNC_TX_DEP_ACK,
+ tx, NULL, NULL);
+
+ /* (3) Calculate P+Pxy */
+ lptrs[0] = ptrs[faila];
+ lptrs[1] = ptrs[disks-2];
+ lptrs[2] = NULL;
+ tx = async_pq(lptrs, NULL, 0, 1, bytes, ASYNC_TX_DEP_ACK,
+ tx, NULL, NULL);
+
These two calls convinced me that ASYNC_TX_PQ_ZERO_{P,Q} need to go.
A 1-source async_pq operation does not make sense. These should be:
/* (2) Calculate Q+Qxy */
lptrs[0] = ptrs[disks-1];
lptrs[1] = ptrs[failb];
tx = async_xor(lptrs[0], lptrs, 0, 2, bytes,
ASYNC_TX_XOR_DROP_DST|ASYNC_TX_DEP_ACK, tx, NULL, NULL);
/* (3) Calculate P+Pxy */
lptrs[0] = ptrs[disks-2];
lptrs[1] = ptrs[faila];
tx = async_xor(lptrs[0], lptrs, 0, 2, bytes,
ASYNC_TX_XOR_DROP_DST|ASYNC_TX_DEP_ACK, tx, NULL, NULL);
Regards,
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ADS5121 how to use /dev/ttyPSC
Stefan Strobl wrote: Hi I'm new to Kernel 2.6 and OF. I'm using a ADS5121 board with kernel from denx (ads5121 branch from linux-2.6-denx). According to my dts file both PSC3 and PSC4 should be accessible through /dev/ttyPSC0 and /dev/ttyPSC1 respectively. When I simply try to run: $ echo Hello /dev/ttyPSC* I can't see any data coming out from the ports. Are you sending it to just one of them at a time and just abbreviating your mail here to include both with a *, or are you really putting that asterisk in there when you test? And when trying to initialize the ports using termios commands I'm getting the Error Inappropriate ioctl for device. You're doing this manually or with an application? But I can see the driver ttyPSC with major 204 in /proc/devices and I can also open the device successfully. I am also able to configure either port as CONSOLE in U-Boot so the Hardware is ok. So you're getting debug output (udbg type stuff) on them? -- Matt Sealey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: is_hugepage_only_range() must account for both 4kB and 64kB slices
On Wed, 2009-01-14 at 13:09 -0600, Dave Kleikamp wrote:
powerpc: is_hugepage_only_range() must account for both 4kB and 64kB slices
The subpage_prot syscall fails on second and subsequent calls for a given
region, because is_hugepage_only_range() is mis-identifying the 4 kB
slices when the process has a 64 kB page size.
Signed-off-by: Dave Kleikamp sha...@linux.vnet.ibm.com
Cc: Paul Mackerras pau...@samba.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Looks good. I'll put that in for .29
Cheers,
Ben.
diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
index db44e02..ba51948 100644
--- a/arch/powerpc/mm/slice.c
+++ b/arch/powerpc/mm/slice.c
@@ -710,9 +710,18 @@ int is_hugepage_only_range(struct mm_struct *mm,
unsigned long addr,
unsigned long len)
{
struct slice_mask mask, available;
+ unsigned int psize = mm-context.user_psize;
mask = slice_range_to_mask(addr, len);
- available = slice_mask_for_size(mm, mm-context.user_psize);
+ available = slice_mask_for_size(mm, psize);
+#ifdef CONFIG_PPC_64K_PAGES
+ /* We need to account for 4k slices too */
+ if (psize == MMU_PAGE_64K) {
+ struct slice_mask compat_mask;
+ compat_mask = slice_mask_for_size(mm, MMU_PAGE_4K);
+ or_mask(available, compat_mask);
+ }
+#endif
#if 0 /* too verbose */
slice_dbg(is_hugepage_only_range(mm=%p, addr=%lx, len=%lx)\n,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 11/11][v2] ppc440spe-adma: ADMA driver for PPC440SP(e) systems
Hello Yuri,
On Tue, Jan 13, 2009 at 03:43:55AM +0300, Yuri Tikhonov wrote:
Adds the platform device definitions and the architecture specific support
routines for the ppc440spe adma driver.
Any board equipped with PPC440SP(e) controller may utilize this driver.
Signed-off-by: Yuri Tikhonov y...@emcraft.com
Signed-off-by: Ilya Yanok ya...@emcraft.com
---
Quite complex and interesting driver, I must say.
Have you thought about splitting ppc440spe-adma.c into multiple
files, btw?
A few comments down below...
[...]
+typedef struct ppc440spe_adma_device {
Please avoid typedefs.
[...]
+/*
+ * Descriptor of allocated CDB
+ */
+typedef struct {
+ dma_cdb_t *vaddr; /* virtual address of CDB */
+ dma_addr_t paddr; /* physical address of CDB */
+ /*
+ * Additional fields
+ */
+ struct list_headlink; /* link in processing list */
+ u32 status; /* status of the CDB */
+ /* status bits: */
+ #define DMA_CDB_DONE(10) /* CDB processing competed */
+ #define DMA_CDB_CANCEL (11) /* waiting thread was interrupted */
+} dma_cdbd_t;
It seems there are no users of this struct.
[...]
+typedef struct {
+ xor_cb_t*vaddr;
+ dma_addr_t paddr;
+
+ /*
+ * Additional fields
+ */
+ struct list_headlink; /* link to processing CBs */
+ u32 status; /* status of the CB */
+ /* status bits: */
+ #define XOR_CB_DONE (10) /* CB processing competed */
+ #define XOR_CB_CANCEL (11) /* waiting thread was interrupted */
+#if 0
+ #define XOR_CB_STALLOC (12) /* CB allocated statically */
+#endif
Dead code.
[...]
+static void ppc440spe_configure_raid_devices(void)
+{
+ void *fifo_buf;
+ volatile i2o_regs_t *i2o_reg;
+ volatile dma_regs_t *dma_reg0, *dma_reg1;
+ volatile xor_regs_t *xor_reg;
+ u32 mask;
+
+ /*
+ * Map registers and allocate fifo buffer
+ */
+ if (!(i2o_reg = ioremap(I2O_MMAP_BASE, I2O_MMAP_SIZE))) {
+ printk(KERN_ERR I2O registers mapping failed.\n);
+ return;
+ }
i2o_reg = ioremap(I2O_MMAP_BASE, I2O_MMAP_SIZE);
if (!i20_reg)
...;
would look better.
+ if (!(dma_reg0 = ioremap(DMA0_MMAP_BASE, DMA_MMAP_SIZE))) {
+ printk(KERN_ERR DMA0 registers mapping failed.\n);
+ goto err1;
+ }
+ if (!(dma_reg1 = ioremap(DMA1_MMAP_BASE, DMA_MMAP_SIZE))) {
+ printk(KERN_ERR DMA1 registers mapping failed.\n);
+ goto err2;
+ }
+ if (!(xor_reg = ioremap(XOR_MMAP_BASE,XOR_MMAP_SIZE))) {
+ printk(KERN_ERR XOR registers mapping failed.\n);
+ goto err3;
+ }
[...]
+static struct platform_device *ppc440spe_devs[] __initdata = {
+ ppc440spe_dma_0_channel,
+ ppc440spe_dma_1_channel,
+ ppc440spe_xor_channel,
+};
+
+static int __init ppc440spe_register_raid_devices(void)
+{
+ ppc440spe_configure_raid_devices();
+ platform_add_devices(ppc440spe_devs, ARRAY_SIZE(ppc440spe_devs));
+
+ return 0;
+}
+
+arch_initcall(ppc440spe_register_raid_devices);
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index e34b064..19df08c 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -62,6 +62,19 @@ config MV_XOR
---help---
Enable support for the Marvell XOR engine.
+config AMCC_PPC440SPE_ADMA
+ tristate AMCC PPC440SPe ADMA support
It's a tristate, but module_exit() disabled with #if 0...
[...]
+/**
+ * Command (Descriptor) Blocks low-level routines
+
**/
+/**
+ * ppc440spe_desc_init_interrupt - initialize the descriptor for INTERRUPT
+ * pseudo operation
+ */
+static inline void ppc440spe_desc_init_interrupt (ppc440spe_desc_t *desc,
+ ppc440spe_ch_t *chan)
+{
Isn't this function way too big for inline?
+ xor_cb_t *p;
+
+ switch (chan-device-id) {
+ case PPC440SPE_XOR_ID:
+ p = desc-hw_desc;
+ memset (desc-hw_desc, 0, sizeof(xor_cb_t));
+ /* NOP with Command Block Complete Enable */
+ p-cbc = XOR_CBCR_CBCE_BIT;
+ break;
+ case PPC440SPE_DMA0_ID:
+ case PPC440SPE_DMA1_ID:
+ memset (desc-hw_desc, 0, sizeof(dma_cdb_t));
+ /* NOP with interrupt */
+ set_bit(PPC440SPE_DESC_INT, desc-flags);
+ break;
+ default:
+ printk(KERN_ERR Unsupported id %d in %s\n, chan-device-id,
+ __func__);
+ break;
+ }
+}
+
+/**
+ * ppc440spe_desc_init_null_xor - initialize the descriptor for NULL XOR
+ * pseudo operation
+ */
Re: [PATCH] mmc: Add driver for Freescale eSDHC controllers
On Jan 14, 2009, at 1:46 PM, Anton Vorontsov wrote: From: Xie Xiaobo x@freescale.com This patch adds support for the Freescale Enhanced Secure Digital Host Controller Interface as found in some Freescale PowerPC microprocessors (e.g. MPC837x SOCs). Signed-off-by: Xie Xiaobo x@freescale.com Signed-off-by: Konjin Lai konjin@freescale.com Signed-off-by: Joe D'Abbraccio Joe.D'abbrac...@freescale.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- drivers/mmc/host/Kconfig |9 + drivers/mmc/host/Makefile |1 + drivers/mmc/host/esdhc.c | 1321 + drivers/mmc/host/esdhc.h | 255 + 4 files changed, 1586 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/host/esdhc.c create mode 100644 drivers/mmc/host/esdhc.h Want to work some device tree docs for this. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/fs_enet: Add missing irq free in error path.
From: Kumar Gala ga...@kernel.crashing.org Date: Tue, 13 Jan 2009 10:28:15 -0600 On Oct 27, 2008, at 4:46 PM, Mike Ditto wrote: If something goes wrong attaching to phy driver, we weren't freeing the IRQ. Signed-off-by: Mike Ditto mdi...@consentry.com ... This seems to have gotten lost in the shuffle. Can you please apply. The netdev patchwork never saw it for some reason. Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Add init_dummy_netdev() and fix EMAC driver using it
From: Geert Uytterhoeven geert.uytterhoe...@sonycom.com Date: Wed, 14 Jan 2009 11:00:05 +0100 (CET) On Wed, 14 Jan 2009, Benjamin Herrenschmidt wrote: This adds an init_dummy_netdev() function that gets a network device structure (allocation and lifetime entirely under caller's control) and initialize the minimum amount of fields so it can be used to schedule NAPI polls without registering a full blown interface. This is to be used by drivers that need to tie several hardware interfaces to a single NAPI poll scheduler due to HW limitations. It also updates the ibm_newemac driver to use that, this fixing the oops on 2.6.29 due to passing NULL as dev to netif_napi_add() Symbol is exported GPL only a I don't think we want binary drivers doing that sort of acrobatics (if we want them at all). Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org Thanks, this fixed my Sequoia! Tested-by: Geert Uytterhoeven geert.uytterhoe...@sonycom.com Applied, thanks everyone. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
interrupt number assignment dts file help
I am trying to configure a dts file for the pci subsystem of a MPC8540 based
system.
I am expecting (hoping) that the value specified in the interrupts property
(98 in this example)
will be used as the virtual interrupt number and that I can later do a
request_irq using that number.
kernel: 2.6.26.3
The board level configuration is:
ADR29 connected to IDSEL
using INTA# only
The PCI interrupt is connected to external IRQ2
What I see is that inside irq_create_mapping, a call to irq_find_mapping
produces a null virq,
so irq_alloc_virt is called and comes back with x12. Can I assign the
number to 98 (x62)
using the dts? Any help would be greatly appreciated.
Thanks
Ken
pci0: p...@fdf08000 {
cell-index = 0;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x1d */
0xe800 0x0 0x0 0x1 mpic 0x2 0x1
;
interrupt-parent = mpic;
interrupts = 98 2;
bus-range = 0 0;
ranges = 0x200 0x0 0x8000 0x8000 0x0 0x2000
0x100 0x0 0x0 0xe200 0x0 0x10;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 0xfdf08000 0x1000;
compatible = fsl,mpc8540-pcix, fsl,mpc8540-pci;
device_type = pci;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: interrupt number assignment dts file help
On Jan 14, 2009, at 11:15 PM, Ken Williams wrote:
I am trying to configure a dts file for the pci subsystem of a
MPC8540 based system.
I am expecting (hoping) that the value specified in the interrupts
property (98 in this example)
will be used as the virtual interrupt number and that I can later do
a request_irq using that number.
The .dts deals with physical interrupt numbers. Virtual IRQs is a
linux concept.
kernel: 2.6.26.3
The board level configuration is:
ADR29 connected to IDSEL
using INTA# only
The PCI interrupt is connected to external IRQ2
What I see is that inside irq_create_mapping, a call to
irq_find_mapping produces a null virq,
so irq_alloc_virt is called and comes back with x12. Can I assign
the number to 98 (x62)
using the dts? Any help would be greatly appreciated.
Do you want INTA# or the PCI error interrupt?
I'm guessing INT A#.
Here's an example from the mpc8540ads.dts:
pci0: p...@e0008000 {
cell-index = 0;
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
...
/* IDSEL 0x03 */
0x1800 0x0 0x0 0x1 mpic 0x4 0x1
0x1800 0x0 0x0 0x2 mpic 0x1 0x1
0x1800 0x0 0x0 0x3 mpic 0x2 0x1
0x1800 0x0 0x0 0x4 mpic 0x3 0x1
...
So the interrupt-map here deals w/PCI INTA# to INTD#.
(0x1800 0x0 0x0) (0x1) mpic ((0x4) (0x1))
(pci address) (intA) pic-handle (pic HW IRQ) (irq sense info)
So to decode the example we have for IDSEL 0x03:
INTA: irq 4
INTB: irq 1
INTC: irq 2
INTD: irq 3
If you have a proper PCI driver in linux you shouldn't have to deal
with virtual IRQs at all.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mmc: Add driver for Freescale eSDHC controllers
On Thu, 15 Jan 2009 02:56:05 +0300 Anton Vorontsov avoront...@ru.mvista.com wrote: Ah. I wonder why Freescale just didn't write some patches for sdhci, but copied the code instead... Probably because it was quicker. Samsung did the same thing, but now Ben Dooks has patches to properly support it via sdhci. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] mmc: Add driver for Freescale eSDHC controllers
Probably because it was quicker. Samsung did the same thing, but now Ben Dooks has patches to properly support it via sdhci. Pierre, What samsung driver are you talking? Could you point it to me? Thanks, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fsldma: print correct IRQ on mpc83xx
Timur Tabi wrote: Peter Korsgaard wrote: The only minor issues we have is the cosmetic problem of the driver printing NO_IRQ (E.G. this patch), and the driver calling free_irq(NO_IRQ) (E.G. the other patch I sent today) in the release path. Ok, I understand. ACK on the patches. Ok, Li Yang and Zhang Wei have been silent recently on fsldma patches. Applied to async_tx.git/fixes Thanks, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mmc: Add driver for Freescale eSDHC controllers
On Thu, 15 Jan 2009 14:11:09 +0800 Liu Dave dave...@freescale.com wrote: Probably because it was quicker. Samsung did the same thing, but now Ben Dooks has patches to properly support it via sdhci. Pierre, What samsung driver are you talking? Could you point it to me? I'm afraid I haven't seen any readily available sources for their driver. If you meant Ben's version, you can find the latest revision here: http://marc.info/?t=12282326615 Unfortunately marc.info didn't sort out the threading, but you should be able to find all the patches there or some other LKML archive. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: Remove unused ppc64_terminate_msg()
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/include/asm/machdep.h |2 --
arch/powerpc/kernel/setup_64.c |7 ---
2 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 2740c44..6c34a0d 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -327,8 +327,6 @@ extern void __devinit smp_generic_take_timebase(void);
*/
/* Print a boot progress message. */
void ppc64_boot_msg(unsigned int src, const char *msg);
-/* Print a termination message (print only -- does not stop the kernel) */
-void ppc64_terminate_msg(unsigned int src, const char *msg);
static inline void log_error(char *buf, unsigned int err_type, int fatal)
{
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 2d34196..73e16e2 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -578,13 +578,6 @@ void ppc64_boot_msg(unsigned int src, const char *msg)
printk([boot]%04x %s\n, src, msg);
}
-/* Print a termination message (print only -- does not stop the kernel) */
-void ppc64_terminate_msg(unsigned int src, const char *msg)
-{
- ppc64_do_msg(PPC64_LINUX_FUNCTION|PPC64_TERM_MESSAGE|src, msg);
- printk([terminate]%04x %s\n, src, msg);
-}
-
void cpu_die(void)
{
if (ppc_md.cpu_die)
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: Add ppc_progress() wrapper
There's quite a lot of code that does:
if (ppc_md.progress)
ppc_md.progress(...)
So move that idiom into a wrapper. Having a wrapper also allows us
to have a fallback to printk if no progress routine is specified.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/include/asm/machdep.h |2 ++
arch/powerpc/kernel/setup-common.c |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 6c34a0d..9e4ab07 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -328,6 +328,8 @@ extern void __devinit smp_generic_take_timebase(void);
/* Print a boot progress message. */
void ppc64_boot_msg(unsigned int src, const char *msg);
+extern void ppc_progress(char *msg, unsigned short code);
+
static inline void log_error(char *buf, unsigned int err_type, int fatal)
{
if (ppc_md.log_error)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 705fc4b..cc4997b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -669,3 +669,11 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+void ppc_progress(char *msg, unsigned short code)
+{
+ if (ppc_md.progress)
+ ppc_md.progress(msg, code);
+ else
+ printk(KERN_DEBUG *** %04x : %s\n, code, msg ? msg : );
+}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] powerpc: Replace ppc_md.progress() uses with ppc_progress()
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/kernel/setup_32.c| 11 +--
arch/powerpc/mm/init_32.c | 15 +--
arch/powerpc/mm/ppc_mmu_32.c |8
arch/powerpc/platforms/52xx/efika.c |3 +--
arch/powerpc/platforms/52xx/lite5200.c|3 +--
arch/powerpc/platforms/52xx/mpc5200_simple.c |3 +--
arch/powerpc/platforms/82xx/ep8248e.c |6 ++
arch/powerpc/platforms/82xx/mgcoge.c |6 ++
arch/powerpc/platforms/82xx/mpc8272_ads.c |6 ++
arch/powerpc/platforms/82xx/pq2fads.c |6 ++
arch/powerpc/platforms/83xx/asp834x.c |3 +--
arch/powerpc/platforms/83xx/mpc831x_rdb.c |3 +--
arch/powerpc/platforms/83xx/mpc832x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc832x_rdb.c |3 +--
arch/powerpc/platforms/83xx/mpc834x_itx.c |3 +--
arch/powerpc/platforms/83xx/mpc834x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc836x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc836x_rdk.c |3 +--
arch/powerpc/platforms/83xx/mpc837x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc837x_rdb.c |3 +--
arch/powerpc/platforms/83xx/sbc834x.c |3 +--
arch/powerpc/platforms/85xx/ksi8560.c |3 +--
arch/powerpc/platforms/85xx/mpc8536_ds.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_ads.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_mds.c |3 +--
arch/powerpc/platforms/85xx/sbc8548.c |3 +--
arch/powerpc/platforms/85xx/sbc8560.c |3 +--
arch/powerpc/platforms/85xx/stx_gp3.c |3 +--
arch/powerpc/platforms/85xx/tqm85xx.c |3 +--
arch/powerpc/platforms/86xx/mpc8610_hpcd.c|3 +--
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|3 +--
arch/powerpc/platforms/86xx/sbc8641d.c|3 +--
arch/powerpc/platforms/chrp/setup.c |5 ++---
arch/powerpc/platforms/embedded6xx/holly.c|6 ++
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |7 +++
arch/powerpc/platforms/powermac/smp.c | 18 --
arch/powerpc/platforms/pseries/setup.c|4 ++--
39 files changed, 70 insertions(+), 119 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e1ca74..a1caaa9 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -139,8 +139,7 @@ notrace void __init machine_init(unsigned long dt_ptr)
cpu_has_feature(CPU_FTR_CAN_NAP))
ppc_md.power_save = e500_idle;
#endif
- if (ppc_md.progress)
- ppc_md.progress(id mach(): done, 0x200);
+ ppc_progress(id mach(): done, 0x200);
}
#ifdef CONFIG_BOOKE_WDT
@@ -219,8 +218,7 @@ EXPORT_SYMBOL(nvram_sync);
int __init ppc_init(void)
{
/* clear the progress line */
- if (ppc_md.progress)
- ppc_md.progress( , 0x);
+ ppc_progress( , 0x);
/* call platform init */
if (ppc_md.init != NULL) {
@@ -322,7 +320,7 @@ void __init setup_arch(char **cmdline_p)
/* set up the bootmem stuff with available memory */
do_init_bootmem();
- if ( ppc_md.progress ) ppc_md.progress(setup_arch: bootmem, 0x3eab);
+ ppc_progress(setup_arch: bootmem, 0x3eab);
#ifdef CONFIG_DUMMY_CONSOLE
conswitchp = dummy_con;
@@ -330,7 +328,8 @@ void __init setup_arch(char **cmdline_p)
if (ppc_md.setup_arch)
ppc_md.setup_arch();
- if ( ppc_md.progress ) ppc_md.progress(arch: exit, 0x3eab);
+
+ ppc_progress(arch: exit, 0x3eab);
paging_init();
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 666a5e8..d1bd21e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -119,8 +119,7 @@ void MMU_setup(void)
*/
void __init MMU_init(void)
{
- if (ppc_md.progress)
- ppc_md.progress(MMU:enter, 0x111);
+ ppc_progress(MMU:enter, 0x111);
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
@@ -159,13 +158,11 @@ void __init MMU_init(void)
}
/* Initialize the MMU hardware */
- if (ppc_md.progress)
- ppc_md.progress(MMU:hw init, 0x300);
+ ppc_progress(MMU:hw init, 0x300);
MMU_init_hw();
/* Map in all of RAM starting at KERNELBASE */
- if (ppc_md.progress)
- ppc_md.progress(MMU:mapin, 0x301);
+ ppc_progress(MMU:mapin, 0x301);
mapin_ram();
#ifdef CONFIG_HIGHMEM
@@ -176,11 +173,9
[PATCH 4/4] powerpc: Remove printk-only progress implementations
Several platforms implement ppc_md.progress as a simple printk. Now that
we have the ppc_progress() wrapper which falls back to printk if no
routine is specified, we can remove all the printk-only progress
implementations.
This leaves us with iSeries_progress(), rtas_progress() and udbg_progress().
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/cell/celleb_setup.c |7 ---
arch/powerpc/platforms/cell/qpace_setup.c |6 --
arch/powerpc/platforms/cell/setup.c|6 --
arch/powerpc/platforms/maple/setup.c |7 ---
arch/powerpc/platforms/pasemi/setup.c |7 ---
arch/powerpc/platforms/ps3/setup.c |6 --
6 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_setup.c
b/arch/powerpc/platforms/cell/celleb_setup.c
index 07c234f..5a5d9f3 100644
--- a/arch/powerpc/platforms/cell/celleb_setup.c
+++ b/arch/powerpc/platforms/cell/celleb_setup.c
@@ -87,11 +87,6 @@ static int __init celleb_machine_type_hack(char *ptr)
__setup(celleb_machine_type_hack=, celleb_machine_type_hack);
-static void celleb_progress(char *s, unsigned short hex)
-{
- printk(*** %04x : %s\n, hex, s ? s : );
-}
-
static void __init celleb_setup_arch_common(void)
{
/* init to some ~sane value until calibrate_delay() runs */
@@ -213,7 +208,6 @@ define_machine(celleb_beat) {
.get_rtc_time = beat_get_rtc_time,
.set_rtc_time = beat_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .progress = celleb_progress,
.power_save = beat_power_save,
.nvram_size = beat_nvram_get_size,
.nvram_read = beat_nvram_read,
@@ -240,7 +234,6 @@ define_machine(celleb_native) {
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .progress = celleb_progress,
.pci_probe_mode = celleb_pci_probe_mode,
.pci_setup_phb = celleb_setup_phb,
.init_IRQ = celleb_init_IRQ_native,
diff --git a/arch/powerpc/platforms/cell/qpace_setup.c
b/arch/powerpc/platforms/cell/qpace_setup.c
index be84e6a..6a37361 100644
--- a/arch/powerpc/platforms/cell/qpace_setup.c
+++ b/arch/powerpc/platforms/cell/qpace_setup.c
@@ -56,11 +56,6 @@ static void qpace_show_cpuinfo(struct seq_file *m)
of_node_put(root);
}
-static void qpace_progress(char *s, unsigned short hex)
-{
- printk(*** %04x : %s\n, hex, s ? s : );
-}
-
static int __init qpace_publish_devices(void)
{
int node;
@@ -142,7 +137,6 @@ define_machine(qpace) {
.halt = rtas_halt,
.get_boot_time = rtas_get_boot_time,
.calibrate_decr = generic_calibrate_decr,
- .progress = qpace_progress,
.init_IRQ = iic_init_IRQ,
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
diff --git a/arch/powerpc/platforms/cell/setup.c
b/arch/powerpc/platforms/cell/setup.c
index 5930536..ca2661e 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -76,11 +76,6 @@ static void cell_show_cpuinfo(struct seq_file *m)
of_node_put(root);
}
-static void cell_progress(char *s, unsigned short hex)
-{
- printk(*** %04x : %s\n, hex, s ? s : );
-}
-
static void cell_fixup_pcie_rootcomplex(struct pci_dev *dev)
{
struct pci_controller *hose;
@@ -285,7 +280,6 @@ define_machine(cell) {
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .progress = cell_progress,
.init_IRQ = cell_init_irq,
.pci_setup_phb = cell_setup_phb,
};
diff --git a/arch/powerpc/platforms/maple/setup.c
b/arch/powerpc/platforms/maple/setup.c
index bfd60e4..92f8eef 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -288,12 +288,6 @@ static void __init maple_init_IRQ(void)
of_node_put(root);
}
-static void __init maple_progress(char *s, unsigned short hex)
-{
- printk(*** %04x : %s\n, hex, s ? s : );
-}
-
-
/*
* Called very early, MMU is off, device-tree isn't unflattened
*/
@@ -332,6 +326,5 @@ define_machine(maple) {
.set_rtc_time = maple_set_rtc_time,
.get_rtc_time = maple_get_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .progress = maple_progress,
.power_save = power4_idle,
};
diff --git a/arch/powerpc/platforms/pasemi/setup.c
b/arch/powerpc/platforms/pasemi/setup.c
index c64fb5b..bcc1ac8 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++
[PATCH 1/2] powerpc: Allow debugging of LMBs with lmb=debug
The lmb debugging can be turned on at boottime with lmb=debug on the command line. However on powerpc that doesn't work, because we don't necessarily call lmb_dump_all(). So always call lmb_dump_all() after lmb_analyze(), no output is generated unless lmb=debug is found on the command line. Signed-off-by: Michael Ellerman mich...@ellerman.id.au --- arch/powerpc/kernel/prom.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index c09cffa..045277b 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -1070,11 +1070,6 @@ static void __init early_reserve_mem(void) DBG(reserving: %llx - %llx\n, base, size); lmb_reserve(base, size); } - -#if 0 - DBG(memory reserved, lmbs :\n); - lmb_dump_all(); -#endif } #ifdef CONFIG_PHYP_DUMP @@ -1216,6 +1211,7 @@ void __init early_init_devtree(void *params) lmb_enforce_memory_limit(limit); lmb_analyze(); + lmb_dump_all(); DBG(Phys. mem: %lx\n, lmb_phys_mem_size()); -- 1.5.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] lmb: Rework lmb_dump_all() output
The lmb_dump_all() output didn't include the RMO size, which is
interesting on powerpc. The output was also a bit spacey and not well
aligned, and didn't show you the end addresses.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
lib/lmb.c | 42 +-
1 files changed, 21 insertions(+), 21 deletions(-)
DaveM, if you like we could make the RMO display conditional on it being
non-zero, which would hide it on sparc presumably.
Old output:
lmb_dump_all:
memory.cnt= 0x1
memory.size = 0x8000
memory.region[0x0].base = 0x0
.size = 0x8000
reserved.cnt = 0x3
reserved.size = 0x8000
reserved.region[0x0].base = 0x0
.size = 0xea2000
reserved.region[0x1].base = 0x2aa6000
.size = 0xc000
reserved.region[0x2].base = 0x76a1000
.size = 0x95f000
New output:
LMB configuration:
rmo_size= 0x800
memory.size = 0x8000
memory.cnt = 0x1
memory[0x0]0x - 0x7fff, 0x8000 bytes
reserved.cnt = 0x3
reserved[0x0] 0x - 0x00ea1fff, 0xea2000 bytes
reserved[0x1] 0x02aa6000 - 0x02ab1fff, 0xc000 bytes
reserved[0x2] 0x076a1000 - 0x07ff, 0x95f000 bytes
diff --git a/lib/lmb.c b/lib/lmb.c
index 97e5470..e4a6482 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -29,33 +29,33 @@ static int __init early_lmb(char *p)
}
early_param(lmb, early_lmb);
-void lmb_dump_all(void)
+static void lmb_dump(struct lmb_region *region, char *name)
{
- unsigned long i;
+ unsigned long long base, size;
+ int i;
+
+ pr_info( %s.cnt = 0x%lx\n, name, region-cnt);
+
+ for (i = 0; i region-cnt; i++) {
+ base = region-region[i].base;
+ size = region-region[i].size;
+
+ pr_info( %s[0x%x]\t0x%016llx - 0x%016llx, 0x%llx bytes\n,
+ name, i, base, base + size - 1, size);
+ }
+}
+void lmb_dump_all(void)
+{
if (!lmb_debug)
return;
- pr_info(lmb_dump_all:\n);
- pr_info(memory.cnt = 0x%lx\n, lmb.memory.cnt);
- pr_info(memory.size = 0x%llx\n,
- (unsigned long long)lmb.memory.size);
- for (i=0; i lmb.memory.cnt ;i++) {
- pr_info(memory.region[0x%lx].base = 0x%llx\n,
- i, (unsigned long long)lmb.memory.region[i].base);
- pr_info( .size = 0x%llx\n,
- (unsigned long long)lmb.memory.region[i].size);
- }
+ pr_info(LMB configuration:\n);
+ pr_info( rmo_size= 0x%llx\n, (unsigned long long)lmb.rmo_size);
+ pr_info( memory.size = 0x%llx\n, (unsigned long long)lmb.memory.size);
- pr_info(reserved.cnt = 0x%lx\n, lmb.reserved.cnt);
- pr_info(reserved.size= 0x%llx\n,
- (unsigned long long)lmb.memory.size);
- for (i=0; i lmb.reserved.cnt ;i++) {
- pr_info(reserved.region[0x%lx].base = 0x%llx\n,
- i, (unsigned long long)lmb.reserved.region[i].base);
- pr_info( .size = 0x%llx\n,
- (unsigned long long)lmb.reserved.region[i].size);
- }
+ lmb_dump(lmb.memory, memory);
+ lmb_dump(lmb.reserved, reserved);
}
static unsigned long lmb_addrs_overlap(u64 base1, u64 size1, u64 base2,
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: Allow debugging of LMBs with lmb=debug
From: Michael Ellerman mich...@ellerman.id.au Date: Thu, 15 Jan 2009 17:46:01 +1100 (EST) The lmb debugging can be turned on at boottime with lmb=debug on the command line. However on powerpc that doesn't work, because we don't necessarily call lmb_dump_all(). So always call lmb_dump_all() after lmb_analyze(), no output is generated unless lmb=debug is found on the command line. Signed-off-by: Michael Ellerman mich...@ellerman.id.au Acked-by: David S. Miller da...@davemloft.net ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] lmb: Rework lmb_dump_all() output
From: Michael Ellerman mich...@ellerman.id.au Date: Thu, 15 Jan 2009 17:46:02 +1100 (EST) The lmb_dump_all() output didn't include the RMO size, which is interesting on powerpc. The output was also a bit spacey and not well aligned, and didn't show you the end addresses. Signed-off-by: Michael Ellerman mich...@ellerman.id.au Acked-by: David S. Miller da...@davemloft.net DaveM, if you like we could make the RMO display conditional on it being non-zero, which would hide it on sparc presumably. Not necessary. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH] mmc: Add driver for Freescale eSDHC controllers
I'm afraid I haven't seen any readily available sources for their driver. If you meant Ben's version, you can find the latest revision here: http://marc.info/?t=12282326615 Unfortunately marc.info didn't sort out the threading, but you should be able to find all the patches there or some other LKML archive. Thanks Pierre, That is my needs. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] powerpc: Add ppc_progress() wrapper
On Wed, Jan 14, 2009 at 11:43 PM, Michael Ellerman
mich...@ellerman.id.au wrote:
There's quite a lot of code that does:
if (ppc_md.progress)
ppc_md.progress(...)
So move that idiom into a wrapper. Having a wrapper also allows us
to have a fallback to printk if no progress routine is specified.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
Good idea.
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/include/asm/machdep.h |2 ++
arch/powerpc/kernel/setup-common.c |8
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index 6c34a0d..9e4ab07 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -328,6 +328,8 @@ extern void __devinit smp_generic_take_timebase(void);
/* Print a boot progress message. */
void ppc64_boot_msg(unsigned int src, const char *msg);
+extern void ppc_progress(char *msg, unsigned short code);
+
static inline void log_error(char *buf, unsigned int err_type, int fatal)
{
if (ppc_md.log_error)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 705fc4b..cc4997b 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -669,3 +669,11 @@ static int powerpc_debugfs_init(void)
}
arch_initcall(powerpc_debugfs_init);
#endif
+
+void ppc_progress(char *msg, unsigned short code)
+{
+ if (ppc_md.progress)
+ ppc_md.progress(msg, code);
+ else
+ printk(KERN_DEBUG *** %04x : %s\n, code, msg ? msg : );
+}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
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 3/4] powerpc: Replace ppc_md.progress() uses with ppc_progress()
On Wed, Jan 14, 2009 at 11:43 PM, Michael Ellerman
mich...@ellerman.id.au wrote:
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/powerpc/kernel/setup_32.c| 11 +--
arch/powerpc/mm/init_32.c | 15 +--
arch/powerpc/mm/ppc_mmu_32.c |8
arch/powerpc/platforms/52xx/efika.c |3 +--
arch/powerpc/platforms/52xx/lite5200.c|3 +--
arch/powerpc/platforms/52xx/mpc5200_simple.c |3 +--
arch/powerpc/platforms/82xx/ep8248e.c |6 ++
arch/powerpc/platforms/82xx/mgcoge.c |6 ++
arch/powerpc/platforms/82xx/mpc8272_ads.c |6 ++
arch/powerpc/platforms/82xx/pq2fads.c |6 ++
arch/powerpc/platforms/83xx/asp834x.c |3 +--
arch/powerpc/platforms/83xx/mpc831x_rdb.c |3 +--
arch/powerpc/platforms/83xx/mpc832x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc832x_rdb.c |3 +--
arch/powerpc/platforms/83xx/mpc834x_itx.c |3 +--
arch/powerpc/platforms/83xx/mpc834x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc836x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc836x_rdk.c |3 +--
arch/powerpc/platforms/83xx/mpc837x_mds.c |3 +--
arch/powerpc/platforms/83xx/mpc837x_rdb.c |3 +--
arch/powerpc/platforms/83xx/sbc834x.c |3 +--
arch/powerpc/platforms/85xx/ksi8560.c |3 +--
arch/powerpc/platforms/85xx/mpc8536_ds.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_ads.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 +
arch/powerpc/platforms/85xx/mpc85xx_ds.c |3 +--
arch/powerpc/platforms/85xx/mpc85xx_mds.c |3 +--
arch/powerpc/platforms/85xx/sbc8548.c |3 +--
arch/powerpc/platforms/85xx/sbc8560.c |3 +--
arch/powerpc/platforms/85xx/stx_gp3.c |3 +--
arch/powerpc/platforms/85xx/tqm85xx.c |3 +--
arch/powerpc/platforms/86xx/mpc8610_hpcd.c|3 +--
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c|3 +--
arch/powerpc/platforms/86xx/sbc8641d.c|3 +--
arch/powerpc/platforms/chrp/setup.c |5 ++---
arch/powerpc/platforms/embedded6xx/holly.c|6 ++
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c |7 +++
arch/powerpc/platforms/powermac/smp.c | 18 --
arch/powerpc/platforms/pseries/setup.c|4 ++--
39 files changed, 70 insertions(+), 119 deletions(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 9e1ca74..a1caaa9 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -139,8 +139,7 @@ notrace void __init machine_init(unsigned long dt_ptr)
cpu_has_feature(CPU_FTR_CAN_NAP))
ppc_md.power_save = e500_idle;
#endif
- if (ppc_md.progress)
- ppc_md.progress(id mach(): done, 0x200);
+ ppc_progress(id mach(): done, 0x200);
}
#ifdef CONFIG_BOOKE_WDT
@@ -219,8 +218,7 @@ EXPORT_SYMBOL(nvram_sync);
int __init ppc_init(void)
{
/* clear the progress line */
- if (ppc_md.progress)
- ppc_md.progress( , 0x);
+ ppc_progress( , 0x);
/* call platform init */
if (ppc_md.init != NULL) {
@@ -322,7 +320,7 @@ void __init setup_arch(char **cmdline_p)
/* set up the bootmem stuff with available memory */
do_init_bootmem();
- if ( ppc_md.progress ) ppc_md.progress(setup_arch: bootmem, 0x3eab);
+ ppc_progress(setup_arch: bootmem, 0x3eab);
#ifdef CONFIG_DUMMY_CONSOLE
conswitchp = dummy_con;
@@ -330,7 +328,8 @@ void __init setup_arch(char **cmdline_p)
if (ppc_md.setup_arch)
ppc_md.setup_arch();
- if ( ppc_md.progress ) ppc_md.progress(arch: exit, 0x3eab);
+
+ ppc_progress(arch: exit, 0x3eab);
paging_init();
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 666a5e8..d1bd21e 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -119,8 +119,7 @@ void MMU_setup(void)
*/
void __init MMU_init(void)
{
- if (ppc_md.progress)
- ppc_md.progress(MMU:enter, 0x111);
+ ppc_progress(MMU:enter, 0x111);
/* 601 can only access 16MB at the moment */
if (PVR_VER(mfspr(SPRN_PVR)) == 1)
@@ -159,13 +158,11 @@ void __init MMU_init(void)
}
/* Initialize the MMU hardware */
- if (ppc_md.progress)
- ppc_md.progress(MMU:hw init, 0x300);
+ ppc_progress(MMU:hw init, 0x300);
MMU_init_hw();
/* Map in all of RAM starting
Re: [PATCH 4/4] powerpc: Remove printk-only progress implementations
On Wed, Jan 14, 2009 at 11:43 PM, Michael Ellerman mich...@ellerman.id.au wrote: Several platforms implement ppc_md.progress as a simple printk. Now that we have the ppc_progress() wrapper which falls back to printk if no routine is specified, we can remove all the printk-only progress implementations. This leaves us with iSeries_progress(), rtas_progress() and udbg_progress(). Signed-off-by: Michael Ellerman mich...@ellerman.id.au Acked-by: Grant Likely grant.lik...@secretlab.ca -- 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
