date:20080919

 Grant == Grant Likely [EMAIL PROTECTED] writes:

Hi,

 Grant On Mon, Sep 15, 2008 at 08:53:53PM +0200, Peter Korsgaard wrote:
  +   uImage.thinx:   U-Boot multi component image. Similar to uImage,

 Grant Change this to uImage.%: to match the rest of this document.

Argh, guess what my platform is called ;)

  -   otheros.bld *.dtb
  +   otheros.bld uImage.* *.dtb

 Grant Actually, you can probably make this uImage* instead because plain
 Grant 'uImage' targets are missing from this list.

Ok, will do.

  -miboot|uboot)
  +miboot|uboot|uboot-*)

 Grant Similarly, uboot and uboot-* can probably be collapsed to 'uboot*'

Yeah, I kept it like this to keep it clear that it doesn't impact the
normal uImage support - Will fix.

I'll send an updated patch.

-- 
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2] bootwrapper: support u-boot multi component images

From: peter Korsgaard [EMAIL PROTECTED]

Support uImage.platform, which are U-Boot multi component images
containing a kernel, dtb and possibly an initrd.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
v2: Incorporated Grant Likely's feedback.

 Documentation/powerpc/bootwrapper.txt |4 
 arch/powerpc/boot/Makefile|   11 +--
 arch/powerpc/boot/wrapper |   20 +++-
 3 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/Documentation/powerpc/bootwrapper.txt 
b/Documentation/powerpc/bootwrapper.txt
index d60fced..fa2e014 100644
--- a/Documentation/powerpc/bootwrapper.txt
+++ b/Documentation/powerpc/bootwrapper.txt
@@ -91,6 +91,10 @@ Currently, the following image format targets exist:
a device tree to the kernel at boot.  If using an older
version of U-Boot, then you need to use a cuImage
instead.
+   uImage.%:   U-Boot multi component image. Similar to uImage,
+   except device tree blob is embedded inside the
+   image together with the kernel (and potentially
+   an initrd).
zImage.%:   Image format which does not embed a device tree.
Used by OpenFirmware and other firmware interfaces
which are able to supply a device tree.  This image
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 717a3bc..8d2e789 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -282,8 +282,9 @@ image-y += $(subst ,,$(CONFIG_EXTRA_TARGETS))
 initrd-  := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
 initrd-y := $(patsubst zImage%, zImage.initrd%, \
$(patsubst dtbImage%, dtbImage.initrd%, \
+   $(patsubst uImage.%, uImage.initrd.%, \
$(patsubst simpleImage%, simpleImage.initrd%, \
-   $(patsubst treeImage%, treeImage.initrd%, $(image-y)
+   $(patsubst treeImage%, treeImage.initrd%, $(image-y))
 initrd-y := $(filter-out $(image-y), $(initrd-y))
 targets+= $(image-y) $(initrd-y)
 
@@ -316,6 +317,12 @@ $(obj)/zImage.iseries: vmlinux
 $(obj)/uImage: vmlinux $(wrapperbits)
$(call if_changed,wrap,uboot)
 
+$(obj)/uImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
+   $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
+
+$(obj)/uImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
+   $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb)
+
 $(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb)
 
@@ -352,7 +359,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
 clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
-   otheros.bld *.dtb
+   otheros.bld uImage* *.dtb
 
 # clean up files cached by wrapper
 clean-kernel := vmlinux.strip vmlinux.bin
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 965c237..548b087 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -153,7 +153,7 @@ coff)
 lds=$object/zImage.coff.lds
 link_address='0x50'
 ;;
-miboot|uboot)
+miboot|uboot*)
 # miboot and U-boot want just the bare bits, not an ELF binary
 ext=bin
 objflags=-O binary
@@ -262,6 +262,24 @@ uboot)
 fi
 exit 0
 ;;
+uboot-*)
+rm -f $ofile
+# we always need an initrd - create a dummy initrd if none provided
+if [ ! -f initrd ]; then
+   initrd=$tmpdir/dummy.initrd
+   echo -n fill $initrd
+fi
+mkimage -A ppc -O linux -T multi -C gzip -a $membase -e $membase \
+   $uboot_version -d $vmz:$initrd:$dtb $ofile
+if [ $initrd == $tmpdir/dummy.initrd ]; then
+   rm $initrd;
+fi
+if [ -z $cacheit ]; then
+   rm -f $vmz
+fi
+exit 0
+;;
+
 esac
 
 addsec() {
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

ioremap and vmalloc

Hello,

When I use ioremap, the second time, I obtain this message :

allocation failed: out of vmalloc space - use vmalloc=size to increase
size.
What can I do in order to fix this problem ?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] bootwrapper: support u-boot multi component images

 Gerhard == Gerhard Pircher [EMAIL PROTECTED] writes:

Hi,

  Support uImage.platform, which are U-Boot multi component images
  containing a kernel, dtb and possibly an initrd.
 Gerhard Just out of interest: Do you intend to replace the code for building
 Gerhard cuImage.platform (zImage target) with this new build target?

No, they are for different use cases. cuImages are interesting when
you cannot upgrade uboot to add device tree support and you want to
use a new kernel - uImage.% is interesting when you want to use device
trees but you want the simplicity of having a single file (And you
acknowledge the fact that the device tree as it is today is pretty much
kernel version dependent so it makes most sense to keep them in sync).

-- 
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] bootwrapper: support u-boot multi component images

2008-09-19 Thread Gerhard Pircher


 Original-Nachricht 
 Datum: Fri, 19 Sep 2008 10:50:10 +0200
 Von: Peter Korsgaard [EMAIL PROTECTED]
 An: linuxppc-dev@ozlabs.org, [EMAIL PROTECTED]
 Betreff: [PATCH v2] bootwrapper: support u-boot multi component images

 From: peter Korsgaard [EMAIL PROTECTED]
 
 Support uImage.platform, which are U-Boot multi component images
 containing a kernel, dtb and possibly an initrd.
Just out of interest: Do you intend to replace the code for building
cuImage.platform (zImage target) with this new build target?

regards,

Gerhard

-- 
GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion!
http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] bootwrapper: support u-boot multi component images

On Fri, Sep 19, 2008 at 10:50:10AM +0200, Peter Korsgaard wrote:
 From: peter Korsgaard [EMAIL PROTECTED]
 
 Support uImage.platform, which are U-Boot multi component images
 containing a kernel, dtb and possibly an initrd.
 
 Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
