date:20090820

RE: [PATCH] [V2] net: add Xilinx emac lite device driver

2009-08-20 Thread John Linn

 -Original Message-
 From: David Miller [mailto:da...@davemloft.net]
 Sent: Thursday, August 20, 2009 10:31 AM
 To: michal.si...@petalogix.com
 Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org;
jgar...@pobox.com;
 grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com;
john.willi...@petalogix.com; Sadanand Mutyala
 Subject: Re: [PATCH] [V2] net: add Xilinx emac lite device driver

 From: Michal Simek michal.si...@petalogix.com
 Date: Thu, 20 Aug 2009 11:28:48 +0200

  There were one bug with spinlock which John L fixed but not send to
  mainling list. :-(
  He wanted to create new v3 version. :-(.
  When he wake up, he send you that bug fix or v3 version with it.

 Send a new version, I'll revert V2 from my tree as I didn't push it
 out yet.

I'll send a V3 version very soon, thanks. 

Sorry for the hassle as I thought there would be more comments and I'd
incorporate the bug fix into those.

Appreciate your help.

-- John

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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

[PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread John Linn

This patch adds support for the Xilinx Ethernet Lite device.  The
soft logic core from Xilinx is typically used on Virtex and Spartan
designs attached to either a PowerPC or a Microblaze processor.

CC: Grant Likely grant.lik...@secretlab.ca
CC: Josh Boyer jwbo...@linux.vnet.ibm.com
CC: John Williams john.willi...@petalogix.com
CC: Michal Simek michal.si...@petalogix.com
Signed-off-by: Sadanand M sada...@xilinx.com
Signed-off-by: John Linn john.l...@xilinx.com

---

V2 - cleanup based on review, added depends for ppc and mb in Kconfig
V3 - fixed bug, spin lock was not initialized
---
 drivers/net/Kconfig   |6 +
 drivers/net/Makefile  |1 +
 drivers/net/xilinx_emaclite.c | 1041 +
 3 files changed, 1048 insertions(+), 0 deletions(-)
 create mode 100755 drivers/net/xilinx_emaclite.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 5f6509a..ec77b69 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1926,6 +1926,12 @@ config ATL2
  To compile this driver as a module, choose M here.  The module
  will be called atl2.
 
+config XILINX_EMACLITE
+   tristate Xilinx 10/100 Ethernet Lite support
+   depends on PPC32 || MICROBLAZE
+   help
+ This driver supports the 10/100 Ethernet Lite from Xilinx.
+
 source drivers/net/fs_enet/Kconfig
 
 endif # NET_ETHERNET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index ead8cab..99ae6d7 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -142,6 +142,7 @@ obj-$(CONFIG_TSI108_ETH) += tsi108_eth.o
 obj-$(CONFIG_MV643XX_ETH) += mv643xx_eth.o
 ll_temac-objs := ll_temac_main.o ll_temac_mdio.o
 obj-$(CONFIG_XILINX_LL_TEMAC) += ll_temac.o
+obj-$(CONFIG_XILINX_EMACLITE) += xilinx_emaclite.o
 obj-$(CONFIG_QLA3XXX) += qla3xxx.o
 obj-$(CONFIG_QLGE) += qlge/
 
diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
new file mode 100755
index 000..7e05b40
--- /dev/null
+++ b/drivers/net/xilinx_emaclite.c
@@ -0,0 +1,1041 @@
+/*
+ * Xilinx EmacLite Linux driver for the Xilinx Ethernet MAC Lite device.
+ *
+ * This is a new flat driver which is based on the original emac_lite
+ * driver from John Williams john.willi...@petalogix.com.
+ *
+ * 2007-2009 (c) Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/module.h
+#include linux/uaccess.h
+#include linux/init.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/skbuff.h
+#include linux/io.h
+
+#include linux/of_device.h
+#include linux/of_platform.h
+
+#define DRIVER_NAME xilinx_emaclite
+
+/* Register offsets for the EmacLite Core */
+#define XEL_TXBUFF_OFFSET  0x0 /* Transmit Buffer */
+#define XEL_GIER_OFFSET0x07F8  /* GIE Register */
+#define XEL_TSR_OFFSET 0x07FC  /* Tx status */
+#define XEL_TPLR_OFFSET0x07F4  /* Tx packet length */
+
+#define XEL_RXBUFF_OFFSET  0x1000  /* Receive Buffer */
+#define XEL_RPLR_OFFSET0x100C  /* Rx packet length */
+#define XEL_RSR_OFFSET 0x17FC  /* Rx status */
+
+#define XEL_BUFFER_OFFSET  0x0800  /* Next Tx/Rx buffer's offset */
+
+/* Global Interrupt Enable Register (GIER) Bit Masks */
+#define XEL_GIER_GIE_MASK  0x8000  /* Global Enable */
+
+/* Transmit Status Register (TSR) Bit Masks */
+#define XEL_TSR_XMIT_BUSY_MASK  0x0001 /* Tx complete */
+#define XEL_TSR_PROGRAM_MASK0x0002 /* Program the MAC address */
+#define XEL_TSR_XMIT_IE_MASK0x0008 /* Tx interrupt enable bit */
+#define XEL_TSR_XMIT_ACTIVE_MASK 0x8000/* Buffer is active, SW bit
+* only. This is not documented
+* in the HW spec */
+
+/* Define for programming the MAC address into the EmacLite */
+#define XEL_TSR_PROG_MAC_ADDR  (XEL_TSR_XMIT_BUSY_MASK | XEL_TSR_PROGRAM_MASK)
+
+/* Receive Status Register (RSR) */
+#define XEL_RSR_RECV_DONE_MASK 0x0001  /* Rx complete */
+#define XEL_RSR_RECV_IE_MASK   0x0008  /* Rx interrupt enable bit */
+
+/* Transmit Packet Length Register (TPLR) */
+#define XEL_TPLR_LENGTH_MASK   0x  /* Tx packet length */
+
+/* Receive Packet Length Register (RPLR) */
+#define XEL_RPLR_LENGTH_MASK   0x  /* Rx packet length */
+
+#define XEL_HEADER_OFFSET  12  /* Offset to length field */
+#define XEL_HEADER_SHIFT   16  /* Shift value for length */
+
+/* General Ethernet Definitions */
+#define XEL_ARP_PACKET_SIZE28  /* Max ARP packet size */
+#define XEL_HEADER_IP_LENGTH_OFFSET16  /* IP Length Offset */
+
+

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread David Miller

From: John Linn john.l...@xilinx.com
Date: Thu, 20 Aug 2009 03:49:51 -0600

 This patch adds support for the Xilinx Ethernet Lite device.  The
 soft logic core from Xilinx is typically used on Virtex and Spartan
 designs attached to either a PowerPC or a Microblaze processor.

 Signed-off-by: Sadanand M sada...@xilinx.com
 Signed-off-by: John Linn john.l...@xilinx.com

Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

2009-08-20 Thread Michal Simek

David Miller wrote:
 From: John Linn john.l...@xilinx.com
 Date: Wed, 19 Aug 2009 06:29:11 -0600

 This patch adds support for the Xilinx Ethernet Lite device.  The
 soft logic core from Xilinx is typically used on Virtex and Spartan
 designs attached to either a PowerPC or a Microblaze processor.

 Signed-off-by: Sadanand M sada...@xilinx.com
 Signed-off-by: John Linn john.l...@xilinx.com

 Looks good, applied to net-next-2.6, thanks!

There were one bug with spinlock which John L fixed but not send to
mainling list. :-(
He wanted to create new v3 version. :-(.
When he wake up, he send you that bug fix or v3 version with it.

Regards,
Michal

-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

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

Re: [PATCH 1/2] powerpc/405ex: provide necessary fixup function to support cuImage

2009-08-20 Thread Josh Boyer

On Tue, Aug 18, 2009 at 10:28:03AM +0800, Tiejun Chen wrote:
For cuImage format it's necessary to provide clock fixups since u-boot will
not pass necessary clock frequency into the dtb included into cuImage so we 
implement the clock fixups as defined in the technical documentation for the 
board and update header file with the basic register definitions. 

Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
 arch/powerpc/boot/4xx.c |  142 +++
 arch/powerpc/boot/4xx.h |1 +
 arch/powerpc/boot/dcr.h |   12 
 3 files changed, 155 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
index 325b310..b5561b3 100644
--- a/arch/powerpc/boot/4xx.c
+++ b/arch/powerpc/boot/4xx.c
@@ -8,6 +8,10 @@
  *   Eugene Surovegin eugene.surove...@zultys.com or e...@ebshome.net
  *   Copyright (c) 2003, 2004 Zultys Technologies
  *
+ * Copyright (C) 2009 Wind River Systems, Inc.
+ *   Updated for supporting PPC405EX on Kilauea.
+ *   Tiejun Chen tiejun.c...@windriver.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
@@ -659,3 +663,141 @@ void ibm405ep_fixup_clocks(unsigned int sys_clk)
   dt_fixup_clock(/plb/opb/ser...@ef600300, uart0);
   dt_fixup_clock(/plb/opb/ser...@ef600400, uart1);
 }
+
+static u8 fwdv_multi_bits[] = {
+  /* values for:  1 - 16 */
+  0x01, 0x02, 0x0e, 0x09, 0x04, 0x0b, 0x10, 0x0d, 0x0c, 0x05,
+  0x06, 0x0f, 0x0a, 0x07, 0x08, 0x03
+};
+
+u32 get_fwdva(unsigned long cpr_fwdv)
+{
+  u32 index;
+
+  for (index = 0; index  ARRAY_SIZE(fwdv_multi_bits); index++)
+  if (cpr_fwdv == (u32)fwdv_multi_bits[index])
+  return index + 1;
+
+  return 0;
+}
+
+static u8 fbdv_multi_bits[] = {
+  /* values for:  1 - 100 */
+  0x00, 0xff, 0x7e, 0xfd, 0x7a, 0xf5, 0x6a, 0xd5, 0x2a, 0xd4,
+  0x29, 0xd3, 0x26, 0xcc, 0x19, 0xb3, 0x67, 0xce, 0x1d, 0xbb,
+  0x77, 0xee, 0x5d, 0xba, 0x74, 0xe9, 0x52, 0xa5, 0x4b, 0x96,
+  0x2c, 0xd8, 0x31, 0xe3, 0x46, 0x8d, 0x1b, 0xb7, 0x6f, 0xde,
+  0x3d, 0xfb, 0x76, 0xed, 0x5a, 0xb5, 0x6b, 0xd6, 0x2d, 0xdb,
+  0x36, 0xec, 0x59, 0xb2, 0x64, 0xc9, 0x12, 0xa4, 0x48, 0x91,
+  0x23, 0xc7, 0x0e, 0x9c, 0x38, 0xf0, 0x61, 0xc2, 0x05, 0x8b,
+  0x17, 0xaf, 0x5f, 0xbe, 0x7c, 0xf9, 0x72, 0xe5, 0x4a, 0x95,
+  0x2b, 0xd7, 0x2e, 0xdc, 0x39, 0xf3, 0x66, 0xcd, 0x1a, 0xb4,
+  0x68, 0xd1, 0x22, 0xc4, 0x09, 0x93, 0x27, 0xcf, 0x1e, 0xbc,
+  /* values for:  101 - 200 */
+  0x78, 0xf1, 0x62, 0xc5, 0x0a, 0x94, 0x28, 0xd0, 0x21, 0xc3,
+  0x06, 0x8c, 0x18, 0xb0, 0x60, 0xc1, 0x02, 0x84, 0x08, 0x90,
+  0x20, 0xc0, 0x01, 0x83, 0x07, 0x8f, 0x1f, 0xbf, 0x7f, 0xfe,
+  0x7d, 0xfa, 0x75, 0xea, 0x55, 0xaa, 0x54, 0xa9, 0x53, 0xa6,
+  0x4c, 0x99, 0x33, 0xe7, 0x4e, 0x9d, 0x3b, 0xf7, 0x6e, 0xdd,
+  0x3a, 0xf4, 0x69, 0xd2, 0x25, 0xcb, 0x16, 0xac, 0x58, 0xb1,
+  0x63, 0xc6, 0x0d, 0x9b, 0x37, 0xef, 0x5e, 0xbd, 0x7b, 0xf6,
+  0x6d, 0xda, 0x35, 0xeb, 0x56, 0xad, 0x5b, 0xb6, 0x6c, 0xd9,
+  0x32, 0xe4, 0x49, 0x92, 0x24, 0xc8, 0x11, 0xa3, 0x47, 0x8e,
+  0x1c, 0xb8, 0x70, 0xe1, 0x42, 0x85, 0x0b, 0x97, 0x2f, 0xdf,
+  /* values for:  201 - 255 */
+  0x3e, 0xfc, 0x79, 0xf2, 0x65, 0xca, 0x15, 0xab, 0x57, 0xae,
+  0x5c, 0xb9, 0x73, 0xe6, 0x4d, 0x9a, 0x34, 0xe8, 0x51, 0xa2,
+  0x44, 0x89, 0x13, 0xa7, 0x4f, 0x9e, 0x3c, 0xf8, 0x71, 0xe2,
+  0x45, 0x8a, 0x14, 0xa8, 0x50, 0xa1, 0x43, 0x86, 0x0c, 0x98,
+  0x30, 0xe0, 0x41, 0x82, 0x04, 0x88, 0x10, 0xa0, 0x40, 0x81,
+  0x03, 0x87, 0x0f, 0x9f, 0x3f  /* END */
+};
+
+u32 get_fbdv(unsigned long cpr_fbdv)
+{
+  u32 index;
+
+  for (index = 0; index  ARRAY_SIZE(fbdv_multi_bits); index++)
+  if (cpr_fbdv == (u32)fbdv_multi_bits[index])
+  return index + 1;
+
+  return 0;
+}

Is this generic?  Can we the function and value arrays to get the fbdv for
all 4xx boards and have the right values pop out?  If not, then all of these
need to be prefixed with ibm405ex_.

diff --git a/arch/powerpc/boot/dcr.h b/arch/powerpc/boot/dcr.h
index 95b9f53..ba41624 100644
--- a/arch/powerpc/boot/dcr.h
+++ b/arch/powerpc/boot/dcr.h
@@ -153,6 +153,18 @@ static const unsigned long sdram_bxcr[] = { SDRAM0_B0CR, 
SDRAM0_B1CR,
 #define DCRN_CPC0_PLLMR1  0xf4
 #define DCRN_CPC0_UCR 0xf5

+/* 405EX Clocking Control regs */
+#define CPR0_CLKUPD 0x0020
+#define CPR0_PLLC   0x0040
+#define CPR0_PLLD   0x0060
+#define CPR0_CPUD   0x0080
+#define CPR0_PLBD   0x00a0
+#define CPR0_OPBD   0x00c0
+#define CPR0_PERD   0x00e0
+#define CPR0_AHBD   0x0100
+#define CPR0_ICFG   0x0140

You duplicated the #defines right below this.  Just change the comment for
the already existing defines to say 440GX/405EX Clock Control regs.  You
don't need to add

Re: [PATCH 2/2] powerpc/405ex: support cuImage via included dtb

2009-08-20 Thread Josh Boyer

On Tue, Aug 18, 2009 at 10:28:04AM +0800, Tiejun Chen wrote:
To support cuImage, we need to initialize the required sections and 
ensure that it is built.

-  cuboot-acadia.c cuboot-amigaone.c
+  cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c
 src-boot := $(src-wlib) $(src-plat) empty.c

 src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -192,6 +192,7 @@ image-$(CONFIG_DEFAULT_UIMAGE) += uImage
 image-$(CONFIG_EP405) += dtbImage.ep405
 image-$(CONFIG_WALNUT)+= treeImage.walnut
 image-$(CONFIG_ACADIA)+= cuImage.acadia
+image-$(CONFIG_KILAUEA)   += cuImage.kilauea

I'm not thrilled with this part as cuImage is really the secondary
solution if the U-Boot that comes with a board if FDT aware.  If you
have a different board that needs this, perhaps you could add the
target when that board support gets upstream?

+static void kilauea_fixups(void)
+{
+  /*TODO: Please change this as the real. Note that should be 
33MHZ~100MHZ.*/

What does that mean?

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

RE: [PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread Stephen Neuendorffer


John,

I just got a chance to browse this...  Do you want to put in the
stripped device names?

.compatible = xlnx,xps-ethernetlite-2, etc...

Steve

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


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

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread Stephen Hemminger

On Thu, 20 Aug 2009 03:49:51 -0600
John Linn john.l...@xilinx.com wrote:

 +/**
 + * xemaclite_ioctl - Perform IO Control operations on the network device
 + * @dev: Pointer to the network device
 + * @rq:  Pointer to the interface request structure
 + * @cmd: IOCTL command
 + *
 + * The only IOCTL operation supported by this function is setting the MAC
 + * address. An error is reported if any other operations are requested.
 + *
 + * Return:   0 to indicate success, or a negative error for failure.
 + */
 +static int xemaclite_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
 +{
 + struct net_local *lp = (struct net_local *) netdev_priv(dev);
 + struct hw_addr_data *hw_addr = (struct hw_addr_data *) rq-ifr_hwaddr;
 +
 + switch (cmd) {
 + case SIOCETHTOOL:
 + return -EIO;
 +
 + case SIOCSIFHWADDR:
 + dev_err(lp-ndev-dev, SIOCSIFHWADDR\n);
 +
 + /* Copy MAC address in from user space */
 + copy_from_user((void __force *) dev-dev_addr,
 +(void __user __force *) hw_addr,
 +IFHWADDRLEN);
 + xemaclite_set_mac_address(lp, dev-dev_addr);
 + break;
 + default:
 + return -EOPNOTSUPP;
 + }
 +
 + return 0;
 +}

Do you really need this? I doubt the SIOCSIFHWADDR even reaches driver!

The normal call path for setting hardware address is:
  dev_ifsioc
 dev_set_mac_address
 ops-ndo_set_mac_address -- 

The driver should be:
   1. defining new code to do ndo_set_mac_address
   2. remove existing xmaclite_ioctl - all ioctl's handled by upper layers

FYI - the only ioctl's that make it to network device ndo_ioctl
 are listed in dev_ifsioc
   SIOCDEVPRIVATE ... SIOCDEVPRIVATE + 15
   SIOCBOND*
   SIOCMII*
   SIOCBR*
   SIOCHWTSTAMP
   SIOCWANDEV


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

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread Grant Likely

On Thu, Aug 20, 2009 at 10:02 AM, Stephen
Neuendorfferstephen.neuendorf...@xilinx.com wrote:

 John,

 I just got a chance to browse this...  Do you want to put in the
 stripped device names?

 .compatible = xlnx,xps-ethernetlite-2, etc...

We've covered this territory before.  Compatible values need to be
exact for the IP cores.  No wildcards. No abbreviations or stripping.
Newer cores can claim compatibility with older when appropriate.

g.

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

Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC

2009-08-20 Thread Solomon Peachy

On Mon, Aug 17, 2009 at 11:13:59AM -0400, Josh Boyer wrote:
 There is another way.  Perhaps you could just copy ppcboot.h to a new file
 called hotfoot.h and just use that.  It's a duplication of ppcboot.h to
 some degree, but it seems to make sense for your board and it helps preserve
 the stock ppcboot.h for other boards.
 
 Solomon, any update on this?  As far as I'm concerned, the ppcboot.h issue is
 the only thing that really needs to be reworked before we bring this patch
 in.

Should I call the new version 'hotfoot.h' or 'ppcboot-hotfoot.h'? 

 - Solomon
-- 
Solomon Peachysolo...@linux-wlan.com
AbsoluteValue Systems http://www.linux-wlan.com
721-D North Drive +1 (321) 259-0737  (office)
Melbourne, FL 32934   +1 (321) 259-0286  (fax)


pgpohZOEwPAwa.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] [V3] net: add Xilinx emac lite device driver

2009-08-20 Thread Stephen Neuendorffer

Sorry... you're right... brain fart on my part.. :)

Steve

 -Original Message-
 From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant 
 Likely
 Sent: Thursday, August 20, 2009 10:45 AM
 To: Stephen Neuendorffer
 Cc: John Linn; net...@vger.kernel.org; linuxppc-...@ozlabs.org; 
 da...@davemloft.net;
 jgar...@pobox.com; John Linn; Sadanand Mutyala; John Williams; Michal Simek
 Subject: Re: [PATCH] [V3] net: add Xilinx emac lite device driver

 On Thu, Aug 20, 2009 at 10:02 AM, Stephen
 Neuendorfferstephen.neuendorf...@xilinx.com wrote:

  John,

  I just got a chance to browse this...  Do you want to put in the
  stripped device names?

  .compatible = xlnx,xps-ethernetlite-2, etc...

 We've covered this territory before.  Compatible values need to be
 exact for the IP cores.  No wildcards. No abbreviations or stripping.
 Newer cores can claim compatibility with older when appropriate.

 g.

 --
 Grant Likely, B.Sc., P.Eng.
 Secret Lab Technologies Ltd.

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

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

Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC

2009-08-20 Thread Josh Boyer

On Thu, Aug 20, 2009 at 01:45:19PM -0400, Solomon Peachy wrote:
On Mon, Aug 17, 2009 at 11:13:59AM -0400, Josh Boyer wrote:
 There is another way.  Perhaps you could just copy ppcboot.h to a new file
 called hotfoot.h and just use that.  It's a duplication of ppcboot.h to
 some degree, but it seems to make sense for your board and it helps preserve
 the stock ppcboot.h for other boards.
 
 Solomon, any update on this?  As far as I'm concerned, the ppcboot.h issue is
 the only thing that really needs to be reworked before we bring this patch
 in.

Should I call the new version 'hotfoot.h' or 'ppcboot-hotfoot.h'? 

Either works for me.

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

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread Sean MacLennan

On Thu, 20 Aug 2009 07:01:21 +0200
Stefan Roese s...@denx.de wrote:

 On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
   I see other boards using SMC as well, can someone comment on the
   change I am proposing.
   Should I change the correction algorithm or the calculate
   function? If the later is preferred
   it would mean the change must be pushed in both U-Boot and Linux.
 
  Odds are the calculate function is wrong. The correction algo is
  used by many nand drivers, I *assume* it is correct. The calculate
  function was set to agree with u-boot (1.3.0).
 
 Yes, it seems that you changed the order in the calculation function
 while reworking the NDFC driver for arch/powerpc. So we should
 probably change this order back to the original version. And change
 it in U-Boot as well.
 
 BTW: I didn't see any problems with ECC so far with the current code.
 Feng, how did you spot this problem?

Ok, I think I have reproduced the problem programmatically. Basically,
I force a one bit error with the following patch:

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 8c21b89..91dd5b4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1628,11 +1628,22 @@ static void nand_write_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
uint8_t *ecc_calc = chip-buffers-ecccalc;
const uint8_t *p = buf;
uint32_t *eccpos = chip-ecc.layout-eccpos;
+   static int count;
 
for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
chip-ecc.hwctl(mtd, NAND_ECC_WRITE);
-   chip-write_buf(mtd, p, eccsize);
-   chip-ecc.calculate(mtd, p, ecc_calc[i]);
+   if (count == 0) {
+   count = 1;
+   printk(Corrupt one bit: %08x = %08x\n,
+  *p, *p ^ 8);
+   *(uint8_t *)p ^= 8;
+   chip-write_buf(mtd, p, eccsize);
+   *(uint8_t *)p ^= 8;
+   nand_calculate_ecc(mtd, p, ecc_calc[i]);
+   } else {
+   chip-write_buf(mtd, p, eccsize);
+   chip-ecc.calculate(mtd, p, ecc_calc[i]);
+   }
}
 
for (i = 0; i  chip-ecc.total; i++)

Basically I write a one bit error to the NAND, but calculate with the
correct bit. This assumes nand_calculate_ecc is correct.

I then added debugs to the correction to make sure it corrected
properly:

diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
index c0cb87d..57dcaa1 100644
--- a/drivers/mtd/nand/nand_ecc.c
+++ b/drivers/mtd/nand/nand_ecc.c
@@ -483,14 +483,20 @@ int nand_correct_data(struct mtd_info *mtd, unsigned char 
*buf,
byte_addr = (addressbits[b2  0x3]  8) +
(addressbits[b1]  4) + addressbits[b0];
bit_addr = addressbits[b2  2];
+
+   printk(Single bit error: correct %08x = %08x\n,
+  buf[byte_addr], buf[byte_addr] ^ (1  bit_addr));
+
/* flip the bit */
buf[byte_addr] ^= (1  bit_addr);
return 1;
 
}
/* count nr of bits; use table lookup, faster than calculating it */
-   if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1)
+   if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1) {
+   printk(ECC DATA BAD\n); // SAM DBG
return 1;   /* error in ecc data; no action needed */
+   }
 
printk(KERN_ERR uncorrectable error : );
return -1;

With the current ndfc code, the error correction gets the bits wrong.
Switching it back to the original way and the correction is correct.

diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 89bf85a..497e175 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -101,9 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
 
wmb();
ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
-   /* The NDFC uses Smart Media (SMC) bytes order */
-   ecc_code[0] = p[2];
-   ecc_code[1] = p[1];
+   ecc_code[0] = p[1];
+   ecc_code[1] = p[2];
ecc_code[2] = p[3];
 
return 0;

Does anybody see a problem with my method of reproducing the bug? This
bug is deadly for our customers. I don't want to make the change unless
it is absolutely necessary.

Cheers,
   Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Author: Solomon Peachy solo...@linux-wlan.com

2009-08-20 Thread Solomon Peachy

[PATCH v2] Add support for the ESTeem 195E (PPC405EP) SBC

This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.

The 195E boards use ancient versions of u-boot and a slightly mangled
verison of the oft-abused ppcboot header.  (v2 of this patch moves the
modified ppcboot header into ppcboot-hotfoot.h)

There are several variants of the SBC deployed, single/dual
ethernet+serial, and also 4MB/8MB flash variations.  In the interest of
having a single kernel image boot on all boards, the cuboot shim detects
the differences and mangles the DTS tree appropriately.

With the exception of the CF interface that was never populated on
production boards, this code/DTS supports all boardpop options.

Signed-off-by:  Solomon Peachy solo...@linux-wlan.com

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9ae7b7e..5a109a9 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -39,6 +39,7 @@ DTS_FLAGS ?= -p 1024
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-hotfoot.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
@@ -67,7 +68,7 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
 src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c 
holly.c \
-   cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+   cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
@@ -190,6 +191,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)  += uImage
 
 # Board ports in arch/powerpc/platform/40x/Kconfig
 image-$(CONFIG_EP405)  += dtbImage.ep405
+image-$(CONFIG_HOTFOOT)+= cuImage.hotfoot
 image-$(CONFIG_WALNUT) += treeImage.walnut
 image-$(CONFIG_ACADIA) += cuImage.acadia
 
diff --git a/arch/powerpc/boot/cuboot-hotfoot.c 
b/arch/powerpc/boot/cuboot-hotfoot.c
new file mode 100644
index 000..8f697b9
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hotfoot.c
@@ -0,0 +1,142 @@
+/*
+ * Old U-boot compatibility for Esteem 195E Hotfoot CPU Board
+ *
+ * Author: Solomon Peachy solo...@linux-wlan.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include reg.h
+#include dcr.h
+#include 4xx.h
+#include cuboot.h
+
+#define TARGET_4xx
+#define TARGET_HOTFOOT
+
+#include ppcboot-hotfoot.h
+
+static bd_t bd;
+
+#define NUM_REGS 3
+
+static void hotfoot_fixups(void)
+{
+   u32 uart = mfdcr(DCRN_CPC0_UCR)  0x7f;
+
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize); 
+
+   dt_fixup_cpu_clocks(bd.bi_procfreq, bd.bi_procfreq, 0);
+   dt_fixup_clock(/plb, bd.bi_plb_busfreq);
+   dt_fixup_clock(/plb/opb, bd.bi_opbfreq);
+   dt_fixup_clock(/plb/ebc, bd.bi_pci_busfreq);
+   dt_fixup_clock(/plb/opb/ser...@ef600300, bd.bi_procfreq / uart); 
+   dt_fixup_clock(/plb/opb/ser...@ef600400, bd.bi_procfreq / uart); 
+   
+   dt_fixup_mac_address_by_alias(ethernet0, bd.bi_enetaddr);
+   dt_fixup_mac_address_by_alias(ethernet1, bd.bi_enet1addr);
+
+   /* Is this a single eth/serial board? */
+   if ((bd.bi_enet1addr[0] == 0)  
+   (bd.bi_enet1addr[1] == 0) 
+   (bd.bi_enet1addr[2] == 0) 
+   (bd.bi_enet1addr[3] == 0) 
+   (bd.bi_enet1addr[4] == 0) 
+   (bd.bi_enet1addr[5] == 0)) {
+   void *devp;
+
+   printf(Trimming devtree for single serial/eth board\n);
+
+   devp = finddevice(/plb/opb/ser...@ef600300);
+   if (!devp)
+   fatal(Can't find node for /plb/opb/ser...@ef600300);
+   del_node(devp);
+
+   devp = finddevice(/plb/opb/ether...@ef600900);
+   if (!devp)
+   fatal(Can't find node for /plb/opb/ether...@ef600900);
+   del_node(devp);
+   }
+
+   ibm4xx_quiesce_eth((u32 *)0xef600800, (u32 *)0xef600900);
+
+   /* Fix up flash size in fdt for 4M boards. */
+   if (bd.bi_flashsize  0x80) {
+   u32 regs[NUM_REGS];
+   void *devp = finddevice(/plb/ebc/nor_fl...@0);
+   if (!devp)
+

[PATCH v2] Add support for the ESTeem 195E (PPC405EP) SBC

2009-08-20 Thread Solomon Peachy

This patch adds support for the ESTeem 195E Hotfoot SBC.
I've been maintaining this out-of-tree for some time now for
older kernels, but recently I ported it to the new unified powerpc
tree with the intent of pushing it upstream.

The 195E boards use ancient versions of u-boot and a slightly mangled
verison of the oft-abused ppcboot header.  (v2 of this patch moves the
modified ppcboot header into ppcboot-hotfoot.h)

There are several variants of the SBC deployed, single/dual
ethernet+serial, and also 4MB/8MB flash variations.  In the interest of
having a single kernel image boot on all boards, the cuboot shim detects
the differences and mangles the DTS tree appropriately.

With the exception of the CF interface that was never populated on
production boards, this code/DTS supports all boardpop options.

Signed-off-by:  Solomon Peachy solo...@linux-wlan.com
---
 arch/powerpc/boot/Makefile |4 +-
 arch/powerpc/boot/cuboot-hotfoot.c |  142 +
 arch/powerpc/boot/dts/hotfoot.dts  |  297 
 arch/powerpc/boot/ppcboot-hotfoot.h|  133 +
 arch/powerpc/platforms/40x/Kconfig |   10 +
 arch/powerpc/platforms/40x/ppc40x_simple.c |3 +-
 6 files changed, 587 insertions(+), 2 deletions(-)
 create mode 100644 arch/powerpc/boot/cuboot-hotfoot.c
 create mode 100644 arch/powerpc/boot/dts/hotfoot.dts
 create mode 100644 arch/powerpc/boot/ppcboot-hotfoot.h

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9ae7b7e..5a109a9 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -39,6 +39,7 @@ DTS_FLAGS ?= -p 1024
 
 $(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
 $(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-hotfoot.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
 $(obj)/cuboot-acadia.o: BOOTCFLAGS += -mcpu=405
@@ -67,7 +68,7 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
fsl-soc.c mpc8xx.c pq2.c
 src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c 
holly.c \
-   cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
+   cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
@@ -190,6 +191,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)  += uImage
 
 # Board ports in arch/powerpc/platform/40x/Kconfig
 image-$(CONFIG_EP405)  += dtbImage.ep405
+image-$(CONFIG_HOTFOOT)+= cuImage.hotfoot
 image-$(CONFIG_WALNUT) += treeImage.walnut
 image-$(CONFIG_ACADIA) += cuImage.acadia
 
diff --git a/arch/powerpc/boot/cuboot-hotfoot.c 
b/arch/powerpc/boot/cuboot-hotfoot.c
new file mode 100644
index 000..8f697b9
--- /dev/null
+++ b/arch/powerpc/boot/cuboot-hotfoot.c
@@ -0,0 +1,142 @@
+/*
+ * Old U-boot compatibility for Esteem 195E Hotfoot CPU Board
+ *
+ * Author: Solomon Peachy solo...@linux-wlan.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include ops.h
+#include stdio.h
+#include reg.h
+#include dcr.h
+#include 4xx.h
+#include cuboot.h
+
+#define TARGET_4xx
+#define TARGET_HOTFOOT
+
+#include ppcboot-hotfoot.h
+
+static bd_t bd;
+
+#define NUM_REGS 3
+
+static void hotfoot_fixups(void)
+{
+   u32 uart = mfdcr(DCRN_CPC0_UCR)  0x7f;
+
+   dt_fixup_memory(bd.bi_memstart, bd.bi_memsize); 
+
+   dt_fixup_cpu_clocks(bd.bi_procfreq, bd.bi_procfreq, 0);
+   dt_fixup_clock(/plb, bd.bi_plb_busfreq);
+   dt_fixup_clock(/plb/opb, bd.bi_opbfreq);
+   dt_fixup_clock(/plb/ebc, bd.bi_pci_busfreq);
+   dt_fixup_clock(/plb/opb/ser...@ef600300, bd.bi_procfreq / uart); 
+   dt_fixup_clock(/plb/opb/ser...@ef600400, bd.bi_procfreq / uart); 
+   
+   dt_fixup_mac_address_by_alias(ethernet0, bd.bi_enetaddr);
+   dt_fixup_mac_address_by_alias(ethernet1, bd.bi_enet1addr);
+
+   /* Is this a single eth/serial board? */
+   if ((bd.bi_enet1addr[0] == 0)  
+   (bd.bi_enet1addr[1] == 0) 
+   (bd.bi_enet1addr[2] == 0) 
+   (bd.bi_enet1addr[3] == 0) 
+   (bd.bi_enet1addr[4] == 0) 
+   (bd.bi_enet1addr[5] == 0)) {
+   void *devp;
+
+   printf(Trimming devtree for single serial/eth board\n);
+
+   devp = finddevice(/plb/opb/ser...@ef600300);
+   if (!devp)
+   fatal(Can't find node for /plb/opb/ser...@ef600300);
+   del_node(devp);
+
+   devp =

Re: [Bugme-new] [Bug 14021] New: hfsplus caused data loss

2009-08-20 Thread Andrew Morton


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 20 Aug 2009 02:17:21 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

 http://bugzilla.kernel.org/show_bug.cgi?id=14021
 
Summary: hfsplus caused data loss
Product: File System
Version: 2.5
 Kernel Version: 2.6.31-rc5
   Platform: All
 OS/Version: Linux
   Tree: Mainline
 Status: NEW
   Severity: normal
   Priority: P1
  Component: HFS/HFSPLUS
 AssignedTo: zip...@linux-m68k.org
 ReportedBy: rbr...@ime.usp.br
 Regression: Yes
 
 
 Hi.
 
 I am trying to package a new version of Apple's own fsck/mkfs for HFS+
 filesystems so that they can be used in Linux as a way to transfer data among
 computers, but I had quite a surprise when I was using the hfsplus module.
 
 I just created a 100MB file with nulls (dd if=/dev/null ...) and I created an
 HFS+ filesystem on it.
 
 Then, I loop mounted it and tried to use it a little bit (in particular,
 applying patches with quilt on a source tree). The commands spit some errors
 about not being able to create links (I never had that problem before) and the
 directory where I was became empty!
 
 Furthermore, here is a quite, quite strange directory listing:
 
 ,
 | rbr...@chagas:/media/usb7$ ls -lAF
 | ls: hfsprogs_332.14-7.diff.gz: No such file or directory
 | ls: hfsprogs_332.14-7.dsc: No such file or directory
 | ls: hfsprogs_332.14.orig.tar.gz: No such file or directory
 | ls: hfsprogs_332.18-1.diff.gz: No such file or directory
 | ls: hfsprogs_332.18-1.dsc: No such file or directory
 | ls: hfsprogs_332.18-1_amd64.changes: No such file or directory
 | ls: hfsprogs_332.18-1_amd64.deb: No such file or directory
 | ls: hfsprogs_332.18.orig.tar.gz: No such file or directory
 | total 1636
 | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
 | drwxr-xr-x 1 rbrito rbrito 39 Aug 17 08:13 hfsprogs-332.14/
 | drwxr-xr-x 1 rbrito rbrito 45 Aug 17 15:30 hfsprogs-332.18/
 | -rw-r--r-- 1 rbrito rbrito  35609 Aug 17 08:13 hfsprogs_332.14-7.diff.gz
 | -rw-r--r-- 1 rbrito rbrito   1193 Aug 17 08:13 hfsprogs_332.14-7.dsc
 | -rw-r--r-- 1 rbrito rbrito 714035 Aug 17 08:13 hfsprogs_332.14.orig.tar.gz
 | -rw-r--r-- 1 rbrito rbrito  35342 Aug 17 15:26 hfsprogs_332.18-1.diff.gz
 | -rw-r--r-- 1 rbrito rbrito954 Aug 17 15:26 hfsprogs_332.18-1.dsc
 | -rw-r--r-- 1 rbrito rbrito   2148 Aug 17 15:26
 hfsprogs_332.18-1_amd64.changes
 | -rw-r--r-- 1 rbrito rbrito 135398 Aug 17 15:26 hfsprogs_332.18-1_amd64.deb
 | -rw-r--r-- 1 rbrito rbrito 732449 Aug 17 08:35 hfsprogs_332.18.orig.tar.gz
 | rbr...@chagas:/media/usb7$
 `
 
 I am using kernel 2.6.31-rc5-1rb.pre6 (that is, rc5 with git updates up to one
 or two days before rc6).
 
 There are no messages in the dmesg, besides these:
 
 ,
 | [30991.501804] loop: module loaded
 | [30991.513337] hfs: create hidden dir...
 | [39897.867830] hfs: create hidden dir...
 | [39960.061622] hfs: splitting index node...
 `
 
 No stack traces, no nothing. Oh, I still have the disk image that I created, 
 if
 it is of any interest.
 
 Please let me know if I can provide any further information.
 

Gee.  Nobody really does much maintenance work on hfs/hfsplus any more.
I cc'ed the ppc guys as I expect that most HFS users are over there.

It seems like a pretty gross failure - others should be hitting it.

I wonder if it's a weird interaction with the loop driver.


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

JFFS2 overflow bug in read_dnone

2009-08-20 Thread Victor Gallardo

Hi,
 
I noticed if I compile with CONFIG_PPC_64K_PAGES, I run into the following 
issue.
 
 read_dnode: tn-csize == 0, csize == 65536
 check_node: tn-csize == 0  BUG_ON assert
 
Look like an OVERFLOW bug. Is this correct?
 
Here is the problem
 
fs/jffs2/nodelist.h
    struct jffs2_tmp_dnode_info
    {
    ...
    uint16_t csize;
    ...
    };
 
fs/jffs2/readinode.c
    static inline int read_dnode(...)
    {
    struct jffs2_tmp_dnode_info *tn;
    uint32_t csize;
    ...
    csize = je32_to_cpu(rd-csize);
    ...
    tn-csize = csize;
  #ifdef DBG_BUG_ON_ASSERT
    if ( tn-csize == 0  csize != 0) {
    printk(*** %s: tn-csize == 0, csize == 
%d\n,__func__,csize);
    }
  #endif
    
   }
Best Regards,
 
Victor Gallardo

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

[PATCH] char/hvc: adding __init macro to char/hvc_vio.c

2009-08-20 Thread Peter Hüwe

From: Peter Huewe peterhu...@gmx.de

Trivial patch which adds the __init/__exit macros to the module_init/
module_exit functions of char/hvc_vio.c

Please have a look at the small patch and either pull it through
your tree, or please ack' it so Jiri can pull it through the trivial tree.

linux version 2.6.31-rc6 - linus git tree, Do 20. Aug 22:26:06 CEST 2009

Signed-off-by: Peter Huewe peterhu...@gmx.de
---
diff --git a/drivers/char/hvc_vio.c b/drivers/char/hvc_vio.c
index c72b994..10be343 100644
--- a/drivers/char/hvc_vio.c
+++ b/drivers/char/hvc_vio.c
@@ -120,7 +120,7 @@ static struct vio_driver hvc_vio_driver = {
}
 };
 
-static int hvc_vio_init(void)
+static int __init hvc_vio_init(void)
 {
int rc;
 
@@ -134,7 +134,7 @@ static int hvc_vio_init(void)
 }
 module_init(hvc_vio_init); /* after drivers/char/hvc_console.c */
 
-static void hvc_vio_exit(void)
+static void __exit hvc_vio_exit(void)
 {
vio_unregister_driver(hvc_vio_driver);
 }
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread Victor Gallardo

Hi Sean,

The change is necessary in both Linux and u-boot. Without this change customer 
are seeing the problem.

Best Regards,

Victor Gallardo

 -Original Message-
 From: linuxppc-dev-bounces+vgallardo=amcc@lists.ozlabs.org 
 [mailto:linuxppc-dev-
 bounces+vgallardo=amcc@lists.ozlabs.org] On Behalf Of Sean MacLennan
 Sent: Thursday, August 20, 2009 12:37 PM
 To: Stefan Roese
 Cc: u-b...@lists.denx.de; Feng Kan; linux-...@lists.infradead.org; 
 linuxppc-...@ozlabs.org
 Subject: Re: [U-Boot] NAND ECC Error with wrong SMC ording bug
 
 On Thu, 20 Aug 2009 07:01:21 +0200
 Stefan Roese s...@denx.de wrote:
 
  On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
I see other boards using SMC as well, can someone comment on the
change I am proposing.
Should I change the correction algorithm or the calculate
function? If the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
  
   Odds are the calculate function is wrong. The correction algo is
   used by many nand drivers, I *assume* it is correct. The calculate
   function was set to agree with u-boot (1.3.0).
 
  Yes, it seems that you changed the order in the calculation function
  while reworking the NDFC driver for arch/powerpc. So we should
  probably change this order back to the original version. And change
  it in U-Boot as well.
 
  BTW: I didn't see any problems with ECC so far with the current code.
  Feng, how did you spot this problem?
 
 Ok, I think I have reproduced the problem programmatically. Basically,
 I force a one bit error with the following patch:
 
 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index 8c21b89..91dd5b4 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -1628,11 +1628,22 @@ static void nand_write_page_hwecc(struct mtd_info 
 *mtd, struct nand_chip
 *chip,
   uint8_t *ecc_calc = chip-buffers-ecccalc;
   const uint8_t *p = buf;
   uint32_t *eccpos = chip-ecc.layout-eccpos;
 + static int count;
 
   for (i = 0; eccsteps; eccsteps--, i += eccbytes, p += eccsize) {
   chip-ecc.hwctl(mtd, NAND_ECC_WRITE);
 - chip-write_buf(mtd, p, eccsize);
 - chip-ecc.calculate(mtd, p, ecc_calc[i]);
 + if (count == 0) {
 + count = 1;
 + printk(Corrupt one bit: %08x = %08x\n,
 +*p, *p ^ 8);
 + *(uint8_t *)p ^= 8;
 + chip-write_buf(mtd, p, eccsize);
 + *(uint8_t *)p ^= 8;
 + nand_calculate_ecc(mtd, p, ecc_calc[i]);
 + } else {
 + chip-write_buf(mtd, p, eccsize);
 + chip-ecc.calculate(mtd, p, ecc_calc[i]);
 + }
   }
 
   for (i = 0; i  chip-ecc.total; i++)
 
 Basically I write a one bit error to the NAND, but calculate with the
 correct bit. This assumes nand_calculate_ecc is correct.
 
 I then added debugs to the correction to make sure it corrected
 properly:
 
 diff --git a/drivers/mtd/nand/nand_ecc.c b/drivers/mtd/nand/nand_ecc.c
 index c0cb87d..57dcaa1 100644
 --- a/drivers/mtd/nand/nand_ecc.c
 +++ b/drivers/mtd/nand/nand_ecc.c
 @@ -483,14 +483,20 @@ int nand_correct_data(struct mtd_info *mtd, unsigned 
 char *buf,
   byte_addr = (addressbits[b2  0x3]  8) +
   (addressbits[b1]  4) + addressbits[b0];
   bit_addr = addressbits[b2  2];
 +
 + printk(Single bit error: correct %08x = %08x\n,
 +buf[byte_addr], buf[byte_addr] ^ (1  bit_addr));
 +
   /* flip the bit */
   buf[byte_addr] ^= (1  bit_addr);
   return 1;
 
   }
   /* count nr of bits; use table lookup, faster than calculating it */
 - if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1)
 + if ((bitsperbyte[b0] + bitsperbyte[b1] + bitsperbyte[b2]) == 1) {
 + printk(ECC DATA BAD\n); // SAM DBG
   return 1;   /* error in ecc data; no action needed */
 + }
 
   printk(KERN_ERR uncorrectable error : );
   return -1;
 
 With the current ndfc code, the error correction gets the bits wrong.
 Switching it back to the original way and the correction is correct.
 
 diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
 index 89bf85a..497e175 100644
 --- a/drivers/mtd/nand/ndfc.c
 +++ b/drivers/mtd/nand/ndfc.c
 @@ -101,9 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
 
   wmb();
   ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
 - /* The NDFC uses Smart Media (SMC) bytes order */
 - ecc_code[0] = p[2];
 - ecc_code[1] = p[1];
 + ecc_code[0] = p[1];
 + ecc_code[1] = p[2];
   ecc_code[2] = p[3];
 
   return 0;
 
 Does anybody see a problem with my method of reproducing the bug? This
 bug is deadly for our customers. I don't want to make

[PATCH] powerpc: Adjust base and index registers in Altivec macros

2009-08-20 Thread Mike Wolf

On POWER6 systems RA needs to be the base and RB the index.  
If they are reversed you take a misdirect hit.  

Signed-off-by: Mike Wolf mjw...@us.ibm.com


--- altivec.orig/arch/powerpc/include/asm/ppc_asm.h 2009-08-17 
15:39:52.0 -0500
+++ altivec/arch/powerpc/include/asm/ppc_asm.h  2009-08-20 18:08:30.0 
-0500
@@ -98,13 +98,13 @@
 #define REST_16FPRS(n, base)   REST_8FPRS(n, base); REST_8FPRS(n+8, base)
 #define REST_32FPRS(n, base)   REST_16FPRS(n, base); REST_16FPRS(n+16, base)
 
-#define SAVE_VR(n,b,base)  li b,THREAD_VR0+(16*(n));  stvx n,b,base
+#define SAVE_VR(n,b,base)  li b,THREAD_VR0+(16*(n));  stvx n,base,b
 #define SAVE_2VRS(n,b,base)SAVE_VR(n,b,base); SAVE_VR(n+1,b,base)
 #define SAVE_4VRS(n,b,base)SAVE_2VRS(n,b,base); SAVE_2VRS(n+2,b,base)
 #define SAVE_8VRS(n,b,base)SAVE_4VRS(n,b,base); SAVE_4VRS(n+4,b,base)
 #define SAVE_16VRS(n,b,base)   SAVE_8VRS(n,b,base); SAVE_8VRS(n+8,b,base)
 #define SAVE_32VRS(n,b,base)   SAVE_16VRS(n,b,base); SAVE_16VRS(n+16,b,base)
-#define REST_VR(n,b,base)  li b,THREAD_VR0+(16*(n)); lvx n,b,base
+#define REST_VR(n,b,base)  li b,THREAD_VR0+(16*(n)); lvx n,base,b
 #define REST_2VRS(n,b,base)REST_VR(n,b,base); REST_VR(n+1,b,base)
 #define REST_4VRS(n,b,base)REST_2VRS(n,b,base); REST_2VRS(n+2,b,base)
 #define REST_8VRS(n,b,base)REST_4VRS(n,b,base); REST_4VRS(n+4,b,base)
@@ -112,26 +112,26 @@
 #define REST_32VRS(n,b,base)   REST_16VRS(n,b,base); REST_16VRS(n+16,b,base)
 
 /* Save the lower 32 VSRs in the thread VSR region */
-#define SAVE_VSR(n,b,base) li b,THREAD_VSR0+(16*(n));  STXVD2X(n,b,base)
+#define SAVE_VSR(n,b,base) li b,THREAD_VSR0+(16*(n));  STXVD2X(n,base,b)
 #define SAVE_2VSRS(n,b,base)   SAVE_VSR(n,b,base); SAVE_VSR(n+1,b,base)
 #define SAVE_4VSRS(n,b,base)   SAVE_2VSRS(n,b,base); SAVE_2VSRS(n+2,b,base)
 #define SAVE_8VSRS(n,b,base)   SAVE_4VSRS(n,b,base); SAVE_4VSRS(n+4,b,base)
 #define SAVE_16VSRS(n,b,base)  SAVE_8VSRS(n,b,base); SAVE_8VSRS(n+8,b,base)
 #define SAVE_32VSRS(n,b,base)  SAVE_16VSRS(n,b,base); SAVE_16VSRS(n+16,b,base)
-#define REST_VSR(n,b,base) li b,THREAD_VSR0+(16*(n)); LXVD2X(n,b,base)
+#define REST_VSR(n,b,base) li b,THREAD_VSR0+(16*(n)); LXVD2X(n,base,b)
 #define REST_2VSRS(n,b,base)   REST_VSR(n,b,base); REST_VSR(n+1,b,base)
 #define REST_4VSRS(n,b,base)   REST_2VSRS(n,b,base); REST_2VSRS(n+2,b,base)
 #define REST_8VSRS(n,b,base)   REST_4VSRS(n,b,base); REST_4VSRS(n+4,b,base)
 #define REST_16VSRS(n,b,base)  REST_8VSRS(n,b,base); REST_8VSRS(n+8,b,base)
 #define REST_32VSRS(n,b,base)  REST_16VSRS(n,b,base); REST_16VSRS(n+16,b,base)
 /* Save the upper 32 VSRs (32-63) in the thread VSX region (0-31) */
-#define SAVE_VSRU(n,b,base)li b,THREAD_VR0+(16*(n));  STXVD2X(n+32,b,base)
+#define SAVE_VSRU(n,b,base)li b,THREAD_VR0+(16*(n));  STXVD2X(n+32,base,b)
 #define SAVE_2VSRSU(n,b,base)  SAVE_VSRU(n,b,base); SAVE_VSRU(n+1,b,base)
 #define SAVE_4VSRSU(n,b,base)  SAVE_2VSRSU(n,b,base); SAVE_2VSRSU(n+2,b,base)
 #define SAVE_8VSRSU(n,b,base)  SAVE_4VSRSU(n,b,base); SAVE_4VSRSU(n+4,b,base)
 #define SAVE_16VSRSU(n,b,base) SAVE_8VSRSU(n,b,base); SAVE_8VSRSU(n+8,b,base)
 #define SAVE_32VSRSU(n,b,base) SAVE_16VSRSU(n,b,base); 
SAVE_16VSRSU(n+16,b,base)
-#define REST_VSRU(n,b,base)li b,THREAD_VR0+(16*(n)); LXVD2X(n+32,b,base)
+#define REST_VSRU(n,b,base)li b,THREAD_VR0+(16*(n)); LXVD2X(n+32,base,b)
 #define REST_2VSRSU(n,b,base)  REST_VSRU(n,b,base); REST_VSRU(n+1,b,base)
 #define REST_4VSRSU(n,b,base)  REST_2VSRSU(n,b,base); REST_2VSRSU(n+2,b,base)
 #define REST_8VSRSU(n,b,base)  REST_4VSRSU(n,b,base); REST_4VSRSU(n+4,b,base)


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

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread Feng Kan


Hi Stefan:

We had a board with high number of correctable ECC errors. Which crashed 
the jffs when it

was miss correcting the wrong byte location.

Do you want me to submit a patch for this, or do you prefer to do it. I 
am submitting a patch

for linux right now.

Feng Kan
AMCC Software

On 08/19/2009 10:01 PM, Stefan Roese wrote:

On Thursday 20 August 2009 06:38:51 Sean MacLennan wrote:
   

I see other boards using SMC as well, can someone comment on the
change I am proposing.
Should I change the correction algorithm or the calculate function?
If the later is preferred
it would mean the change must be pushed in both U-Boot and Linux.
   

Odds are the calculate function is wrong. The correction algo is used
by many nand drivers, I *assume* it is correct. The calculate function
was set to agree with u-boot (1.3.0).
 

Yes, it seems that you changed the order in the calculation function while
reworking the NDFC driver for arch/powerpc. So we should probably change this
order back to the original version. And change it in U-Boot as well.

BTW: I didn't see any problems with ECC so far with the current code. Feng,
how did you spot this problem?

Cheers,
Stefan

--
DENX Software Engineering GmbH,  MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
   


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

[PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.

2009-08-20 Thread Feng Kan

Fix ECC Correction bug where the byte offset location were double
fliped causing correction routine to toggle the wrong byte location
in the ECC segment. The ndfc_calculate_ecc routine change the order
of getting the ECC code.
/* The NDFC uses Smart Media (SMC) bytes order */
ecc_code[0] = p[2];
ecc_code[1] = p[1];
ecc_code[2] = p[3];
But in the Correction algorithm when calculating the byte offset
location, the b1 is used as the upper part of the address. Which
again reverse the order making the final byte offset address 
location incorrect.
byte_addr = (addressbits[b1]  4) + addressbits[b0];
The order is change to read it in straight and let the correction
function to revert it to SMC order.

Signed-off-by: Feng Kan f...@amcc.com
Acked-by: Victor Gallardo vgalla...@amcc.com
Acked-by: Prodyut Hazarika phazar...@amcc.com
---
 drivers/mtd/nand/ndfc.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 5906c40..d9d3e6e 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -101,8 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
wmb();
ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
/* The NDFC uses Smart Media (SMC) bytes order */
-   ecc_code[0] = p[2];
-   ecc_code[1] = p[1];
+   ecc_code[0] = p[1];
+   ecc_code[1] = p[2];
ecc_code[2] = p[3];
 
return 0;
-- 
1.5.5

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

Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.

2009-08-20 Thread Sean MacLennan

On Thu, 20 Aug 2009 17:19:17 -0700
Feng Kan f...@amcc.com wrote:

 Fix ECC Correction bug where the byte offset location were double
 fliped causing correction routine to toggle the wrong byte location
 in the ECC segment. The ndfc_calculate_ecc routine change the order
 of getting the ECC code.
 /* The NDFC uses Smart Media (SMC) bytes order */
 ecc_code[0] = p[2];
 ecc_code[1] = p[1];
 ecc_code[2] = p[3];
 But in the Correction algorithm when calculating the byte offset
 location, the b1 is used as the upper part of the address. Which
 again reverse the order making the final byte offset address 
 location incorrect.
   byte_addr = (addressbits[b1]  4) + addressbits[b0];
 The order is change to read it in straight and let the correction
 function to revert it to SMC order.
 
 Signed-off-by: Feng Kan f...@amcc.com
 Acked-by: Victor Gallardo vgalla...@amcc.com
 Acked-by: Prodyut Hazarika phazar...@amcc.com
 ---
  drivers/mtd/nand/ndfc.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
 index 5906c40..d9d3e6e 100644
 --- a/drivers/mtd/nand/ndfc.c
 +++ b/drivers/mtd/nand/ndfc.c
 @@ -101,8 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info
 *mtd, wmb();
   ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
   /* The NDFC uses Smart Media (SMC) bytes order */
 - ecc_code[0] = p[2];
 - ecc_code[1] = p[1];
 + ecc_code[0] = p[1];
 + ecc_code[1] = p[2];
   ecc_code[2] = p[3];
  
   return 0;

Acked-by: Sean MacLennan smaclen...@pikatech.com

Cheers,
   Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: manual merge of the agp tree with the powerpc tree

2009-08-20 Thread Stephen Rothwell

Hi Dave,

Today's linux-next merge of the agp tree got a conflict in
drivers/char/agp/uninorth-agp.c between commit uninorth_create_gatt_table
(agp/uninorth: Simplify cache flushing) from the powerpc tree and
commit 6a12235c7d2d75c7d94b9afcaaecd422ff845ce0 (agp: kill phys_to_gart
() and gart_to_phys()) from the agp tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/char/agp/uninorth-agp.c
index bba29ab,4317a55..000
--- a/drivers/char/agp/uninorth-agp.c
+++ b/drivers/char/agp/uninorth-agp.c
@@@ -424,28 -424,14 +424,28 @@@ static int uninorth_create_gatt_table(s
if (table == NULL)
return -ENOMEM;
  
 +  pages = kmalloc((1  page_order) * sizeof(struct page*), GFP_KERNEL);
 +  if (pages == NULL)
 +  goto enomem;
 +
table_end = table + ((PAGE_SIZE * (1  page_order)) - 1);
  
 -  for (page = virt_to_page(table); page = virt_to_page(table_end); 
page++)
 +  for (page = virt_to_page(table), i = 0; page = virt_to_page(table_end);
 +   page++, i++) {
SetPageReserved(page);
 +  pages[i] = page;
 +  }
  
bridge-gatt_table_real = (u32 *) table;
 -  bridge-gatt_table = (u32 *)table;
 +  /* Need to clear out any dirty data still sitting in caches */
 +  flush_dcache_range((unsigned long)table,
 + (unsigned long)(table_end + PAGE_SIZE));
 +  bridge-gatt_table = vmap(pages, (1  page_order), 0, PAGE_KERNEL_NCG);
 +
 +  if (bridge-gatt_table == NULL)
 +  goto enomem;
 +
-   bridge-gatt_bus_addr = virt_to_gart(table);
+   bridge-gatt_bus_addr = virt_to_phys(table);
  
for (i = 0; i  num_entries; i++)
bridge-gatt_table[i] = 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

2009-08-20 Thread vimal singh

snip

 With the current ndfc code, the error correction gets the bits wrong.
 Switching it back to the original way and the correction is correct.

 diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
 index 89bf85a..497e175 100644
 --- a/drivers/mtd/nand/ndfc.c
 +++ b/drivers/mtd/nand/ndfc.c
 @@ -101,9 +101,8 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,

        wmb();
        ecc = in_be32(ndfc-ndfcbase + NDFC_ECC);
 -       /* The NDFC uses Smart Media (SMC) bytes order */
 -       ecc_code[0] = p[2];
 -       ecc_code[1] = p[1];
 +       ecc_code[0] = p[1];
 +       ecc_code[1] = p[2];
        ecc_code[2] = p[3];

        return 0;

 Does anybody see a problem with my method of reproducing the bug? This
 bug is deadly for our customers. I don't want to make the change unless
 it is absolutely necessary..

Just one question: did you enabled MTD_NAND_ECC_SMC in configs?

-vimal


 Cheers,
   Sean

 __
 Linux MTD discussion mailing list
 http://lists.infradead.org/mailman/listinfo/linux-mtd/

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

[RFC PATCH 0/3] Make 64-bit PCI device tree scanning code common

2009-08-20 Thread Grant Likely

Ben and Kumar,

Compile tested only.  I haven't even tried to boot this on real
hardware, but I'm posting so that you guys can see what I'm up to.
Basically, I want access to the device tree scanning in ppc32 land,
and these patches start to get me there.  Please take a look and
comment.  Tomorrow I'll actually try running this stuff and debugging
the details.

Thanks,
g.

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

[PATCH 1/3] powerpc/pci: Remove dead checks for CONFIG_PPC_OF

2009-08-20 Thread Grant Likely

From: Grant Likely grant.lik...@secretlab.ca

PPC_OF is always selected for arch/powerpc.  This patch removes the stale
#defines

Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---

 arch/powerpc/kernel/pci-common.c |8 
 arch/powerpc/kernel/pci_32.c |9 -
 2 files changed, 0 insertions(+), 17 deletions(-)


diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 5a56e97..23eeb3e 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -176,8 +176,6 @@ int pci_domain_nr(struct pci_bus *bus)
 }
 EXPORT_SYMBOL(pci_domain_nr);
 
-#ifdef CONFIG_PPC_OF
-
 /* This routine is meant to be used early during boot, when the
  * PCI bus numbers have not yet been assigned, and you need to
  * issue PCI config cycles to an OF device.
@@ -210,17 +208,11 @@ static ssize_t pci_show_devspec(struct device *dev,
return sprintf(buf, %s, np-full_name);
 }
 static DEVICE_ATTR(devspec, S_IRUGO, pci_show_devspec, NULL);
-#endif /* CONFIG_PPC_OF */
 
 /* Add sysfs properties */
 int pcibios_add_platform_entries(struct pci_dev *pdev)
 {
-#ifdef CONFIG_PPC_OF
return device_create_file(pdev-dev, dev_attr_devspec);
-#else
-   return 0;
-#endif /* CONFIG_PPC_OF */
-
 }
 
 char __devinit *pcibios_setup(char *str)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 3ae1c66..1e807fe 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -34,9 +34,7 @@ int pcibios_assign_bus_offset = 1;
 void pcibios_make_OF_bus_map(void);
 
 static void fixup_cpc710_pci64(struct pci_dev* dev);
-#ifdef CONFIG_PPC_OF
 static u8* pci_to_OF_bus_map;
-#endif
 
 /* By default, we don't re-assign bus numbers. We do this only on
  * some pmacs
@@ -83,7 +81,6 @@ fixup_cpc710_pci64(struct pci_dev* dev)
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_IBM,PCI_DEVICE_ID_IBM_CPC710_PCI64, 
fixup_cpc710_pci64);
 
-#ifdef CONFIG_PPC_OF
 /*
  * Functions below are used on OpenFirmware machines.
  */
@@ -357,12 +354,6 @@ pci_create_OF_bus_map(void)
}
 }
 
-#else /* CONFIG_PPC_OF */
-void pcibios_make_OF_bus_map(void)
-{
-}
-#endif /* CONFIG_PPC_OF */
-
 static void __devinit pcibios_scan_phb(struct pci_controller *hose)
 {
struct pci_bus *bus;

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

[PATCH 3/3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()

2009-08-20 Thread Grant Likely

From: Grant Likely grant.lik...@secretlab.ca

The two versions are doing almost exactly the same thing.  No need to
maintain them as separate files.  This patch also has the side effect
of making the PCI device tree scanning code available to 32 bit powerpc
machines, but no board ports actually make use of this feature at this
point.

Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---

 arch/powerpc/include/asm/pci.h   |2 ++
 arch/powerpc/kernel/pci-common.c |   48 ++
 arch/powerpc/kernel/pci_32.c |   25 ++--
 arch/powerpc/kernel/pci_64.c |   46 +---
 4 files changed, 58 insertions(+), 63 deletions(-)


diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 9ae2e3e..feebfed 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -233,6 +233,8 @@ extern void pci_resource_to_user(const struct pci_dev *dev, 
int bar,
 
 extern void pcibios_setup_bus_devices(struct pci_bus *bus);
 extern void pcibios_setup_bus_self(struct pci_bus *bus);
+extern void pcibios_setup_phb_io_space(struct pci_controller *hose);
+extern void pcibios_scan_phb(struct pci_controller *hose, void *data);
 
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_PCI_H */
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 3762525..7d5bf1b 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1956,3 +1956,51 @@ void __devinit of_rescan_bus(struct device_node *node,
 }
 EXPORT_SYMBOL_GPL(of_rescan_bus);
 
+/**
+ * pci_scan_phb - Given a pci_controller, setup and scan the PCI bus
+ * @hose: Pointer to the PCI host controller instance structure
+ * @data: value to use for sysdata pointer.  ppc32 and ppc64 differ here
+ *
+ * Note: the 'data' pointer is a temporary measure.  As 32 and 64 bit
+ * pci code gets merged, this parameter should become unnecessary because
+ * both will use the same value.
+ */
+void __devinit pcibios_scan_phb(struct pci_controller *hose, void *data)
+{
+   struct pci_bus *bus;
+   struct device_node *node = hose-dn;
+   int mode;
+
+   pr_debug(PCI: Scanning PHB %s\n,
+node ? node-full_name : NO NAME);
+
+   /* Create an empty bus for the toplevel */
+   bus = pci_create_bus(hose-parent, hose-first_busno, hose-ops, data);
+   if (bus == NULL) {
+   pr_err(Failed to create bus for PCI domain %04x\n,
+   hose-global_number);
+   return;
+   }
+   bus-secondary = hose-first_busno;
+   hose-bus = bus;
+
+   /* Get some IO space for the new PHB */
+   pcibios_setup_phb_io_space(hose);
+
+   /* Wire up PHB bus resources */
+   pcibios_setup_phb_resources(hose);
+
+   /* Get probe mode and perform scan */
+   mode = PCI_PROBE_NORMAL;
+   if (node  ppc_md.pci_probe_mode)
+   mode = ppc_md.pci_probe_mode(bus);
+   pr_debug(probe mode: %d\n, mode);
+   if (mode == PCI_PROBE_DEVTREE) {
+   bus-subordinate = hose-last_busno;
+   of_scan_bus(node, bus);
+   }
+
+   if (mode == PCI_PROBE_NORMAL)
+   hose-last_busno = bus-subordinate = pci_scan_child_bus(bus);
+}
+
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 1e807fe..4e415e1 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -354,36 +354,15 @@ pci_create_OF_bus_map(void)
}
 }
 
-static void __devinit pcibios_scan_phb(struct pci_controller *hose)
+void __devinit pcibios_setup_phb_io_space(struct pci_controller *hose)
 {
-   struct pci_bus *bus;
-   struct device_node *node = hose-dn;
unsigned long io_offset;
struct resource *res = hose-io_resource;
 
-   pr_debug(PCI: Scanning PHB %s\n,
-node ? node-full_name : NO NAME);
-
-   /* Create an empty bus for the toplevel */
-   bus = pci_create_bus(hose-parent, hose-first_busno, hose-ops, hose);
-   if (bus == NULL) {
-   printk(KERN_ERR Failed to create bus for PCI domain %04x\n,
-  hose-global_number);
-   return;
-   }
-   bus-secondary = hose-first_busno;
-   hose-bus = bus;
-
/* Fixup IO space offset */
io_offset = (unsigned long)hose-io_base_virt - isa_io_base;
res-start = (res-start + io_offset)  0xu;
res-end = (res-end + io_offset)  0xu;
-
-   /* Wire up PHB bus resources */
-   pcibios_setup_phb_resources(hose);
-
-   /* Scan children */
-   hose-last_busno = bus-subordinate = pci_scan_child_bus(bus);
 }
 
 static int __init pcibios_init(void)
@@ -401,7 +380,7 @@ static int __init pcibios_init(void)
if (pci_assign_all_buses)
hose-first_busno = next_busno;
hose-last_busno = 0xff;
-   pcibios_scan_phb(hose);
+

[PATCH 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c

2009-08-20 Thread Grant Likely

From: Grant Likely grant.lik...@secretlab.ca

The PCI device tree scanning code in pci_64.c is some useful functionality.
It allows PCI devices to be described in the device tree instead of being
probed for, which in turn allows pci devices to use all of the device tree
facilities to describe complex PCI bus architectures like GPIO and IRQ
routing (perhaps not a common situation for desktop or server systems,
but useful for embedded systems with on-board PCI devices).

This patch moves the device tree scanning into pci-common.c so it is
available for 32-bit powerpc machines too.

Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---

 arch/powerpc/include/asm/pci-bridge.h |5 
 arch/powerpc/include/asm/pci.h|5 
 arch/powerpc/kernel/pci-common.c  |  338 +
 arch/powerpc/kernel/pci_64.c  |  289 
 4 files changed, 343 insertions(+), 294 deletions(-)


diff --git a/arch/powerpc/include/asm/pci-bridge.h 
b/arch/powerpc/include/asm/pci-bridge.h
index 4c61fa0..3faf575 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -284,11 +284,6 @@ static inline int isa_vaddr_is_ioport(void __iomem 
*address)
 extern int pcibios_unmap_io_space(struct pci_bus *bus);
 extern int pcibios_map_io_space(struct pci_bus *bus);
 
-/* Return values for ppc_md.pci_probe_mode function */
-#define PCI_PROBE_NONE -1  /* Don't look at this bus at all */
-#define PCI_PROBE_NORMAL   0   /* Do normal PCI probing */
-#define PCI_PROBE_DEVTREE  1   /* Instantiate from device tree */
-
 #ifdef CONFIG_NUMA
 #define PHB_SET_NODE(PHB, NODE)((PHB)-node = (NODE))
 #else
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index d9483c5..9ae2e3e 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -22,6 +22,11 @@
 
 #include asm-generic/pci-dma-compat.h
 
+/* Return values for ppc_md.pci_probe_mode function */
+#define PCI_PROBE_NONE -1  /* Don't look at this bus at all */
+#define PCI_PROBE_NORMAL   0   /* Do normal PCI probing */
+#define PCI_PROBE_DEVTREE  1   /* Instantiate from device tree */
+
 #define PCIBIOS_MIN_IO 0x1000
 #define PCIBIOS_MIN_MEM0x1000
 
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 23eeb3e..3762525 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1618,3 +1618,341 @@ void __devinit pcibios_setup_phb_resources(struct 
pci_controller *hose)
 
 }
 
+/**
+ * get_int_prop - Decode a u32 from a device tree property
+ */
+static u32 get_int_prop(struct device_node *np, const char *name, u32 def)
+{
+   const u32 *prop;
+   int len;
+
+   prop = of_get_property(np, name, len);
+   if (prop  len = 4)
+   return *prop;
+   return def;
+}
+
+/**
+ * pci_parse_of_flags - Parse the flags cell of a device tree PCI address
+ * @addr0: value of 1st cell of a device tree PCI address.
+ * @bridge: Set this flag if the address is from a bridge 'ranges' property
+ */
+unsigned int pci_parse_of_flags(u32 addr0, int bridge)
+{
+   unsigned int flags = 0;
+
+   if (addr0  0x0200) {
+   flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
+   flags |= (addr0  22)  PCI_BASE_ADDRESS_MEM_TYPE_64;
+   flags |= (addr0  28)  PCI_BASE_ADDRESS_MEM_TYPE_1M;
+   if (addr0  0x4000)
+   flags |= IORESOURCE_PREFETCH
+| PCI_BASE_ADDRESS_MEM_PREFETCH;
+   /* Note: We don't know whether the ROM has been left enabled
+* by the firmware or not. We mark it as disabled (ie, we do
+* not set the IORESOURCE_ROM_ENABLE flag) for now rather than
+* do a config space read, it will be force-enabled if needed
+*/
+   if (!bridge  (addr0  0xff) == 0x30)
+   flags |= IORESOURCE_READONLY;
+   } else if (addr0  0x0100)
+   flags = IORESOURCE_IO | PCI_BASE_ADDRESS_SPACE_IO;
+   if (flags)
+   flags |= IORESOURCE_SIZEALIGN;
+   return flags;
+}
+
+/**
+ * of_pci_parse_addrs - Parse PCI addresses assigned in the device tree node
+ * @node: device tree node for the PCI device
+ * @dev: pci_dev structure for the device
+ *
+ * This function parses the 'assigned-addresses' property of a PCI devices'
+ * device tree node and writes them into the associated pci_dev structure.
+ */
+static void of_pci_parse_addrs(struct device_node *node, struct pci_dev *dev)
+{
+   u64 base, size;
+   unsigned int flags;
+   struct resource *res;
+   const u32 *addrs;
+   u32 i;
+   int proplen;
+
+   addrs = of_get_property(node, assigned-addresses, proplen);
+   if (!addrs)
+   return;
+

Re: [PATCH 2/2] powerpc/405ex: support cuImage via included dtb

2009-08-20 Thread tiejun.chen

Josh Boyer wrote:
 On Tue, Aug 18, 2009 at 10:28:04AM +0800, Tiejun Chen wrote:
 To support cuImage, we need to initialize the required sections and 
 ensure that it is built.

 -cuboot-acadia.c cuboot-amigaone.c
 +cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c
 src-boot := $(src-wlib) $(src-plat) empty.c

 src-boot := $(addprefix $(obj)/, $(src-boot))
 @@ -192,6 +192,7 @@ image-$(CONFIG_DEFAULT_UIMAGE)   += uImage
 image-$(CONFIG_EP405)+= dtbImage.ep405
 image-$(CONFIG_WALNUT)   += treeImage.walnut
 image-$(CONFIG_ACADIA)   += cuImage.acadia
 +image-$(CONFIG_KILAUEA) += cuImage.kilauea
 
 I'm not thrilled with this part as cuImage is really the secondary
 solution if the U-Boot that comes with a board if FDT aware.  If you
 have a different board that needs this, perhaps you could add the
 target when that board support gets upstream?
 

Agreed and I will remove this line as you expect. Right?

 +static void kilauea_fixups(void)
 +{
 +/*TODO: Please change this as the real. Note that should be 
 33MHZ~100MHZ.*/
 
 What does that mean?
 

It's difficult to check the sysclk value on all revision Kilauea board for me,
and we have to check this value only by the real target, not by reading one
register. So I hope it's safe to remind other guys here.

But I am sure that should be 33MHZ ~ 100MHZ as PPC405EX manual.

Best Regards
Tiejun

 josh
 

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

Re: [PATCH 1/3] powerpc/pci: Remove dead checks for CONFIG_PPC_OF

2009-08-20 Thread Stephen Rothwell

Hi Grant,

On Thu, 20 Aug 2009 23:30:09 -0600 Grant Likely grant.lik...@secretlab.ca 
wrote:

 From: Grant Likely grant.lik...@secretlab.ca
 
 PPC_OF is always selected for arch/powerpc.  This patch removes the stale
 #defines
 
 Signed-off-by: Grant Likely grant.lik...@secretlab.ca

Good work.

Acked-by: Stephen Rothwell s...@canb.auug.org.au

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpGFSlqTgnzA.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] powerpc/405ex: provide necessary fixup function to support cuImage

2009-08-20 Thread tiejun.chen

Josh Boyer wrote:
 On Tue, Aug 18, 2009 at 10:28:03AM +0800, Tiejun Chen wrote:
 For cuImage format it's necessary to provide clock fixups since u-boot will
 not pass necessary clock frequency into the dtb included into cuImage so we 
 implement the clock fixups as defined in the technical documentation for the 
 board and update header file with the basic register definitions. 

 Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
 ---
 arch/powerpc/boot/4xx.c |  142 
 +++
 arch/powerpc/boot/4xx.h |1 +
 arch/powerpc/boot/dcr.h |   12 
 3 files changed, 155 insertions(+), 0 deletions(-)

 diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
 index 325b310..b5561b3 100644
 --- a/arch/powerpc/boot/4xx.c
 +++ b/arch/powerpc/boot/4xx.c
 @@ -8,6 +8,10 @@
  *   Eugene Surovegin eugene.surove...@zultys.com or e...@ebshome.net
  *   Copyright (c) 2003, 2004 Zultys Technologies
  *
 + * Copyright (C) 2009 Wind River Systems, Inc.
 + *   Updated for supporting PPC405EX on Kilauea.
 + *   Tiejun Chen tiejun.c...@windriver.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
 @@ -659,3 +663,141 @@ void ibm405ep_fixup_clocks(unsigned int sys_clk)
  dt_fixup_clock(/plb/opb/ser...@ef600300, uart0);
  dt_fixup_clock(/plb/opb/ser...@ef600400, uart1);
 }
 +
 +static u8 fwdv_multi_bits[] = {
 +/* values for:  1 - 16 */
 +0x01, 0x02, 0x0e, 0x09, 0x04, 0x0b, 0x10, 0x0d, 0x0c, 0x05,
 +0x06, 0x0f, 0x0a, 0x07, 0x08, 0x03
 +};
 +
 +u32 get_fwdva(unsigned long cpr_fwdv)
 +{
 +u32 index;
 +
 +for (index = 0; index  ARRAY_SIZE(fwdv_multi_bits); index++)
 +if (cpr_fwdv == (u32)fwdv_multi_bits[index])
 +return index + 1;
 +
 +return 0;
 +}
 +
 +static u8 fbdv_multi_bits[] = {
 +/* values for:  1 - 100 */
 +0x00, 0xff, 0x7e, 0xfd, 0x7a, 0xf5, 0x6a, 0xd5, 0x2a, 0xd4,
 +0x29, 0xd3, 0x26, 0xcc, 0x19, 0xb3, 0x67, 0xce, 0x1d, 0xbb,
 +0x77, 0xee, 0x5d, 0xba, 0x74, 0xe9, 0x52, 0xa5, 0x4b, 0x96,
 +0x2c, 0xd8, 0x31, 0xe3, 0x46, 0x8d, 0x1b, 0xb7, 0x6f, 0xde,
 +0x3d, 0xfb, 0x76, 0xed, 0x5a, 0xb5, 0x6b, 0xd6, 0x2d, 0xdb,
 +0x36, 0xec, 0x59, 0xb2, 0x64, 0xc9, 0x12, 0xa4, 0x48, 0x91,
 +0x23, 0xc7, 0x0e, 0x9c, 0x38, 0xf0, 0x61, 0xc2, 0x05, 0x8b,
 +0x17, 0xaf, 0x5f, 0xbe, 0x7c, 0xf9, 0x72, 0xe5, 0x4a, 0x95,
 +0x2b, 0xd7, 0x2e, 0xdc, 0x39, 0xf3, 0x66, 0xcd, 0x1a, 0xb4,
 +0x68, 0xd1, 0x22, 0xc4, 0x09, 0x93, 0x27, 0xcf, 0x1e, 0xbc,
 +/* values for:  101 - 200 */
 +0x78, 0xf1, 0x62, 0xc5, 0x0a, 0x94, 0x28, 0xd0, 0x21, 0xc3,
 +0x06, 0x8c, 0x18, 0xb0, 0x60, 0xc1, 0x02, 0x84, 0x08, 0x90,
 +0x20, 0xc0, 0x01, 0x83, 0x07, 0x8f, 0x1f, 0xbf, 0x7f, 0xfe,
 +0x7d, 0xfa, 0x75, 0xea, 0x55, 0xaa, 0x54, 0xa9, 0x53, 0xa6,
 +0x4c, 0x99, 0x33, 0xe7, 0x4e, 0x9d, 0x3b, 0xf7, 0x6e, 0xdd,
 +0x3a, 0xf4, 0x69, 0xd2, 0x25, 0xcb, 0x16, 0xac, 0x58, 0xb1,
 +0x63, 0xc6, 0x0d, 0x9b, 0x37, 0xef, 0x5e, 0xbd, 0x7b, 0xf6,
 +0x6d, 0xda, 0x35, 0xeb, 0x56, 0xad, 0x5b, 0xb6, 0x6c, 0xd9,
 +0x32, 0xe4, 0x49, 0x92, 0x24, 0xc8, 0x11, 0xa3, 0x47, 0x8e,
 +0x1c, 0xb8, 0x70, 0xe1, 0x42, 0x85, 0x0b, 0x97, 0x2f, 0xdf,
 +/* values for:  201 - 255 */
 +0x3e, 0xfc, 0x79, 0xf2, 0x65, 0xca, 0x15, 0xab, 0x57, 0xae,
 +0x5c, 0xb9, 0x73, 0xe6, 0x4d, 0x9a, 0x34, 0xe8, 0x51, 0xa2,
 +0x44, 0x89, 0x13, 0xa7, 0x4f, 0x9e, 0x3c, 0xf8, 0x71, 0xe2,
 +0x45, 0x8a, 0x14, 0xa8, 0x50, 0xa1, 0x43, 0x86, 0x0c, 0x98,
 +0x30, 0xe0, 0x41, 0x82, 0x04, 0x88, 0x10, 0xa0, 0x40, 0x81,
 +0x03, 0x87, 0x0f, 0x9f, 0x3f  /* END */
 +};
 +
 +u32 get_fbdv(unsigned long cpr_fbdv)
 +{
 +u32 index;
 +
 +for (index = 0; index  ARRAY_SIZE(fbdv_multi_bits); index++)
 +if (cpr_fbdv == (u32)fbdv_multi_bits[index])
 +return index + 1;
 +
 +return 0;
 +}
 
 Is this generic?  Can we the function and value arrays to get the fbdv for
 all 4xx boards and have the right values pop out?  If not, then all of these
 need to be prefixed with ibm405ex_.
 

Other 4xx boards have different fwdv_multi_bits[]/fbdv_multi_bits[] array as far
as I know. So I prefer to prefix with ibm405ex as you suggestion.

 diff --git a/arch/powerpc/boot/dcr.h b/arch/powerpc/boot/dcr.h
 index 95b9f53..ba41624 100644
 --- a/arch/powerpc/boot/dcr.h
 +++ b/arch/powerpc/boot/dcr.h
 @@ -153,6 +153,18 @@ static const unsigned long sdram_bxcr[] = { 
 SDRAM0_B0CR, SDRAM0_B1CR,
 #define DCRN_CPC0_PLLMR1  0xf4
 #define DCRN_CPC0_UCR 0xf5

 +/* 405EX Clocking Control regs */
 +#define CPR0_CLKUPD 0x0020
 +#define CPR0_PLLC   0x0040
 +#define CPR0_PLLD   0x0060
 +#define CPR0_CPUD   0x0080
 +#define CPR0_PLBD   0x00a0
 +#define CPR0_OPBD   0x00c0
 +#define CPR0_PERD   0x00e0
 +#define CPR0_AHBD   0x0100
 +#define CPR0_ICFG

Re: [PATCH] Add kmemleak annotations to lmb.c

2009-08-20 Thread Michael Ellerman

On Fri, 2009-08-14 at 22:57 +0100, Catalin Marinas wrote:
 On Fri, 2009-08-14 at 12:49 -0700, David Miller wrote:
  From: Benjamin Herrenschmidt b...@kernel.crashing.org
  Date: Fri, 14 Aug 2009 17:56:40 +1000

   On Thu, 2009-08-13 at 16:40 +0100, Catalin Marinas wrote:
   On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
We don't actually want kmemleak to track the lmb allocations, so we
pass min_count as 0. However telling kmemleak about lmb allocations
allows it to scan that memory for pointers to other memory that is
tracked by kmemleak, ie. slab allocations etc.

   Looks alright to me (though I haven't tested it). You can add a
   Reviewed-by: Catalin Marinas catalin.mari...@arm.com

   Actually, Milton pointed to me that we may not want to allow all
   LMB chunks to be scanned by kmemleaks, things like the DART hole
   that's taken out of the linear mapping for example may need to
   be avoided, though I'm not sure what would be the right way to
   do it.

  I think that annotating LMB for kmemleak may be more problems
  that it's worth.

 BTW, are there many LMB allocations used for storing pointers to other
 objects? If not, it may be worth just annotating those with
 kmemleak_alloc() if you get false positives.

Yeah I think that's probably the safer approach. As Dave says even if
there's nothing obvious, lmb is used for very early allocs which are
more likely to be special and cause problems - and only when someone
boots with kmemleak enabled. So we're better to explicitly mark things
we want scanned.

cheers

signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Regarding TSI108 ethernet DMA issue

2009-08-20 Thread Thirumalai

Hi all,
I found that the header file(dma-mapping.h) has changed. I saw this 
change has happened on Linux -2.6.28 kernel onwards. earlier kernel is having 
COMFIT_PPC64 macro. Based on this macro the things were happened. Is there any 
fixes available right now or any reasons behind this changes. 
Regards,
T.
  - Original Message - 
  From: Thirumalai Pachamuthu 
  To: linuxppc-...@ozlabs.org 
  Sent: Thursday, August 20, 2009 9:45 AM
  Subject: Regarding TSI108 ethernet DMA issue

  Hi all,
I am trying to port linux 2.6.30 for my TSI108 based custom board where 
i am getting the following kernel panic message. I found that it was due to dma 
allocation function call particularly dma_alloc_coherent() of tsi108_open 
function. When we see the implementation of dma_alloc_coherent. It was bit 
changed from the previous linux versions it seems. 
The implementation of dma_alloc_coherent was kept on the 
arch/powerpc/include/asm/dma-mapping.h file. Earlier implementation is not 
considering the first parameter what the tsi108 driver is passing as NULL. But 
the current implementation is considering this parameter and because of this 
the panic is coming what i believe.

So kindly let me know any patches for this problem or any fixes.
  Regards,
  T.

--

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

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

2009-08-20 Thread David Miller

From: John Linn john.l...@xilinx.com
Date: Wed, 19 Aug 2009 06:29:11 -0600

 This patch adds support for the Xilinx Ethernet Lite device.  The
 soft logic core from Xilinx is typically used on Virtex and Spartan
 designs attached to either a PowerPC or a Microblaze processor.

 Signed-off-by: Sadanand M sada...@xilinx.com
 Signed-off-by: John Linn john.l...@xilinx.com

Looks good, applied to net-next-2.6, thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

2009-08-20 Thread David Miller

From: Michal Simek michal.si...@petalogix.com
Date: Thu, 20 Aug 2009 11:28:48 +0200

 There were one bug with spinlock which John L fixed but not send to
 mainling list. :-(
 He wanted to create new v3 version. :-(.
 When he wake up, he send you that bug fix or v3 version with it.

Send a new version, I'll revert V2 from my tree as I didn't push it
out yet.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] [V2] net: add Xilinx emac lite device driver

[PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

Re: [PATCH 1/2] powerpc/405ex: provide necessary fixup function to support cuImage

Re: [PATCH 2/2] powerpc/405ex: support cuImage via included dtb

RE: [PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC

RE: [PATCH] [V3] net: add Xilinx emac lite device driver

Re: [PATCH] Add support for the ESTeem 195E (PPC405EP) SBC

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

Author: Solomon Peachy solo...@linux-wlan.com

[PATCH v2] Add support for the ESTeem 195E (PPC405EP) SBC

Re: [Bugme-new] [Bug 14021] New: hfsplus caused data loss

JFFS2 overflow bug in read_dnone

[PATCH] char/hvc: adding __init macro to char/hvc_vio.c

RE: [U-Boot] NAND ECC Error with wrong SMC ording bug

[PATCH] powerpc: Adjust base and index registers in Altivec macros

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

[PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.

Re: [PATCH 1/1] Fix ECC Correction bug for SMC ordering for NDFC driver.

linux-next: manual merge of the agp tree with the powerpc tree

Re: [U-Boot] NAND ECC Error with wrong SMC ording bug

[RFC PATCH 0/3] Make 64-bit PCI device tree scanning code common

[PATCH 1/3] powerpc/pci: Remove dead checks for CONFIG_PPC_OF

[PATCH 3/3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()

[PATCH 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c

Re: [PATCH 2/2] powerpc/405ex: support cuImage via included dtb

Re: [PATCH 1/3] powerpc/pci: Remove dead checks for CONFIG_PPC_OF

Re: [PATCH 1/2] powerpc/405ex: provide necessary fixup function to support cuImage

Re: [PATCH] Add kmemleak annotations to lmb.c

Re: Regarding TSI108 ethernet DMA issue

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

Re: [PATCH] [V2] net: add Xilinx emac lite device driver

36 matches

Site Navigation

Mail list logo

Footer information