Acked-by: Grant Likely [EMAIL PROTECTED]

 ---
 v2: Incorporated Grant Likely's feedback.
 
  Documentation/powerpc/bootwrapper.txt |4 
  arch/powerpc/boot/Makefile|   11 +--
  arch/powerpc/boot/wrapper |   20 +++-
  3 files changed, 32 insertions(+), 3 deletions(-)
 
 diff --git a/Documentation/powerpc/bootwrapper.txt 
 b/Documentation/powerpc/bootwrapper.txt
 index d60fced..fa2e014 100644
 --- a/Documentation/powerpc/bootwrapper.txt
 +++ b/Documentation/powerpc/bootwrapper.txt
 @@ -91,6 +91,10 @@ Currently, the following image format targets exist:
   a device tree to the kernel at boot.  If using an older
   version of U-Boot, then you need to use a cuImage
   instead.
 +   uImage.%: U-Boot multi component image. Similar to uImage,
 + except device tree blob is embedded inside the
 + image together with the kernel (and potentially
 + an initrd).
 zImage.%: Image format which does not embed a device tree.
   Used by OpenFirmware and other firmware interfaces
   which are able to supply a device tree.  This image
 diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
 index 717a3bc..8d2e789 100644
 --- a/arch/powerpc/boot/Makefile
 +++ b/arch/powerpc/boot/Makefile
 @@ -282,8 +282,9 @@ image-y   += $(subst ,,$(CONFIG_EXTRA_TARGETS))
  initrd-  := $(patsubst zImage%, zImage.initrd%, $(image-n) $(image-))
  initrd-y := $(patsubst zImage%, zImage.initrd%, \
   $(patsubst dtbImage%, dtbImage.initrd%, \
 + $(patsubst uImage.%, uImage.initrd.%, \
   $(patsubst simpleImage%, simpleImage.initrd%, \
 - $(patsubst treeImage%, treeImage.initrd%, $(image-y)
 + $(patsubst treeImage%, treeImage.initrd%, $(image-y))
  initrd-y := $(filter-out $(image-y), $(initrd-y))
  targets  += $(image-y) $(initrd-y)
  
 @@ -316,6 +317,12 @@ $(obj)/zImage.iseries: vmlinux
  $(obj)/uImage: vmlinux $(wrapperbits)
   $(call if_changed,wrap,uboot)
  
 +$(obj)/uImage.initrd.%: vmlinux $(wrapperbits) $(obj)/%.dtb
 + $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz)
 +
 +$(obj)/uImage.%: vmlinux $(wrapperbits) $(obj)/%.dtb
 + $(call if_changed,wrap,uboot-$*,,$(obj)/$*.dtb)
 +
  $(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
   $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb)
  
 @@ -352,7 +359,7 @@ install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
  clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
   zImage zImage.initrd zImage.chrp zImage.coff zImage.holly \
   zImage.iseries zImage.miboot zImage.pmac zImage.pseries \
 - otheros.bld *.dtb
 + otheros.bld uImage* *.dtb
  
  # clean up files cached by wrapper
  clean-kernel := vmlinux.strip vmlinux.bin
 diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
 index 965c237..548b087 100755
 --- a/arch/powerpc/boot/wrapper
 +++ b/arch/powerpc/boot/wrapper
 @@ -153,7 +153,7 @@ coff)
  lds=$object/zImage.coff.lds
  link_address='0x50'
  ;;
 -miboot|uboot)
 +miboot|uboot*)
  # miboot and U-boot want just the bare bits, not an ELF binary
  ext=bin
  objflags=-O binary
 @@ -262,6 +262,24 @@ uboot)
  fi
  exit 0
  ;;
 +uboot-*)
 +rm -f $ofile
 +# we always need an initrd - create a dummy initrd if none provided
 +if [ ! -f initrd ]; then
 + initrd=$tmpdir/dummy.initrd
 + echo -n fill $initrd
 +fi
 +mkimage -A ppc -O linux -T multi -C gzip -a $membase -e $membase \
 + $uboot_version -d $vmz:$initrd:$dtb $ofile
 +if [ $initrd == $tmpdir/dummy.initrd ]; then
 + rm $initrd;
 +fi
 +if [ -z $cacheit ]; then
 + rm -f $vmz
 +fi
 +exit 0
 +;;
 +
  esac
  
  addsec() {
 -- 
 1.5.6.3
 
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Remove obsolete junk in Documentation/powerpc

On Tue, 16 Sep 2008 11:44:42 -0700
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:

 We have all sort of totally rotten pieces of documentation
 in there, let's get rid of them
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

Geert's two patches for ppc_htab.txt and smp.txt are more complete as
they remove the references in 00-INDEX as well.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc

On Fri, Sep 19, 2008 at 01:15:20PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
 Hello,
 
 When I use ioremap, the second time, I obtain this message :
 
 allocation failed: out of vmalloc space - use vmalloc=size to increase
 size.
 What can I do in order to fix this problem ?

How large are the regions that you are ioremapping?  The kernel sets
aside a fixed amount of the virtual address space for ioremaps, and if
you exhaust that then more ioremaps will stop working.

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs

 Anton == Anton Vorontsov [EMAIL PROTECTED] writes:

Hi,

  It seems basically the same as my patch (gpio driver for
  mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except
  you don't have any documentation

 Anton Well, do we really need documentation for every trivial gpio
 Anton controller? The bindings are the same, only different compatible
 Anton entries...

Well, we need some way of knowing that atleast. Having people grepping
through arch/powerpc/boot/dts/ (and knowing that they should look for
8349 even though they might use 8313 or 8610) doesn't seem optimal to
me - I take it that's why we created
Documentation/powerpc/dts-bindings in the first place?

 Anton If we do need the documentation for this, I can readily include it.

  and the Kconfig doesn't depend on
  831x/834x/837x.

 Anton This is purposely. We also need support for 8610, and maybe
 Anton later we'll find another chip with the same unit. So, to not touch
 Anton the Kconfig for every new chip I just made it PPC32-wide. Other
 Anton option is to depend on FSL_SOC, but the driver really does not
 Anton depend on any fsl_soc stuff...

Adding another symbol to the Kconfig once it is verified that a new
SoC is compatible doesn't seem like a big deal - Figuring out all the
knobs we already have is, without having options for stuff that is
known to be irrelevant for the SoC.

The other 83xx specific drivers also depend on PPC_83xx.

  Why do you need this when you have the lock?

 Anton See this discussion:

 Anton http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12299.html

Ahh, for open drain outputs. gpiolib doesn't actually provide an
interface to put the gpios in that mode, but it could ofcause have
been set up in the bootloader. I'll fix that and send an updated
patch.

-- 
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] fsl-dma: allow Freescale Elo DMA driver to be compiled as a module

2008-09-19 Thread Timur Tabi

Modify the Freescale Elo / Elo Plus DMA driver so that it can be compiled as
a module.

The primary change is to stop treating the DMA controller as a bus, and the
DMA channels as devices on the bus.  This is because the Open Firmware (OF)
kernel code does not allow busses to be removed, so although we can call
of_platform_bus_probe() to probe the DMA channels, there is no
of_platform_bus_remove().  Therefore, the DMA channels must be manually probed.

Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---

(Reposting because I forgot to CC: the maintainers) 

This patch is for the 2.6.28 kernel.  This patch exposes a bug in the dmatest
module, so my other patch dmatest: properly handle duplicate DMA channels
should be applied if this patch is applied.

 drivers/dma/Kconfig  |   10 ++--
 drivers/dma/fsldma.c |  165 ++
 drivers/dma/fsldma.h |2 +
 3 files changed, 119 insertions(+), 58 deletions(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index cd30390..9dfd502 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -48,13 +48,13 @@ config DW_DMAC
  can be integrated in chips such as the Atmel AT32ap7000.
 
 config FSL_DMA
-   bool Freescale MPC85xx/MPC83xx DMA support
-   depends on PPC
+   tristate Freescale Elo and Elo Plus DMA support
+   depends on PPC_83xx || PPC_85xx || PPC_86xx
select DMA_ENGINE
---help---
- Enable support for the Freescale DMA engine. Now, it support
- MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
- The MPC8349, MPC8360 is also supported.
+ Enable support for the Freescale Elo and Elo Plus DMA controllers.
+ The Elo is the DMA controller on 83xx parts, and the Elo Plus is
+ the DMA controller on 85xx and 86xx parts.
 
 config MV_XOR
bool Marvell XOR engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index c0059ca..327c485 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -372,6 +372,10 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan 
*chan,
struct fsl_dma_chan *fsl_chan = to_fsl_chan(chan);
LIST_HEAD(tmp_list);
 
+   /* Has this channel already been allocated? */
+   if (fsl_chan-desc_pool)
+   return 1;
+
/* We need the descriptor to be aligned to 32bytes
 * for meeting FSL DMA specification requirement.
 */
@@ -381,7 +385,7 @@ static int fsl_dma_alloc_chan_resources(struct dma_chan 
*chan,
if (!fsl_chan-desc_pool) {
dev_err(fsl_chan-dev, No memory for channel %d 
descriptor dma pool.\n, fsl_chan-id);
-   return 0;
+   return -ENOMEM;
}
 
return 1;
@@ -410,6 +414,8 @@ static void fsl_dma_free_chan_resources(struct dma_chan 
*chan)
}
spin_unlock_irqrestore(fsl_chan-desc_lock, flags);
dma_pool_destroy(fsl_chan-desc_pool);
+
+   fsl_chan-desc_pool = NULL;
 }
 
 static struct dma_async_tx_descriptor *
@@ -912,33 +918,37 @@ out:
return err;
 }
 
-static int __devinit of_fsl_dma_chan_probe(struct of_device *dev,
-   const struct of_device_id *match)
+static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
+   struct device_node *node, u32 feature, const char *compatible)
 {
-   struct fsl_dma_device *fdev;
struct fsl_dma_chan *new_fsl_chan;
+   const u32 *iprop;
int err;
 
-   fdev = dev_get_drvdata(dev-dev.parent);
-   BUG_ON(!fdev);
-
/* alloc channel */
new_fsl_chan = kzalloc(sizeof(struct fsl_dma_chan), GFP_KERNEL);
if (!new_fsl_chan) {
-   dev_err(dev-dev, No free memory for allocating 
+   dev_err(fdev-dev, No free memory for allocating 
dma channels!\n);
return -ENOMEM;
}
 
+   new_fsl_chan-of_dev = of_platform_device_create(node, NULL, fdev-dev);
+   if (!new_fsl_chan-of_dev) {
+   dev_err(fdev-dev, cannot create platform device\n);
+   err = -EINVAL;
+   goto err_no_dev;
+   }
+
/* get dma channel register base */
-   err = of_address_to_resource(dev-node, 0, new_fsl_chan-reg);
+   err = of_address_to_resource(node, 0, new_fsl_chan-reg);
if (err) {
-   dev_err(dev-dev, Can't get %s property 'reg'\n,
-   dev-node-full_name);
+   dev_err(fdev-dev, Can't get %s property 'reg'\n,
+   node-full_name);
goto err_no_reg;
}
 
-   new_fsl_chan-feature = *(u32 *)match-data;
+   new_fsl_chan-feature = feature;
 
if (!fdev-feature)
fdev-feature = new_fsl_chan-feature;
@@ -948,17 +958,22 @@ static int __devinit of_fsl_dma_chan_probe(struct 
of_device *dev,
 */
WARN_ON(fdev-feature != new_fsl_chan-feature);
 
-

Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs

On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote:
Anton == Anton Vorontsov [EMAIL PROTECTED] writes:

Hi,

It seems basically the same as my patch (gpio driver for
mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except
you don't have any documentation

Anton Well, do we really need documentation for every trivial gpio
Anton controller? The bindings are the same, only different compatible
Anton entries...

Well, we need some way of knowing that atleast. Having people grepping
through arch/powerpc/boot/dts/ (and knowing that they should look for
8349 even though they might use 8313 or 8610) doesn't seem optimal to
me - I take it that's why we created
Documentation/powerpc/dts-bindings in the first place?

Ok.

Anton If we do need the documentation for this, I can readily include it.

and the Kconfig doesn't depend on
831x/834x/837x.

Anton This is purposely. We also need support for 8610, and maybe
Anton later we'll find another chip with the same unit. So, to not touch
Anton the Kconfig for every new chip I just made it PPC32-wide. Other
Anton option is to depend on FSL_SOC, but the driver really does not
Anton depend on any fsl_soc stuff...

Adding another symbol to the Kconfig once it is verified that a new
SoC is compatible doesn't seem like a big deal - Figuring out all the
knobs we already have is, without having options for stuff that is
known to be irrelevant for the SoC.

The other 83xx specific drivers also depend on PPC_83xx.

Lets wait for Kumar's comments. We've already had a PPC_* mess
for the USB_EHCI_FSL symbol. What I've learned from it, is that
huge PPC_* list isn't perfect either.

See this discussion:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg01926.html

And this one:

http://fixunix.com/kernel/397972-patch-1-4-spi-powerpc-spi_mpc83xx-handles-freescale-mpc8610-well.html

Why do you need this when you have the lock?

Anton See this discussion:

Anton http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12299.html

Ahh, for open drain outputs. gpiolib doesn't actually provide an
interface to put the gpios in that mode, but it could ofcause have
been set up in the bootloader. I'll fix that and send an updated
patch.

Pardon? Who will send an updated patch, and what patch exactly? ;-)

--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc


The first is ioremap(0x2000,0x1000);
The second is ioremap(0x8000,0x1000);
Is it too long

Grant Likely a écrit :

On Fri, Sep 19, 2008 at 01:15:20PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
  

Hello,

When I use ioremap, the second time, I obtain this message :

allocation failed: out of vmalloc space - use vmalloc=size to increase
size.
What can I do in order to fix this problem ?



How large are the regions that you are ioremapping?  The kernel sets
aside a fixed amount of the virtual address space for ioremaps, and if
you exhaust that then more ioremaps will stop working.

g.

___
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: ioremap and vmalloc

On Fri, Sep 19, 2008 at 06:34:06PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
 The first is ioremap(0x2000,0x1000);
 The second is ioremap(0x8000,0x1000);
 Is it too long

The error message you are getting should have been a very strong hint that
the answer is yes.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc

On Fri, Sep 19, 2008 at 06:34:06PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
 The first is ioremap(0x2000,0x1000);
 The second is ioremap(0x8000,0x1000);
 Is it too long

Well, you're trying to allocate two 256MB regions.  That is very large.
What kind of device are you trying to map?

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc

On Fri, Sep 19, 2008 at 06:45:01PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
 if I write :
 ioremap(0x2000,0x4) and ioremap(0x2000,0x5)

 Will it crash ?

I have no idea.  You haven't given us enough information to really answer
that.

Basic information needed would be: 

1) What board/chip
2) What kernel version
3) What are you actually trying to do
4) What driver are you using
5) If you are writing your own, where is the code for it

etc.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc

On Fri, Sep 19, 2008 at 10:58 AM, Josh Boyer [EMAIL PROTECTED] wrote:
 On Fri, Sep 19, 2008 at 06:45:01PM +0200, 
 =?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
 if I write :
 ioremap(0x2000,0x4) and ioremap(0x2000,0x5)

 Will it crash ?

 I have no idea.  You haven't given us enough information to really answer
 that.

But I can say that the second ioremap() call makes the first ioremap()
both redundant and inefficient.  You're using exactly the same base
address so the same region is getting mapped twice.  Since the second
call uses a bigger region than the first then the kernel will probably
need to allocate another chunk of virtual address space to map it
instead of reusing the first mapping.

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: [PATCH v2] Add AMCC Arches eval board support to platforms/44x

2008-09-19 Thread Victor Gallardo

 
Hi Josh,

See below...

 ...
 @@ -83,9 +83,23 @@ config CANYONLANDS
  select 460EX
  select PCI
  select PPC4xx_PCI_EXPRESS
 +select IBM_NEW_EMAC_EMAC4
 +select IBM_NEW_EMAC_RGMII
 +select IBM_NEW_EMAC_ZMII
 +select IBM_NEW_EMAC_TAH
  help
This option enables support for the AMCC PPC460EX evaluation board.
 
 +config ARCHES
 +bool Arches
 +depends on 44x
 +default n
 +select 460EX
 +select IBM_NEW_EMAC_EMAC4
 +select IBM_NEW_EMAC_TAH
 +help
 +  This option enables support for the AMCC PPC460GT evaluation board.

This seems fine.

 ...

 +obj-$(CONFIG_ARCHES)+= canyonlands.o
  obj-$(CONFIG_CANYONLANDS) += canyonlands.o
  obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o

Instead of modifying the Makefile, you should only have to add the 
amcc,arches
 string to the board array in ppc44x_simple.c.

 We switched to doing this as opposed to having a somewhat bogus 
 board compatible statement with other boards.  That is what was discussed 
 at
 OLS, and this is the result.

The reason for two different board types is to remove RGMII and ZMII from the 
build. Arches does not use it.

Where is ppc4xx_simple.c? I just pulled your git tree and did not find this 
file.

Thanks,

Victor Gallardo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] Add AMCC Arches eval board support to platforms/44x

On Fri, 19 Sep 2008 10:31:34 -0700
Victor Gallardo [EMAIL PROTECTED] wrote:

Hi Josh,

See below...

...
@@ -83,9 +83,23 @@ config CANYONLANDS
select 460EX
select PCI
select PPC4xx_PCI_EXPRESS
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+ select IBM_NEW_EMAC_ZMII
+ select IBM_NEW_EMAC_TAH
help
This option enables support for the AMCC PPC460EX evaluation board.

+config ARCHES
+ bool Arches
+ depends on 44x
+ default n
+ select 460EX
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_TAH
+ help
+This option enables support for the AMCC PPC460GT evaluation board.

This seems fine.

...

+obj-$(CONFIG_ARCHES) += canyonlands.o
obj-$(CONFIG_CANYONLANDS) += canyonlands.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o

Instead of modifying the Makefile, you should only have to add the
amcc,arches
string to the board array in ppc44x_simple.c.

We switched to doing this as opposed to having a somewhat bogus
board compatible statement with other boards. That is what was
discussed at
OLS, and this is the result.

The reason for two different board types is to remove RGMII and ZMII from the
build. Arches does not use it.

Right, and that part is fine.

Where is ppc4xx_simple.c? I just pulled your git tree and did not find this
file.

You need to look in the 'next' branch.

http://git.kernel.org/?p=linux/kernel/git/jwboyer/powerpc-4xx.git;a=tree;f=arch/powerpc/platforms/44x;h=c5cae8d37f170193ed45b7b76e3cb2cbb8be927a;hb=next

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs



On Sep 19, 2008, at 10:33 AM, Anton Vorontsov wrote:


On Fri, Sep 19, 2008 at 05:11:15PM +0200, Peter Korsgaard wrote:

Anton == Anton Vorontsov [EMAIL PROTECTED] writes:


Hi,


It seems basically the same as my patch (gpio driver for
mpc831x/mpc834x/mpc837x with OF bindings) from September 5th except
you don't have any documentation


Anton Well, do we really need documentation for every trivial gpio
Anton controller? The bindings are the same, only different  
compatible

Anton entries...

Well, we need some way of knowing that atleast. Having people  
grepping

through arch/powerpc/boot/dts/ (and knowing that they should look for
8349 even though they might use 8313 or 8610) doesn't seem optimal to
me - I take it that's why we created
Documentation/powerpc/dts-bindings in the first place?


Ok.

Anton If we do need the documentation for this, I can readily  
include it.



and the Kconfig doesn't depend on
831x/834x/837x.


Anton This is purposely. We also need support for 8610, and maybe
Anton later we'll find another chip with the same unit. So, to not  
touch
Anton the Kconfig for every new chip I just made it PPC32-wide.  
Other

Anton option is to depend on FSL_SOC, but the driver really does not
Anton depend on any fsl_soc stuff...

Adding another symbol to the Kconfig once it is verified that a new
SoC is compatible doesn't seem like a big deal - Figuring out all the
knobs we already have is, without having options for stuff that is
known to be irrelevant for the SoC.

The other 83xx specific drivers also depend on PPC_83xx.


Lets wait for Kumar's comments. We've already had a PPC_* mess
for the USB_EHCI_FSL symbol. What I've learned from it, is that
huge PPC_* list isn't perfect either.


I've alone glanced over this, but some initial comments are.. lets  
rename the thing to not be 83xx specific since 8610 uses it and I'm  
sure we'll have other parts that do similar things.


With regards to the binding, lets make it generic like 'fsl,mpc8xxx- 
gpio, fsl,CHIP-gpio and than we can use cpm1/cpm2/pq1/pq2 as  
prefixes to distinguish and major differences.


- k

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/2] i2c: expand I2C's id.name to 23 characters

It was discussed[1] that we should match on the first (most specific)
entry in the device tree.

The most lengthy I2C compatible entry for the MPC8349E-mITX MCU
devices is mc9s08qg8-mpc8349emitx (w/o vendor name). This means
that we have to allow longer IDs to be used in the I2C subsystem.

[1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 include/linux/mod_devicetable.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index c4db582..9d9d1f5 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -379,7 +379,7 @@ struct virtio_device_id {
 
 /* i2c */
 
-#define I2C_NAME_SIZE  20
+#define I2C_NAME_SIZE  23
 #define I2C_MODULE_PREFIX i2c:
 
 struct i2c_device_id {
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/2] i2c: MPC8349E-mITX Power Management and GPIO expander driver

On MPC8349E-mITX, MPC8315E-RDB and MPC837x-RDB boards there is a
Freescale MC9S08QG8 (MCU) chip with the custom firmware
pre-programmed. The chip is used to power-off the board by the
software, and to control some GPIO pins.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 drivers/i2c/chips/Kconfig|   11 ++
 drivers/i2c/chips/Makefile   |1 +
 drivers/i2c/chips/mcu_mpc8349emitx.c |  213 ++
 3 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/chips/mcu_mpc8349emitx.c

diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
index a95cb94..1735682 100644
--- a/drivers/i2c/chips/Kconfig
+++ b/drivers/i2c/chips/Kconfig
@@ -172,4 +172,15 @@ config MENELAUS
  and other features that are often used in portable devices like
  cell phones and PDAs.
 
+config MCU_MPC8349EMITX
+   tristate MPC8349E-mITX MCU driver
+   depends on I2C  PPC_83xx
+   select GENERIC_GPIO
+   select ARCH_REQUIRE_GPIOLIB
+   help
+ Say Y here to enable soft power-off functionality on the Freescale
+ boards with the MPC8349E-mITX-compatible MCU chips. This driver will
+ also register MCU GPIOs with the generic GPIO API, so you'll able
+ to use MCU pins as GPIOs.
+
 endmenu
diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
index 39e3e69..ca520fa 100644
--- a/drivers/i2c/chips/Makefile
+++ b/drivers/i2c/chips/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_ISP1301_OMAP)+= isp1301_omap.o
 obj-$(CONFIG_TPS65010) += tps65010.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 obj-$(CONFIG_SENSORS_TSL2550)  += tsl2550.o
+obj-$(CONFIG_MCU_MPC8349EMITX) += mcu_mpc8349emitx.o
 
 ifeq ($(CONFIG_I2C_DEBUG_CHIP),y)
 EXTRA_CFLAGS += -DDEBUG
diff --git a/drivers/i2c/chips/mcu_mpc8349emitx.c 
b/drivers/i2c/chips/mcu_mpc8349emitx.c
new file mode 100644
index 000..47b07b8
--- /dev/null
+++ b/drivers/i2c/chips/mcu_mpc8349emitx.c
@@ -0,0 +1,213 @@
+/*
+ * Power Management and GPIO expander driver for MPC8349E-mITX-compatible MCU
+ *
+ * Copyright (c) 2008  MontaVista Software, Inc.
+ *
+ * Author: Anton Vorontsov [EMAIL PROTECTED]
+ *
+ * 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/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include asm/prom.h
+#include asm/machdep.h
+
+/*
+ * I don't have specifications for the MCU firmware, I found this register
+ * and bits positions by the trialerror method.
+ */
+#define MCU_REG_CTRL   0x20
+#define MCU_CTRL_POFF  0x40
+
+#define MCU_NUM_GPIO   2
+
+struct mcu {
+   struct mutex lock;
+   struct device_node *np;
+   struct i2c_client *client;
+   struct of_gpio_chip of_gc;
+   u8 reg_ctrl;
+};
+
+static struct mcu *glob_mcu;
+
+static void mcu_power_off(void)
+{
+   struct mcu *mcu = glob_mcu;
+
+   pr_info(Sending power-off request to the MCU...\n);
+   mutex_lock(mcu-lock);
+   i2c_smbus_write_byte_data(glob_mcu-client, MCU_REG_CTRL,
+ mcu-reg_ctrl | MCU_CTRL_POFF);
+   mutex_unlock(mcu-lock);
+}
+
+static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
+   struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+   u8 bit = 1  (4 + gpio);
+
+   mutex_lock(mcu-lock);
+   if (val)
+   mcu-reg_ctrl = ~bit;
+   else
+   mcu-reg_ctrl |= bit;
+
+   i2c_smbus_write_byte_data(mcu-client, MCU_REG_CTRL, mcu-reg_ctrl);
+   mutex_unlock(mcu-lock);
+}
+
+static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   mcu_gpio_set(gc, gpio, val);
+   return 0;
+}
+
+static int mcu_gpiochip_add(struct mcu *mcu)
+{
+   struct device_node *np;
+   struct of_gpio_chip *of_gc = mcu-of_gc;
+   struct gpio_chip *gc = of_gc-gc;
+   int ret;
+
+   np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc8349emitx);
+   if (!np)
+   return -ENODEV;
+
+   gc-owner = THIS_MODULE;
+   gc-label = np-full_name;
+   gc-can_sleep = 1;
+   gc-ngpio = MCU_NUM_GPIO;
+   gc-base = -1;
+   gc-set = mcu_gpio_set;
+   gc-direction_output = mcu_gpio_dir_out;
+   of_gc-gpio_cells = 2;
+   of_gc-xlate = of_gpio_simple_xlate;
+
+   np-data = of_gc;
+   mcu-np = np;
+
+   /*
+* We don't want to lose the node, its -data and -full_name...
+* So, if succeeded, we don't put the node here.
+*/
+   ret = gpiochip_add(gc);
+   if (ret)
+

Re: [PATCH] powerpc: gpio driver for mpc831x/834x/837x with OF bindings



On Sep 5, 2008, at 10:08 AM, Peter Korsgaard wrote:


Structured similar to the existing QE GPIO support.

Signed-off-by: Peter Korsgaard [EMAIL PROTECTED]
---
.../powerpc/dts-bindings/fsl/83xx_gpio.txt |   33 +
arch/powerpc/sysdev/Kconfig|9 ++
arch/powerpc/sysdev/Makefile   |1 +
arch/powerpc/sysdev/mpc83xx_gpio.c |  141 +++ 
+

4 files changed, 184 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/ 
83xx_gpio.txt

create mode 100644 arch/powerpc/sysdev/mpc83xx_gpio.c


So we need to make this mpc8xxx_gpio.c 83xx, 8610, 85xx all have the  
same GPIO hw.


- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs

On Fri, Sep 19, 2008 at 01:02:11PM -0500, Kumar Gala wrote:
[...]
 Anton This is purposely. We also need support for 8610, and maybe
 Anton later we'll find another chip with the same unit. So, to not  
 touch
 Anton the Kconfig for every new chip I just made it PPC32-wide.  
 Other
 Anton option is to depend on FSL_SOC, but the driver really does not
 Anton depend on any fsl_soc stuff...

 Adding another symbol to the Kconfig once it is verified that a new
 SoC is compatible doesn't seem like a big deal - Figuring out all the
 knobs we already have is, without having options for stuff that is
 known to be irrelevant for the SoC.

 The other 83xx specific drivers also depend on PPC_83xx.

 Lets wait for Kumar's comments. We've already had a PPC_* mess
 for the USB_EHCI_FSL symbol. What I've learned from it, is that
 huge PPC_* list isn't perfect either.

 I've alone glanced over this, but some initial comments are.. lets  
 rename the thing to not be 83xx specific since 8610 uses it and I'm sure 
 we'll have other parts that do similar things.

Ok, mpc8xxx_gpio.c would be fine? (Note that I'm agree with 8xxx, for
the file name).

 With regards to the binding, lets make it generic like 'fsl,mpc8xxx- 
 gpio, fsl,CHIP-gpio and than we can use cpm1/cpm2/pq1/pq2 as prefixes 
 to distinguish and major differences.

But for compatible entry, shouldn't we use the last compatiblle entry
as a generic one? Then fsl,mpc8349-gpio is perfectly valid. I.e.,
for MPC8610 chips we will have:

fsl,mpc8610-gpio, fsl,mpc8349-gpio

The last entry is most generic, and 8610 is registers-compatible with
the earlier (8349) chips. I thought that we tend to not do made up
8xxx things in the device tree... Am I wrong?


Thanks!

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc: Fix build warnings introduced by PMC support on 32-bit

arch/powerpc/kernel/sysfs.c:197:7: warning: CONFIG_6xx is not defined
arch/powerpc/kernel/sysfs.c:141: warning: 'run_on_cpu' defined but not used

Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
 arch/powerpc/kernel/sysfs.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index ef2ad92..86a2ffc 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -134,6 +134,7 @@ void ppc_enable_pmcs(void)
 }
 EXPORT_SYMBOL(ppc_enable_pmcs);
 
+#if defined(CONFIG_6xx) || defined(CONFIG_PPC64)
 /* XXX convert to rusty's on_one_cpu */
 static unsigned long run_on_cpu(unsigned long cpu,
unsigned long (*func)(unsigned long),
@@ -152,6 +153,7 @@ static unsigned long run_on_cpu(unsigned long cpu,
 
return ret;
 }
+#endif
 
 #define SYSFS_PMCSETUP(NAME, ADDRESS) \
 static unsigned long read_##NAME(unsigned long junk) \
@@ -190,11 +192,11 @@ static ssize_t __used \
  * that are implemented on the current processor
  */
 
-#ifdef CONFIG_PPC64
+#if defined(CONFIG_PPC64)
 #define HAS_PPC_PMC_CLASSIC1
 #define HAS_PPC_PMC_IBM1
 #define HAS_PPC_PMC_PA6T   1
-#elif CONFIG_6xx
+#elif defined(CONFIG_6xx)
 #define HAS_PPC_PMC_CLASSIC1
 #define HAS_PPC_PMC_IBM1
 #define HAS_PPC_PMC_G4 1
-- 
1.5.5.1

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH V2] Pass actual dev ptr to dma_* in ucc and cpm_uart serial



On Sep 12, 2008, at 10:42 AM, Becky Bruce wrote:


We're currently passing NULL, and really shouldn't be.

Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
drivers/serial/cpm_uart/cpm_uart_core.c |3 +++
drivers/serial/cpm_uart/cpm_uart_cpm1.c |6 +++---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +++---
drivers/serial/ucc_uart.c   |4 ++--
4 files changed, 11 insertions(+), 8 deletions(-)


applied.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Please pull from 'powerpc-next'

Please pull from 'powerpc-next' branch of

master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git 
powerpc-next

to receive the following updates:

 Documentation/powerpc/dts-bindings/fsl/ssi.txt  |   15
 arch/powerpc/boot/dts/gef_sbc610.dts|  260 +++
 arch/powerpc/boot/dts/mgcoge.dts|  174 ++
 arch/powerpc/boot/dts/mgsuvd.dts|  163 ++
 arch/powerpc/boot/dts/mpc836x_mds.dts   |   23
 arch/powerpc/boot/dts/mpc8610_hpcd.dts  |8
 arch/powerpc/configs/83xx/mpc836x_mds_defconfig |   79 +
 arch/powerpc/configs/86xx/gef_sbc610_defconfig  | 1654 
 arch/powerpc/configs/mgcoge_defconfig   |  900 +
 arch/powerpc/configs/mgsuvd_defconfig   |  872 
 arch/powerpc/kernel/head_fsl_booke.S|   26
 arch/powerpc/kernel/sysfs.c |6
 arch/powerpc/mm/fsl_booke_mmu.c |5
 arch/powerpc/platforms/82xx/Kconfig |8
 arch/powerpc/platforms/82xx/Makefile|1
 arch/powerpc/platforms/82xx/mgcoge.c|  129 +
 arch/powerpc/platforms/85xx/sbc8560.c   |2
 arch/powerpc/platforms/86xx/Kconfig |9
 arch/powerpc/platforms/86xx/Makefile|1
 arch/powerpc/platforms/86xx/gef_sbc610.c|  149 ++
 arch/powerpc/platforms/8xx/Kconfig  |6
 arch/powerpc/platforms/8xx/Makefile |1
 arch/powerpc/platforms/8xx/mgsuvd.c |   92 +
 arch/powerpc/sysdev/cpm1.c  |   74 -
 drivers/serial/Kconfig  |   36
 drivers/serial/cpm_uart/cpm_uart_core.c |3
 drivers/serial/cpm_uart/cpm_uart_cpm1.c |6
 drivers/serial/cpm_uart/cpm_uart_cpm2.c |6
 drivers/serial/ucc_uart.c   |4
 include/math-emu/op-2.h |2
 include/math-emu/op-common.h|   12
 include/math-emu/soft-fp.h  |   19
 32 files changed, 4656 insertions(+), 89 deletions(-)

Anton Vorontsov (1):
  powerpc/83xx: mpc836x_mds: add support for the nor flash

Becky Bruce (2):
  powerpc/85xx: fix build warning, remove silly cast
  cpm_uart: Pass actual dev ptr to dma_* in ucc and cpm_uart serial

Heiko Schocher (2):
  powerpc: Add support for the MPC852 based mgsuvd board from keymile.
  powerpc: Add support for mpc8247 based board MGCOGE from keymile.

Jochen Friedrich (1):
  powerpc/cpm1: Fix race condition in CPM1 GPIO library.

Kumar Gala (5):
  serial/cpm_uart: Remove dead Kconfig options
  math-emu: Fix compiler warnings
  math-emu: Add support for reporting exact invalid exception
  powerpc: Fix build warnings introduced by PMC support on 32-bit
  powerpc/fsl-booke: Fixup 64-bit PTE reading for SMP support

Martyn Welch (2):
  powerpc: Board support for GE Fanuc SBC610
  powerpc: Default configuration for GE Fanuc SBC610

Paul Gortmaker (1):
  powerpc/sbc8560: fix compile warning on CPM pin array

Timur Tabi (1):
  powerpc: add SSI-to-DMA properties to Freescale MPC8610 HPCD device tree

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: implement support for MPC8349-compatible SOC GPIOs



On Sep 19, 2008, at 1:12 PM, Anton Vorontsov wrote:


On Fri, Sep 19, 2008 at 01:02:11PM -0500, Kumar Gala wrote:
[...]

Anton This is purposely. We also need support for 8610, and maybe
Anton later we'll find another chip with the same unit. So, to not
touch
Anton the Kconfig for every new chip I just made it PPC32-wide.
Other
Anton option is to depend on FSL_SOC, but the driver really does  
not

Anton depend on any fsl_soc stuff...

Adding another symbol to the Kconfig once it is verified that a new
SoC is compatible doesn't seem like a big deal - Figuring out all  
the

knobs we already have is, without having options for stuff that is
known to be irrelevant for the SoC.

The other 83xx specific drivers also depend on PPC_83xx.


Lets wait for Kumar's comments. We've already had a PPC_* mess
for the USB_EHCI_FSL symbol. What I've learned from it, is that
huge PPC_* list isn't perfect either.


I've alone glanced over this, but some initial comments are.. lets
rename the thing to not be 83xx specific since 8610 uses it and I'm  
sure

we'll have other parts that do similar things.


Ok, mpc8xxx_gpio.c would be fine? (Note that I'm agree with 8xxx, for
the file name).


With regards to the binding, lets make it generic like 'fsl,mpc8xxx-
gpio, fsl,CHIP-gpio and than we can use cpm1/cpm2/pq1/pq2 as  
prefixes

to distinguish and major differences.


But for compatible entry, shouldn't we use the last compatiblle entry
as a generic one? Then fsl,mpc8349-gpio is perfectly valid. I.e.,
for MPC8610 chips we will have:

fsl,mpc8610-gpio, fsl,mpc8349-gpio


Yeah the order is correct.. should be:

fsl,CHIP-gpio, fsl,mpc8xxx-gpio

The last entry is most generic, and 8610 is registers-compatible with


the earlier (8349) chips. I thought that we tend to not do made up
8xxx things in the device tree... Am I wrong?


You are correct we try to avoid this, but than I suggest we do it by  
family.  I think its confusing to show 8610 and 8349 in the same dev  
tree.


What we do in PCI is use the first in family.  So lets take 8379 as an  
example it would look like:


fsl,mpc8379-gpio, fsl-mpc8349-gpio

and 8610 would look like:

fsl,mpc8610-gpio

This way the compatiable binding in the code just lists something like  
fsl,mpc8349-gpio, fsl,mpc8610-gpio, fsl,mpc8572-gpio.


Does that make sense?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] i2c: expand I2C's id.name to 23 characters

2008-09-19 Thread Jean Delvare

On Fri, 19 Sep 2008 22:03:39 +0400, Anton Vorontsov wrote:
 It was discussed[1] that we should match on the first (most specific)
 entry in the device tree.
 
 The most lengthy I2C compatible entry for the MPC8349E-mITX MCU
 devices is mc9s08qg8-mpc8349emitx (w/o vendor name). This means
 that we have to allow longer IDs to be used in the I2C subsystem.
 
 [1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html

Nack. Just come up with shorter names. mc9s08qg8-mpc8349emitx is
simply too long to start with. Looking at the mcu_mpc8349emitx driver
you just submitted, you are clearly abusing the i2c client name to pass
platform-specific information, and that's bad. I'm not even sure why
you do that, given that all the names are then handled the same as far
as I can see.

 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
 ---
  include/linux/mod_devicetable.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
 index c4db582..9d9d1f5 100644
 --- a/include/linux/mod_devicetable.h
 +++ b/include/linux/mod_devicetable.h
 @@ -379,7 +379,7 @@ struct virtio_device_id {
  
  /* i2c */
  
 -#define I2C_NAME_SIZE20
 +#define I2C_NAME_SIZE23
  #define I2C_MODULE_PREFIX i2c:
  
  struct i2c_device_id {


-- 
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/2] i2c: expand I2C's id.name to 23 characters

On Fri, Sep 19, 2008 at 10:03:08PM +0200, Jean Delvare wrote:
 On Fri, 19 Sep 2008 22:03:39 +0400, Anton Vorontsov wrote:
  It was discussed[1] that we should match on the first (most specific)
  entry in the device tree.
  
  The most lengthy I2C compatible entry for the MPC8349E-mITX MCU
  devices is mc9s08qg8-mpc8349emitx (w/o vendor name). This means
  that we have to allow longer IDs to be used in the I2C subsystem.
  
  [1] http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg21196.html
 
 Nack. Just come up with shorter names. mc9s08qg8-mpc8349emitx is
 simply too long to start with. Looking at the mcu_mpc8349emitx driver
 you just submitted, you are clearly abusing the i2c client name to pass
 platform-specific information, and that's bad. I'm not even sure why
 you do that, given that all the names are then handled the same as far
 as I can see.

The whole matching on the first entry thing is just a Linux-internal
heuristic.  If the heuristic breaks down (like it does here), then there
is a mechanism to override it in of_base.c which has a
compatible--modalias translation table.

g.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] edac: mpc85xx: Add support for MPC8572

2008-09-19 Thread Nate Case

From: Andrew Kilkenny [EMAIL PROTECTED]

This adds support for the dual-core MPC8572 processor.  We have
to support making SPR changes on each core.  Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.

Signed-off-by: Andrew Kilkenny [EMAIL PROTECTED]
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
 drivers/edac/mpc85xx_edac.c |   34 +++---
 1 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
 #include linux/io.h
 #include linux/mod_devicetable.h
 #include linux/edac.h
+#include linux/smp.h
 
 #include linux/of_platform.h
 #include linux/of_device.h
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
 #endif
 
 static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
 
 / MC SYSFS parts ***/
 
@@ -272,7 +273,8 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device 
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_pci_isr, IRQF_DISABLED,
+  mpc85xx_pci_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] PCI err, pci);
if (res  0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct of_device 
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_l2_isr, IRQF_DISABLED,
+  mpc85xx_l2_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] L2 err, edac_dev);
if (res  0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
 .compatible = fsl,8568-l2-cache-controller,
 },
+   {
+.compatible = fsl,8572-l2-cache-controller,
+},
{},
 };
 
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device 
*op,
/* register interrupts */
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_mc_isr, IRQF_DISABLED,
+  mpc85xx_mc_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] MC err, mci);
if (res  0) {
printk(KERN_ERR %s: Unable to request irq %d for 
@@ -980,6 +987,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
 .compatible = fsl,8568-memory-controller,
 },
+   {
+.compatible = fsl,8572-memory-controller,
+},
{},
 };
 
@@ -995,6 +1005,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
   },
 };
 
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+   orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+   mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()]  ~0x2));
+}
+
 static int __init mpc85xx_mc_init(void)
 {
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
 * so we can catch it
 */
if (edac_op_state == EDAC_OPSTATE_INT) {
-   orig_hid1 = mfspr(SPRN_HID1);
-   mtspr(SPRN_HID1, (orig_hid1  ~0x2));
+   on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
 
return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
 
 module_init(mpc85xx_mc_init);
 
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+   mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
 static void __exit mpc85xx_mc_exit(void)
 {
-   mtspr(SPRN_HID1, orig_hid1);
+   on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
 #ifdef CONFIG_PCI
of_unregister_platform_driver(mpc85xx_pci_err_driver);
 #endif
-- 
1.6.0.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting

2008-09-19 Thread Matthias Fuchs

Hi Kumar,

should I resend this my patch? Is there chance to get it applied.
It really fixes a bug!

Matthias

On Thursday 07 August 2008 15:19:10 Kumar Gala wrote:
 On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:
  This patch fixes the setting of the Book-E watchdog timer interval
  setup
  on initialization and by ioctl().
 
  Tested on PPC440EPx sequoia evaluation board.
 
  Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
  ---
  drivers/watchdog/booke_wdt.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

 can you be more explicit about what the bug was.

 - k
 ___
 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] edac: mpc85xx: Add support for MPC8572

2008-09-19 Thread Dave Jiang


Acked-by: Dave Jiang [EMAIL PROTECTED]

Nate Case wrote:

From: Andrew Kilkenny [EMAIL PROTECTED]

This adds support for the dual-core MPC8572 processor.  We have
to support making SPR changes on each core.  Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.

Signed-off-by: Andrew Kilkenny [EMAIL PROTECTED]
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
 drivers/edac/mpc85xx_edac.c |   34 +++---
 1 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
 #include linux/io.h
 #include linux/mod_devicetable.h
 #include linux/edac.h
+#include linux/smp.h
 
 #include linux/of_platform.h

 #include linux/of_device.h
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
 #endif
 
 static u32 orig_l2_err_disable;

-static u32 orig_hid1;
+static u32 orig_hid1[2];
 
 / MC SYSFS parts ***/
 
@@ -272,7 +273,8 @@ static int __devinit mpc85xx_pci_err_probe(struct of_device *op,

if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_pci_isr, IRQF_DISABLED,
+  mpc85xx_pci_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] PCI err, pci);
if (res  0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct of_device 
*op,
if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_l2_isr, IRQF_DISABLED,
+  mpc85xx_l2_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] L2 err, edac_dev);
if (res  0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
 .compatible = fsl,8568-l2-cache-controller,
 },
+   {
+.compatible = fsl,8572-l2-cache-controller,
+},
{},
 };
 
@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device *op,

/* register interrupts */
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_mc_isr, IRQF_DISABLED,
+  mpc85xx_mc_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] MC err, mci);
if (res  0) {
printk(KERN_ERR %s: Unable to request irq %d for 
@@ -980,6 +987,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
 .compatible = fsl,8568-memory-controller,
 },
+   {
+.compatible = fsl,8572-memory-controller,
+},
{},
 };
 
@@ -995,6 +1005,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {

   },
 };
 
+static void __init mpc85xx_mc_clear_rfxe(void *data)

+{
+   orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+   mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()]  ~0x2));
+}
+
 static int __init mpc85xx_mc_init(void)
 {
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
 * so we can catch it
 */
if (edac_op_state == EDAC_OPSTATE_INT) {
-   orig_hid1 = mfspr(SPRN_HID1);
-   mtspr(SPRN_HID1, (orig_hid1  ~0x2));
+   on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
 
 	return 0;

@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)
 
 module_init(mpc85xx_mc_init);
 
+static void __exit mpc85xx_mc_restore_hid1(void *data)

+{
+   mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
 static void __exit mpc85xx_mc_exit(void)
 {
-   mtspr(SPRN_HID1, orig_hid1);
+   on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
 #ifdef CONFIG_PCI
of_unregister_platform_driver(mpc85xx_pci_err_driver);
 #endif



--

--
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
--

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: Fix Book-E watchdog timer interval setting

Please repost and I'll look at it again.. I'm trying to be more  
diligent about patchworks.ozlabs.org and tracking things there.


- k

On Sep 19, 2008, at 4:28 PM, Matthias Fuchs wrote:


Hi Kumar,

should I resend this my patch? Is there chance to get it applied.
It really fixes a bug!

Matthias

On Thursday 07 August 2008 15:19:10 Kumar Gala wrote:

On Aug 7, 2008, at 7:48 AM, Matthias Fuchs wrote:

This patch fixes the setting of the Book-E watchdog timer interval
setup
on initialization and by ioctl().

Tested on PPC440EPx sequoia evaluation board.

Signed-off-by: Matthias Fuchs [EMAIL PROTECTED]
---
drivers/watchdog/booke_wdt.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)


can you be more explicit about what the bug was.

- k
___
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] edac: mpc85xx: Add support for MPC8572



On Sep 19, 2008, at 4:12 PM, Nate Case wrote:


From: Andrew Kilkenny [EMAIL PROTECTED]

This adds support for the dual-core MPC8572 processor.  We have
to support making SPR changes on each core.  Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.

Signed-off-by: Andrew Kilkenny [EMAIL PROTECTED]
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
drivers/edac/mpc85xx_edac.c |   34 +++---
1 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..0668492 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
#include linux/io.h
#include linux/mod_devicetable.h
#include linux/edac.h
+#include linux/smp.h

#include linux/of_platform.h
#include linux/of_device.h
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
#endif

static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];

/ MC SYSFS parts  
***/


@@ -272,7 +273,8 @@ static int __devinit  
mpc85xx_pci_err_probe(struct of_device *op,

if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_pci_isr, IRQF_DISABLED,
+  mpc85xx_pci_isr,
+  IRQF_DISABLED | IRQF_SHARED,


I don't have any issue with this, but why are you marking the PCI  
error interrupt as shared?	




   [EDAC] PCI err, pci);
if (res  0) {
printk(KERN_ERR
@@ -576,7 +578,8 @@ static int __devinit mpc85xx_l2_err_probe(struct  
of_device *op,

if (edac_op_state == EDAC_OPSTATE_INT) {
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_l2_isr, IRQF_DISABLED,
+  mpc85xx_l2_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] L2 err, edac_dev);


this I'm a bit more skeptical about.


if (res  0) {
printk(KERN_ERR
@@ -647,6 +650,9 @@ static struct of_device_id  
mpc85xx_l2_err_of_match[] = {

{
 .compatible = fsl,8568-l2-cache-controller,
 },
+   {
+.compatible = fsl,8572-l2-cache-controller,
+},


its fsl,mpc8572..  (we need to fix the others to match that convention  
as its pretty standard for other device tree nodes)




{},
};

@@ -912,7 +918,8 @@ static int __devinit mpc85xx_mc_err_probe(struct  
of_device *op,

/* register interrupts */
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_mc_isr, IRQF_DISABLED,
+  mpc85xx_mc_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] MC err, mci);
if (res  0) {
printk(KERN_ERR %s: Unable to request irq %d for 
@@ -980,6 +987,9 @@ static struct of_device_id  
mpc85xx_mc_err_of_match[] = {

{
 .compatible = fsl,8568-memory-controller,
 },
+   {
+.compatible = fsl,8572-memory-controller,
+},


ditto on 'fsl,mpc8572'



{},
};

@@ -995,6 +1005,12 @@ static struct of_platform_driver  
mpc85xx_mc_err_driver = {

   },
};

+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+   orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+   mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()]  ~0x2));
+}
+
static int __init mpc85xx_mc_init(void)
{
int res = 0;
@@ -1031,8 +1047,7 @@ static int __init mpc85xx_mc_init(void)
 * so we can catch it
 */
if (edac_op_state == EDAC_OPSTATE_INT) {
-   orig_hid1 = mfspr(SPRN_HID1);
-   mtspr(SPRN_HID1, (orig_hid1  ~0x2));
+   on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}

return 0;
@@ -1040,9 +1055,14 @@ static int __init mpc85xx_mc_init(void)

module_init(mpc85xx_mc_init);

+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+   mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
static void __exit mpc85xx_mc_exit(void)
{
-   mtspr(SPRN_HID1, orig_hid1);
+   on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
#ifdef CONFIG_PCI
of_unregister_platform_driver(mpc85xx_pci_err_driver);
#endif
--
1.6.0.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

patchwork states and workflow


Guys,

I've always been a bit confused about some of the states we can put a  
patch in.  For example, what does 'archiving' a patch mean?


What's the difference between 'deferred' and 'rejected'?  Is 'Under  
Review' useful?


My biggest question is how to manage the transition of 'Accepted' and  
'Awaiting Upstream' and having clear definitions of what we think  
these mean.


My preference is 'Accepted' means its been applied to someone's tree  
(mine, josh's, paul's, etc.) and 'Awaiting Upstream' is the state it  
goes into if we are waiting for a pull by Paul or Linus.  This does  
raise the issue of what state things should be in after the pull.


Comments?

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: patchwork states and workflow

2008-09-19 Thread David Miller


I'm not really interested in this dicussion, the states make sense
to me and I know how I will use them.

I'm also extremely backlogged as-is, and this will only compound
things.

Therefore, please drop me from the CC: list, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] edac: mpc85xx: Add support for MPC8572

2008-09-19 Thread Nate Case

On Fri, 2008-09-19 at 16:43 -0500, Kumar Gala wrote:
 I don't have any issue with this, but why are you marking the PCI  
 error interrupt as shared?
[snip]
 this I'm a bit more skeptical about.

The only one we really need to make shared is the memory controller
interrupt.  I'll drop it for the PCI and L2 interrupts in the next rev
of the patch.

 its fsl,mpc8572..  (we need to fix the others to match that convention  
 as its pretty standard for other device tree nodes)

I actually started out with fsl,mpc8572-* but then somehow convinced
myself I was wrong when I saw fsl,85xx in so many other places :)

Thanks for the feedback.  I'll correct these and re-submit.

-- 
Nate Case [EMAIL PROTECTED]

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: patchwork states and workflow

2008-09-19 Thread Paul Mackerras

Kumar Gala writes:

 I've always been a bit confused about some of the states we can put a  
 patch in.  For example, what does 'archiving' a patch mean?

Archiving puts the patch away somewhere where it doesn't appear in the
normal pages and needs extra effort to get to, as I understand it.

 What's the difference between 'deferred' and 'rejected'?  Is 'Under  
 Review' useful?

Deferred usually means the patch depends on something else that isn't
upstream, such as patches that only apply against the RT tree.
Rejected means we just don't want to do what the patch does.

 My biggest question is how to manage the transition of 'Accepted' and  
 'Awaiting Upstream' and having clear definitions of what we think  
 these mean.

I put patches into awaiting upstream when I put them in a bundle, so
it means that they have entered my QA process.  When they're in my
public tree, I put them into accepted state.

[BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't
explicitly remove you.  Presumably you are getting this thread through
the linuxppc-dev list.]

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: patchwork states and workflow

2008-09-19 Thread David Miller

From: Paul Mackerras [EMAIL PROTECTED]
Date: Fri, 19 Sep 2008 15:59:32 -0700

 [BTW, DaveM, you don't appear to be explicitly cc'd, so I couldn't
 explicitly remove you.  Presumably you are getting this thread through
 the linuxppc-dev list.]

Indeed, my bad :)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 3/3] USB: driver for Freescale QUICC Engine USB Host Controller

2008-09-19 Thread Andrew Morton

On Thu, 18 Sep 2008 19:17:46 +0400
Anton Vorontsov [EMAIL PROTECTED] wrote:

 This patch adds support for the FHCI USB controller, as found
 in the Freescale MPC836x and MPC832x processors. It can support
 Full or Low speed modes.
 
 Quite a lot the hardware is doing by itself (SOF generation, CRC
 generation and checking), though scheduling and retransmission is on
 software's shoulders.
 
 This controller does not integrate the root hub, so this driver also
 fakes one-port hub. External hub is required to support more than
 one device.

 ...


Please, no.

 new file mode 100644
 index 000..23716fa
 --- /dev/null
 +++ b/drivers/usb/host/fhci-cq.c
 @@ -0,0 +1,105 @@
 +/*
 + * Freescale QUICC Engine USB Host Controller Driver
 + *
 + * Copyright (c) Freescale Semicondutor, Inc. 2006.
 + *   Shlomi Gridish [EMAIL PROTECTED]
 + *   Jerry Huang [EMAIL PROTECTED]
 + * Copyright (c) Logic Product Development, Inc. 2007
 + *   Peter Barada [EMAIL PROTECTED]
 + * Copyright (c) MontaVista Software, Inc. 2008.
 + *   Anton Vorontsov [EMAIL PROTECTED]
 + *
 + * 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.
 + */
 +
 +/* circular queue structure */

Yet another private ringbuffer implementation.  Sigh.

 +struct cir_q {
 +   int max;  /* size of queue */
 +   int max_in;   /* max items in queue */
 +   int first;/* index of first in queue */
 +   int last; /* index after last in queue */
 +   int read; /* current reading position */
 +   void *table[1];   /* fake size */
 +};
 +
 +/* circular queue handle */
 +static int cq_howmany(struct cir_q *cq)
 +{
 + int l = cq-last;
 + int f = cq-first;
 +
 + return l = f ? l - f : l + cq-max - f;
 +}
 +
 +static struct cir_q *cq_new(int size)
 +{
 + struct cir_q *cq;
 +
 + cq = kzalloc((sizeof(*cq) + size * sizeof(void *)), GFP_KERNEL);
 + if (cq) {
 + cq-max = size;
 + cq-first = 0;
 + cq-last = 0;
 + cq-read = 0;
 + cq-max_in = 0;

The above four statements are unneeded.

 + }
 +
 + return cq;
 +}

 ...

 +++ b/drivers/usb/host/fhci-hcd.c
 @@ -0,0 +1,798 @@
 +/*
 + * Freescale QUICC Engine USB Host Controller Driver
 + *
 + * Copyright (c) Freescale Semicondutor, Inc. 2006.
 + *   Shlomi Gridish [EMAIL PROTECTED]
 + *   Jerry Huang [EMAIL PROTECTED]
 + * Copyright (c) Logic Product Development, Inc. 2007
 + *   Peter Barada [EMAIL PROTECTED]
 + * Copyright (c) MontaVista Software, Inc. 2008.
 + *   Anton Vorontsov [EMAIL PROTECTED]
 + *
 + * 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.
 + */
 +
 +#if defined(CONFIG_FHCI_DEBUG)  !defined(DEBUG)
 +#define DEBUG
 +#endif
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/delay.h
 +#include linux/errno.h
 +#include linux/list.h
 +#include linux/interrupt.h
 +#include linux/io.h
 +#include linux/usb.h
 +#include linux/of_platform.h
 +#include linux/of_gpio.h
 +#include asm/qe.h
 +#include asm/fsl_gtm.h
 +#include ../core/hcd.h
 +#include fhci.h
 +#include fhci-hub.c
 +#include fhci-q.c
 +#include fhci-dbg.c
 +#include fhci-mem.c
 +#include fhci-cq.c
 +#include fhci-tds.c
 +#include fhci-sched.c

hack, gack, nack.

We know that USB likes to prevertedly #include C files all over the
place, but this doesn't mean that it's a sane, tasteful or desirable
thing to do.

I stopped looking there.  Guys - get a grip :(
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH v2] edac: mpc85xx: Add support for MPC8572

2008-09-19 Thread Nate Case

From: Andrew Kilkenny [EMAIL PROTECTED]

This adds support for the dual-core MPC8572 processor.  We have
to support making SPR changes on each core.  Also, since we can
have multiple memory controllers sharing an interrupt, flag the
interrupts with IRQF_SHARED.

Signed-off-by: Andrew Kilkenny [EMAIL PROTECTED]
Signed-off-by: Nate Case [EMAIL PROTECTED]
---
 drivers/edac/mpc85xx_edac.c |   28 +++-
 1 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index 2265d9c..63bdc47 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -17,6 +17,7 @@
 #include linux/io.h
 #include linux/mod_devicetable.h
 #include linux/edac.h
+#include linux/smp.h
 
 #include linux/of_platform.h
 #include linux/of_device.h
@@ -40,7 +41,7 @@ static u32 orig_pci_err_en;
 #endif
 
 static u32 orig_l2_err_disable;
-static u32 orig_hid1;
+static u32 orig_hid1[2];
 
 / MC SYSFS parts ***/
 
@@ -647,6 +648,9 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
{
 .compatible = fsl,8568-l2-cache-controller,
 },
+   {
+.compatible = fsl,mpc8572-l2-cache-controller,
+},
{},
 };
 
@@ -912,7 +916,8 @@ static int __devinit mpc85xx_mc_err_probe(struct of_device 
*op,
/* register interrupts */
pdata-irq = irq_of_parse_and_map(op-node, 0);
res = devm_request_irq(op-dev, pdata-irq,
-  mpc85xx_mc_isr, IRQF_DISABLED,
+  mpc85xx_mc_isr,
+  IRQF_DISABLED | IRQF_SHARED,
   [EDAC] MC err, mci);
if (res  0) {
printk(KERN_ERR %s: Unable to request irq %d for 
@@ -980,6 +985,9 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{
 .compatible = fsl,8568-memory-controller,
 },
+   {
+.compatible = fsl,mpc8572-memory-controller,
+},
{},
 };
 
@@ -995,6 +1003,12 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
   },
 };
 
+static void __init mpc85xx_mc_clear_rfxe(void *data)
+{
+   orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
+   mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()]  ~0x2));
+}
+
 static int __init mpc85xx_mc_init(void)
 {
int res = 0;
@@ -1031,8 +1045,7 @@ static int __init mpc85xx_mc_init(void)
 * so we can catch it
 */
if (edac_op_state == EDAC_OPSTATE_INT) {
-   orig_hid1 = mfspr(SPRN_HID1);
-   mtspr(SPRN_HID1, (orig_hid1  ~0x2));
+   on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
}
 
return 0;
@@ -1040,9 +1053,14 @@ static int __init mpc85xx_mc_init(void)
 
 module_init(mpc85xx_mc_init);
 
+static void __exit mpc85xx_mc_restore_hid1(void *data)
+{
+   mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
+}
+
 static void __exit mpc85xx_mc_exit(void)
 {
-   mtspr(SPRN_HID1, orig_hid1);
+   on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
 #ifdef CONFIG_PCI
of_unregister_platform_driver(mpc85xx_pci_err_driver);
 #endif
-- 
1.6.0.2

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: patchwork states and workflow

2008-09-19 Thread Benjamin Herrenschmidt

On Fri, 2008-09-19 at 15:59 -0700, Paul Mackerras wrote:
 Kumar Gala writes:
 
  I've always been a bit confused about some of the states we can put a  
  patch in.  For example, what does 'archiving' a patch mean?
 
 Archiving puts the patch away somewhere where it doesn't appear in the
 normal pages and needs extra effort to get to, as I understand it.
 
  What's the difference between 'deferred' and 'rejected'?  Is 'Under  
  Review' useful?
 
 Deferred usually means the patch depends on something else that isn't
 upstream, such as patches that only apply against the RT tree.
 Rejected means we just don't want to do what the patch does.
 
  My biggest question is how to manage the transition of 'Accepted' and  
  'Awaiting Upstream' and having clear definitions of what we think  
  these mean.
 
 I put patches into awaiting upstream when I put them in a bundle, so
 it means that they have entered my QA process.  When they're in my
 public tree, I put them into accepted state.

Note, Kumar, that I have a git hook that will generate a file that
lists the sha1 and corresponding patchwork IDs when you use git-am.

I can send that to you when I'm back.

You can then use a little tool that automatically update patchwork based
on that file, filing the SHA1 reference in the database and switching
the patches to accepted state.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc


if I write :
ioremap(0x2000,0x4) and ioremap(0x2000,0x5)

Will it crash ?

Josh Boyer a écrit :

On Fri, Sep 19, 2008 at 06:34:06PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:
  

The first is ioremap(0x2000,0x1000);
The second is ioremap(0x8000,0x1000);
Is it too long



The error message you are getting should have been a very strong hint that
the answer is yes.

josh
___
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: ioremap and vmalloc


I made a mistake. The right code is :

ioremap(0x2000,0x4) and ioremap(0x8000,0x5)



Grant Likely a écrit :

On Fri, Sep 19, 2008 at 10:58 AM, Josh Boyer [EMAIL PROTECTED] wrote:
  

On Fri, Sep 19, 2008 at 06:45:01PM +0200, 
=?ISO-8859-1?Q?S=E9bastien_Chr=E9tien_ wrote:


if I write :
ioremap(0x2000,0x4) and ioremap(0x2000,0x5)

Will it crash ?
  

I have no idea.  You haven't given us enough information to really answer
that.



But I can say that the second ioremap() call makes the first ioremap()
both redundant and inefficient.  You're using exactly the same base
address so the same region is getting mapped twice.  Since the second
call uses a bigger region than the first then the kernel will probably
need to allocate another chunk of virtual address space to map it
instead of reusing the first mapping.

g.


  

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: ioremap and vmalloc